Chore: update debounce value - #182
Conversation
|
Warning Review limit reached
Next review available in: 52 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe pull request changes async filtering defaults and lifecycle logging, adjusts focus disposal behavior, adds spacing to example tabs, updates Android flags, expands VS Code colors, and renames the README contributor section. ChangesSearchable listview updates
Estimated code review effort: 2 (Simple) | ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@lib/searchable_listview.dart`:
- Line 557: Update the cleanup around the searchable list’s focus handling to
avoid calling FocusManager.instance.primaryFocus?.unfocus() unconditionally.
Unfocus only the focus node owned by this searchable list, or move the cleanup
into the search-field component that owns that node, preserving focus in
unrelated fields when the list is disposed.
- Line 92: Add a regression test covering the 3000 ms default assigned by the
SearchableListView constructor, including the downstream async test path. Omit
asyncDebounceTime, use a query that changes the filtered results, advance the
test clock beyond 3000 ms explicitly, and then verify the updated results
instead of relying on pumpAndSettle alone.
- Line 809: Update the logging around the filtering operation to avoid including
the raw value from the search input. In the filtering logic containing the log
statement, record only that filtering occurred, unless an explicit
development-only diagnostic flag permits detailed query logging.
- Around line 555-557: Update the SearchableListView dispose flow to cancel
pending asynchronous work before the widget is torn down: dispose the _debouncer
and cancel or invalidate _activeOperation so queued callbacks cannot invoke
asyncListFilter after disposal. Keep the existing focus-unfocus behavior intact.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 9d4926b9-962d-42d7-9be5-4e10fcbb2bb0
⛔ Files ignored due to path filters (1)
example/pubspec.lockis excluded by!**/*.lock
📒 Files selected for processing (5)
.vscode/settings.jsonREADME.mdexample/android/gradle.propertiesexample/lib/main.dartlib/searchable_listview.dart
f8ce91a to
2fd23b8
Compare
Summary by CodeRabbit