New API Function from Stopwatch & Improve Program Plugin #3429
Conversation
@check-spelling-bot Report🔴 Please reviewSee the 📂 files view, the 📜action log, or 📝 job summary for details.
See ❌ Event descriptions for more information. Pattern suggestions ✂️ (1)You could add these patterns to If the flagged items are 🤯 false positivesIf items relate to a ...
|
|
Be a legend 🏆 by adding a before and after screenshot of the changes you made, especially if they are around UI/UX. |
📝 WalkthroughWalkthroughThe changes standardize and centralize logging across multiple components by introducing a consistent Changes
Sequence Diagram(s)sequenceDiagram
participant Caller as Application Component
participant API as IPublicAPI
participant Stopwatch as Stopwatch
Caller->>API: Call StopwatchLogInfoAsync(ClassName, message, action)
API->>Stopwatch: Invoke NormalAsync(action)
Stopwatch-->>API: Return elapsed time
API-->>Caller: Return logged result & execution time
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
Flow.Launcher.Infrastructure/Image/ImageLoader.cs (1)
57-64: Improved logging with new API methods.The code now uses the new
StopwatchLogInfoAsyncmethod instead of direct stopwatch/logging calls, providing more consistent logging with execution time tracking.However, there's a minor redundancy in the log message:
-API.LogInfo(ClassName, $"Number of preload images is <{ImageCache.CacheSize()}>, Images Number: {ImageCache.CacheSize()}, Unique Items {ImageCache.UniqueImagesInCache()}"); +API.LogInfo(ClassName, $"Number of preload images is <{ImageCache.CacheSize()}>, Unique Items {ImageCache.UniqueImagesInCache()}");
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
Flow.Launcher.Core/Plugin/PluginManager.cs(3 hunks)Flow.Launcher.Core/Plugin/PluginsLoader.cs(2 hunks)Flow.Launcher.Infrastructure/Image/ImageLoader.cs(4 hunks)Flow.Launcher.Infrastructure/Stopwatch.cs(0 hunks)Flow.Launcher.Plugin/Interfaces/IPublicAPI.cs(1 hunks)Flow.Launcher/App.xaml.cs(3 hunks)Flow.Launcher/PublicAPIInstance.cs(2 hunks)Plugins/Flow.Launcher.Plugin.Program/Main.cs(7 hunks)
💤 Files with no reviewable changes (1)
- Flow.Launcher.Infrastructure/Stopwatch.cs
🧰 Additional context used
🧬 Code Definitions (5)
Plugins/Flow.Launcher.Plugin.Program/Main.cs (5)
Flow.Launcher.Plugin/Interfaces/IPublicAPI.cs (3)
LogDebug(219-219)LogInfo(224-224)LogException(240-240)Flow.Launcher/PublicAPIInstance.cs (6)
LogDebug(205-206)LogInfo(208-209)LogException(217-218)Task(117-117)Task(188-189)Task(191-192)Flow.Launcher.Core/Plugin/JsonRPCV2Models/JsonRPCPublicAPI.cs (2)
LogDebug(143-146)LogInfo(148-151)Plugins/Flow.Launcher.Plugin.Explorer/ContextMenu.cs (1)
LogException(471-474)Flow.Launcher.Infrastructure/Storage/PluginJsonStorage.cs (1)
Task(49-59)
Flow.Launcher.Infrastructure/Image/ImageLoader.cs (2)
Flow.Launcher.Plugin/Interfaces/IPublicAPI.cs (2)
LogInfo(224-224)LogException(240-240)Flow.Launcher/PublicAPIInstance.cs (2)
LogInfo(208-209)LogException(217-218)
Flow.Launcher/App.xaml.cs (1)
Flow.Launcher/PublicAPIInstance.cs (1)
StopwatchLogInfo(441-442)
Flow.Launcher/PublicAPIInstance.cs (3)
Flow.Launcher.Infrastructure/Stopwatch.cs (2)
Stopwatch(7-62)Normal(39-49)Flow.Launcher.Plugin/Interfaces/IPublicAPI.cs (14)
StopwatchLogDebug(482-482)Task(73-73)Task(170-170)Task(178-178)Task(191-191)Task(342-342)Task(391-391)Task(405-405)Task(428-428)Task(455-455)Task(475-475)Task(489-489)Task(501-501)StopwatchLogInfo(495-495)Flow.Launcher.Infrastructure/Logger/Log.cs (2)
Debug(204-207)Debug(210-213)
Flow.Launcher.Plugin/Interfaces/IPublicAPI.cs (1)
Flow.Launcher/PublicAPIInstance.cs (14)
StopwatchLogDebug(435-436)Task(117-117)Task(188-189)Task(191-192)Task(194-195)Task(364-365)Task(398-405)Task(407-414)Task(419-420)Task(426-427)Task(432-433)Task(438-439)Task(444-445)StopwatchLogInfo(441-442)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: gitStream.cm
- GitHub Check: gitStream.cm
🔇 Additional comments (29)
Flow.Launcher.Core/Plugin/PluginManager.cs (3)
26-26: Good addition of ClassName field for loggingAdding a static field for the class name makes logging more consistent and maintainable across the codebase.
199-201: Appropriate use of new StopwatchLogDebugAsync APIThis implementation correctly replaces the previous direct Stopwatch call with the new API method, using the ClassName field to maintain consistent logging format.
271-272: Good implementation of StopwatchLogDebugAsyncProperly updates the code to use the new API method for measuring query execution time while maintaining the same functionality.
Flow.Launcher/App.xaml.cs (3)
37-38: Good addition of ClassName field for standardized loggingAdding a static field for the class name enhances log consistency and readability throughout the application.
140-195: Well-implemented StopwatchLogInfoAsync for startup timingThis change correctly replaces the direct Stopwatch call with the new API method, using the ClassName field to ensure consistent log formatting for application startup timing.
317-330: Appropriate use of StopwatchLogInfo for disposal timingGood implementation of the synchronous version of the stopwatch logging API for the application dispose process.
Plugins/Flow.Launcher.Plugin.Program/Main.cs (8)
33-34: Good addition of ClassName field for standardized loggingAdding a static field for the class name ensures consistent log formatting and improves code maintainability.
112-113: Good implementation of LogDebug APISuccessfully replaced direct Log.Debug call with the API's LogDebug method using the ClassName field for consistent log formats.
191-255: Well-implemented StopwatchLogInfoAsync for program preloadingThe implementation correctly uses the new API method to log program preloading execution time, maintaining the same functionality while improving log consistency.
256-257: Good transition to API's LogInfo methodSuccessfully replaced direct Log.Info calls with API.LogInfo calls using the ClassName field for consistent log formatting.
298-299: Appropriate use of LogException APIGood implementation of the API's LogException method instead of direct Log.Exception call for error handling.
323-324: Consistent use of LogException APIThis change maintains consistent error logging patterns throughout the class by using the API's LogException method.
335-336: Well-implemented StopwatchLogInfoAsync for Win32 program indexingThe change correctly uses the new API method to log program indexing execution time, improving log consistency.
340-341: Good implementation of StopwatchLogInfoAsync for UWP program indexingSuccessfully implemented the same logging pattern for UWP program indexing, ensuring consistency throughout the codebase.
Flow.Launcher.Core/Plugin/PluginsLoader.cs (2)
19-24: Good implementation of ClassName field and API propertyThe changes correctly add:
- A static field for the class name to standardize logging
- A private static field for the API instance
- A property with lazy initialization to avoid premature API instance creation
This follows the same pattern used in PluginManager, ensuring consistency across the codebase.
67-116: Appropriate use of StopwatchLogDebug APIThe implementation correctly replaces the direct Stopwatch call with the new API method, using the ClassName field to maintain consistent logging format for plugin initialization timing.
Flow.Launcher.Infrastructure/Image/ImageLoader.cs (4)
10-10: Added dependency for dependency injection.The new
CommunityToolkit.Mvvm.DependencyInjectiondependency is used for retrieving theIPublicAPIservice, aligning with the PR's goal of standardizing API access.
18-22: Good implementation of lazy-initialized API with standardized class name.The implementation follows best practices with:
- Clear comment explaining why static constructor initialization is avoided
- Lazy initialization pattern for the API instance
- Consistent
ClassNamefield for standardized loggingThis approach ensures the API is only initialized when needed, preventing unnecessary resource usage.
80-80: Standardized exception logging.Updated to use the API's exception logging method which provides consistent formatting with class name context.
175-176: Enhanced exception logging with class context.Both exceptions are now logged with standardized formatting including the class name for better traceability.
Flow.Launcher.Plugin/Interfaces/IPublicAPI.cs (4)
477-482: New API method for synchronous debug logging with execution time tracking.Well-documented method that logs debug messages with execution time measurement, following the same pattern as existing logging methods. This method enhances the API by providing standardized performance tracking capabilities for plugin developers.
484-489: New API method for asynchronous debug logging with execution time tracking.This method provides the asynchronous counterpart to the synchronous version, maintaining a consistent API pattern. The documentation clearly explains that this logs only in debug mode and returns the execution time.
491-495: New API method for synchronous info logging with execution time tracking.Well-structured method that follows the established pattern but logs at info level instead of debug. This will be useful for logging performance metrics that should always be visible regardless of debug settings.
497-501: New API method for asynchronous info logging with execution time tracking.Completes the set of stopwatch logging methods with the asynchronous info-level variant. This provides a comprehensive set of options for plugin developers to track and log execution times.
Flow.Launcher/PublicAPIInstance.cs (5)
34-34: Proper aliasing to avoid namespace conflicts.Good practice using an alias for the
Stopwatchclass to avoid conflicts withSystem.Diagnostics.Stopwatch.
435-436: Implementation of synchronous debug stopwatch logging.Clean implementation using expression-bodied member syntax with proper message formatting that includes class and method context.
438-439: Implementation of asynchronous debug stopwatch logging.The asynchronous implementation properly delegates to the
Stopwatch.DebugAsyncmethod with consistent message formatting.
441-442: Implementation of synchronous info stopwatch logging.Proper implementation that delegates to
Stopwatch.Normalfor info-level logging with execution time tracking.
444-445: Implementation of asynchronous info stopwatch logging.Completes the implementation set with consistent formatting and proper delegation to the underlying
Stopwatch.NormalAsyncmethod.
Jack251970
added
enhancement
|
|
||
| // We should not initialize API in static constructor because it will create another API instance | ||
| private static IPublicAPI api = null; | ||
| private static IPublicAPI API => api ??= Ioc.Default.GetRequiredService<IPublicAPI>(); |
There was a problem hiding this comment.
Not an issue for now but we should think about a better way to safeguard this, maybe a design pattern we can use or something.
New API Function from Stopwatch
Added new api functions to helper csharp plugin developers quickly log debug & info message with function executing time.
Improve Program Plugin
Use api functions instead of project reference in Program plugin.