[JEWEL-1024] Improvements to SpeedSearchArea to support using for filter #3361
Conversation
faogustavo
requested review from
daaria-s,
nebojsa-vuksic,
rock3r and
wellingtoncosta
- Fixed index emission on SelectableLazyColumn when the selection changes by the speed search - Created 'EmptySpeedSearchMatcher' to easily identify when the filter text is empty - This matches is automatically returned in the SpeedSearchState.matcher when the text is empty - Added 'dismissOnLoseFocus' to SpeedSearchArea to keep the filter when the focus is left from the component - Added 'currentMatcher' to the 'SpeedSearchState', allowing the user use it for filtering purposes - Created convenience function on top of 'SpeedSearchMatcher' to check if the given text matches or not - Created convenience functions to support filtering collections based on the speed search matcher
faogustavo
force-pushed
the
gv/JEWEL-1204
branch
from
9ed15c7 to
8857fc4
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| // The `state.lastActiveItemIndex` can also be changed by the SpeedSearch flow. | ||
| // If the last active index is not among the selected indices, the SpeedSearch | ||
| // has selected a different value and an update must be triggered. | ||
| if (indices != lastEmittedIndices || state.lastActiveItemIndex !in indices) { |
There was a problem hiding this comment.
Condition causes repeated callback invocations when selection is empty
The condition state.lastActiveItemIndex !in indices always evaluates to true when indices is empty (since any value, including null, is not contained in an empty list). This means when there's no selection, the onSelectedIndexesChange callback fires every time the LaunchedEffect runs, even if nothing has actually changed. The second part of the condition needs to be guarded to only apply when indices is non-empty, for example: (indices.isNotEmpty() && state.lastActiveItemIndex !in indices).
| keys = currentStateToList.value.second, | ||
| onSelectedIndexChange = { currentOnSelectedIndexesChange(listOf(it)) }, | ||
| dispatcher = dispatcher, | ||
| ) |
There was a problem hiding this comment.
Duplicate callback invocations when SpeedSearch selects an item
When SpeedSearch selects an item, the onSelectedIndexesChange callback can be invoked twice for the same selection event. SpeedSearchableLazyColumnScrollEffect sets selectedKeys and directly calls onSelectedIndexChange. This selectedKeys change then triggers the LaunchedEffect in SelectableLazyColumn, which also calls onSelectedIndexesChange because lastEmittedIndices wasn't updated by the first callback path. This could cause performance issues or unexpected behavior if the callback has side effects.
Additional Locations (1)
1 participant
Evidences
Release notes
New features
Bug fixes
Note
Introduces filtering-focused improvements and small fixes around speed search and selection.
SpeedSearchState,rememberSpeedSearchState,dismissOnLoseFocusflag, andSpeedSearchState.currentMatcher+ visibility controls; internal batching/caching for better performance.EmptySpeedSearchMatcher,SpeedSearchMatcher.doesMatch, andIterable.filter(...)extensions (strings and generics).SpeedSearchableLazyColumnScrollEffectnow reports selection viaonSelectedIndexChange;SelectableLazyColumnemits indices when selection changes via SpeedSearch and syncslastActiveItemIndex.dismissOnLoseFocus=false.Written by Cursor Bugbot for commit 8857fc4. This will update automatically on new commits. Configure here.