Input Smooth & Search delay #3350
Conversation
|
🥷 Code experts: onesounds, Yusyuriv Jack251970 has most 👩💻 activity in the files. See details
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame: To learn more about /:\ gitStream - Visit our Docs |
This comment has been minimized.
This comment has been minimized.
📝 WalkthroughWalkthroughThis pull request introduces delayed search functionality across the application. Two new properties are added to the settings for configuring delay behavior, and corresponding UI elements along with language strings are provided for user configuration. Reactive programming is integrated into the main window to delay query executions based on user input. Additionally, adjustments in the main view model now invoke queries explicitly via a dedicated method rather than through property setters. A new package reference for reactive programming is also included. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant QueryTextBox
participant MainWindow
participant ReactivePipeline
participant SearchEngine
User->>QueryTextBox: Types query text
QueryTextBox->>MainWindow: Triggers TextChanged event
MainWindow->>ReactivePipeline: Processes event with delay (Throttle)
ReactivePipeline->>MainWindow: Emits delayed event
MainWindow->>SearchEngine: Executes search query
sequenceDiagram
participant User
participant MainViewModel
participant QueryEngine
User->>MainViewModel: Updates query text via UI
MainViewModel->>MainViewModel: Updates QueryText property
MainViewModel->>QueryEngine: Calls Query() via ChangeQueryText method
Suggested labels
Suggested reviewers
Poem
Tip ⚡🧪 Multi-step agentic review comment chat (experimental)
✨ Finishing Touches
🪧 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 (
|
This comment has been minimized.
This comment has been minimized.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
Flow.Launcher.Infrastructure/UserSettings/Settings.cs(1 hunks)Flow.Launcher/Flow.Launcher.csproj(1 hunks)Flow.Launcher/Languages/en.xaml(1 hunks)Flow.Launcher/MainWindow.xaml.cs(5 hunks)Flow.Launcher/SettingPages/ViewModels/SettingsPaneGeneralViewModel.cs(1 hunks)Flow.Launcher/SettingPages/Views/SettingsPaneGeneral.xaml(1 hunks)Flow.Launcher/ViewModel/MainViewModel.cs(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: gitStream.cm
- GitHub Check: gitStream.cm
🔇 Additional comments (11)
Flow.Launcher.Infrastructure/UserSettings/Settings.cs (1)
278-279: Good implementation of the search delay settingsThe addition of these two settings properties is clean and fits well within the existing settings structure. The default values (delay disabled by default with a 120ms duration when enabled) are reasonable choices.
Flow.Launcher/Flow.Launcher.csproj (1)
107-107: Appropriate package addition for implementing reactive search behaviorAdding System.Reactive.Linq is a good choice for implementing the delayed search functionality, as it provides the tools needed for throttling input events.
Flow.Launcher/SettingPages/Views/SettingsPaneGeneral.xaml (1)
175-195: UI elements for search delay are well structuredThe UI elements follow the application's design patterns with appropriate use of CardGroup and Cards. The toggle switch and ComboBox are correctly bound to the corresponding ViewModel properties, and the use of localized strings for labels and tooltips supports internationalization.
Flow.Launcher/SettingPages/ViewModels/SettingsPaneGeneralViewModel.cs (1)
153-156: Range of delay values is comprehensiveThe delay range from 30ms to 300ms provides good flexibility for users to find their preferred responsiveness level. The 120ms default is a reasonable middle ground.
Flow.Launcher/Languages/en.xaml (1)
97-100: Well-formatted and clear string resources for search delay feature.The added string resources for the new search delay functionality follow the existing naming conventions and provide helpful tooltips that clearly explain the feature's purpose and default values.
Flow.Launcher/ViewModel/MainViewModel.cs (2)
633-633: Explicit query call for better control of search execution.This change separates setting the query text from executing the query, which enables the delayed search functionality. Now the query is explicitly triggered after setting the text rather than being automatically triggered by the property setter.
698-698: Ensures query is executed when selecting results with empty query text.Adds an explicit call to Query() after clearing the query text, which maintains the expected behavior while supporting the new delayed search implementation.
Flow.Launcher/MainWindow.xaml.cs (4)
29-29: Added required namespace for reactive programming.The System.Reactive.Linq namespace provides the essential extensions for implementing delayed search using the Observable pattern and Throttle operator.
71-71: Initializes search delay functionality when window loads.Properly sets up the reactive behavior of the search text box based on user settings when the window is loaded.
209-265: Improved code organization for window visibility and progress bar handling.The refactored property change handlers flatten the nested conditionals and improve the organization of the code, making it more readable while maintaining the same functionality.
864-932: Well-implemented search delay using reactive programming.The search delay implementation:
- Uses the Observable pattern with Throttle operator to delay search execution
- Properly handles subscription lifecycle (creation and disposal)
- Maintains auto-complete functionality
- Separates concerns into well-defined methods
- Follows good reactive programming practices derived from PowerToys
The code effectively implements the search delay functionality requested in issue #1677.
Flow.Launcher/SettingPages/ViewModels/SettingsPaneGeneralViewModel.cs
Outdated
Show resolved
Hide resolved
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
Flow.Launcher/MainWindow.xaml.cs (1)
865-936: Well-implemented search delay functionalityThe implementation of search delay using Reactive Extensions is well-structured and handles all edge cases:
- Properly cleans up previous subscriptions before creating new ones
- Uses appropriate throttling mechanism to delay search execution
- Correctly handles both delayed and immediate search modes
- Properly manages auto-complete text clearing
- Includes attribution to the original PowerToys implementation
Consider adding XML documentation to these methods to improve code maintainability for future developers.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
Flow.Launcher.Infrastructure/UserSettings/Settings.cs(1 hunks)Flow.Launcher/MainWindow.xaml.cs(6 hunks)Flow.Launcher/SettingPages/ViewModels/SettingsPaneGeneralViewModel.cs(1 hunks)Flow.Launcher/SettingPages/Views/SettingsPaneGeneral.xaml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- Flow.Launcher/SettingPages/Views/SettingsPaneGeneral.xaml
- Flow.Launcher/SettingPages/ViewModels/SettingsPaneGeneralViewModel.cs
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: gitStream.cm
🔇 Additional comments (5)
Flow.Launcher.Infrastructure/UserSettings/Settings.cs (1)
278-288: New search delay functionality looks goodThe implementation adds two well-designed properties to support search query delay functionality:
SearchQueryResultsWithDelay- toggle to enable/disable the delay featureSearchInputDelay- configurable delay value (default 120ms)The properties follow proper MVVM patterns with appropriate property change notification.
Flow.Launcher/MainWindow.xaml.cs (4)
29-29: Added Reactive Extensions dependencyAdded the necessary dependency to implement reactive programming for the search delay functionality.
71-71: Appropriate initialization of search reactivenessThe search reactiveness setup is called during window loading, which is the correct place to initialize this functionality.
205-264: Improved property change handlers structureThe property change handlers for
MainWindowVisibilityStatusandProgressBarVisibilityhave been refactored to be more readable with better structure and explicit break statements.
300-302: Good handling of settings property changeThe code properly responds to settings changes by setting up the search reactiveness when the delay toggle changes.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
Flow.Launcher/MainWindow.xaml.cs (1)
926-926: Consider using case-insensitive comparison for autocompleteThe code uses StringComparison.Ordinal for autocomplete prefix matching, which is case-sensitive. For better user experience, consider using StringComparison.OrdinalIgnoreCase to match autocomplete suggestions regardless of case.
- return string.IsNullOrEmpty(queryText) || !autoCompleteText.StartsWith(queryText, StringComparison.Ordinal); + return string.IsNullOrEmpty(queryText) || !autoCompleteText.StartsWith(queryText, StringComparison.OrdinalIgnoreCase);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
Flow.Launcher/MainWindow.xaml.cs(6 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: gitStream.cm
🔇 Additional comments (6)
Flow.Launcher/MainWindow.xaml.cs (6)
29-29: Added Reactive Extensions dependencyThe code now includes System.Reactive.Linq for implementing throttled search functionality.
198-199: Search reactiveness initialization addedGood addition of search reactiveness setup during window loading, which allows for delayed search functionality.
210-246: Improved window visibility handlingThe code has been reorganized for better readability while maintaining the same functionality. The conditional structure is now clearer with better indentation.
249-265: Refactored progress bar visibility logicThe progress bar visibility handling has been improved with clearer conditional statements and better structure.
301-303: Added handler for search delay setting changesGood implementation of a property change handler that reconfigures search reactiveness when the user toggles the delay setting.
889-889:✅ Verification successful
Verify search delay configuration
The throttle delay is set from user settings, which is a good approach for configurability.
🌐 Web query:
What is a good throttle delay for search input in UI applications?💡 Result:
Throttling delays for search inputs in UI applications typically range between 200-500 milliseconds, but the optimal choice depends on balancing responsiveness and performance. Here's a breakdown of key considerations:
Throttle vs. Debounce Preference
- Debouncing is generally preferred for search inputs[1][5][9], as it waits until typing stops completely (e.g., 300ms pause) before executing, reducing unnecessary API calls.
- Throttling forces regular execution intervals, which can feel more responsive but might generate more network traffic than needed[2][3].
When Using Throttle
For scenarios where immediate feedback is critical:
- 200-300ms: Provides near real-time updates for short queries
- 400-500ms: Better for complex searches or slower backends
Performance Considerations
Delay Pros Cons 200ms Feels instantaneous High server load 300ms Balanced UX Slight lag 500ms Server-friendly Noticeable delay Implementation Example
const throttleSearch = throttle((query) => { // API call here }, 300); // Adjust delay based on testing inputElement.addEventListener('input', (e) => { throttleSearch(e.target.value); });In practice, most teams opt for debouncing with 300ms delay for search inputs[5][7][9], reserving throttling for scroll/resize handlers or rate-limited APIs[4][6]. Always test with real users to find the sweet spot between perceived performance and system load[8].
Citations:
- 1: https://dev.to/abhirupa/the-art-of-smooth-ux-debouncing-and-throttling-for-a-more-performant-ui-m0h
- 2: http://devsign.co/notes/throttle-and-debounce
- 3: https://www.youtube.com/watch?v=cjIswDCKgu0
- 4: https://weblog.west-wind.com/posts/2017/jul/02/debouncing-and-throttling-dispatcher-events
- 5: https://dev.to/kartikbudhraja/debouncing-and-throttling-choosing-the-right-strategy-for-your-web-projects-5cjh
- 6: https://www.telerik.com/blogs/debouncing-and-throttling-in-javascript
- 7: https://forums.meteor.com/t/best-way-to-throttle-a-live-search-input/32133
- 8: https://www.developerway.com/posts/debouncing-in-react
- 9: https://blog.codeminer42.com/codetips10-throttle-and-debounce/
Search Delay Configuration Verified
The current implementation sets the throttle delay from user settings, which is a flexible approach. Based on industry guidance, a throttle delay in the range of 200–500 ms is generally ideal for search inputs. As a best practice, please ensure that the default value in
_settings.SearchInputDelayfalls within this range (around 300 ms is common). Additionally, consider whether a debouncing strategy might better suit your use case if minimizing unnecessary API calls is a priority.
| @@ -631,6 +630,7 @@ public void ChangeQueryText(string queryText, bool isReQuery = false) | |||
| { | |||
| // re-query is done in QueryText's setter method | |||
| QueryText = queryText; | |||
| Query(); | |||
There was a problem hiding this comment.
From original codes, when QueryText is changed, it will call Query().
There was a problem hiding this comment.
And I remove Query() in QueryText setter, so we need to manually call it.
There was a problem hiding this comment.
QueryText is a property used by others functions in MainViewModel like auto complete text, backspace event, change query text event, etc. So we need to update it once users input.
Query is a function to load results and we can delay them.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@check-spelling-bot Report🔴 Please reviewSee the 📂 files view, the 📜action log, or 📝 job summary for details.
See ❌ Event descriptions for more information. Forbidden patterns 🙅 (1)In order to address this, you could change the content to not match the forbidden patterns (comments before forbidden patterns may help explain why they're forbidden), add patterns for acceptable instances, or adjust the forbidden patterns themselves. These forbidden patterns matched content: s.b. workaround(s)If the flagged items are 🤯 false positivesIf items relate to a ...
|
Delay time when typing to search
More details in #1677. Codes are edited from PowerToys Run project and they are all done and works well on FL.
Close #1677.
TODO
plugin.json& Add document// TODO: Remove debug codes.Test