feat(@clayui/autocomplete): adds loading indicator and live announcer to infinite scrolling #6060
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ticket LPD-55597
Well, this PR introduces improvements to the infinite scrolling mechanism used by the Autocomplete component, which also benefits the MultiSelect component. There are still a few minor adjustments needed, particularly around triggering the load more functionality via keyboard interaction—specifically, ensuring the scroll moves to the loading indicator, and after the new items are loaded, to the next item in the list.
One small caveat: the loading indicator is barely visible when the request completes very quickly. You can only consistently observe it when simulating a slower connection (e.g., 3G) in the browser—this applies to both mouse and keyboard interactions. This behavior also depends on how fast the API response is, and in the example cases, it’s a bit hard to notice.
This PR also includes improvements to the live announcer, which now behaves as a singleton and relies on a global state.
Looking ahead, one possible enhancement would be to move the keyboard-based load more trigger and the infinite scroll announcer logic to the Collection layer. However, I still need to identify a better pattern for that. Some of this logic could potentially go into
useNavigation
, but I’m not too keen on that approach, since it would make the hook responsible for handling network state awareness. A better alternative might be to create a newuseCollectionAnnouncer
hook that encapsulates this behavior and is easy to reuse across other components. I’ll investigate cleaner approaches in the future.Also, a quick note: I added a deprecation warning to a few Storybook examples that still use the legacy Autocomplete implementation. These are only kept for backwards compatibility. This legacy usage caused some confusion in the ticket raised to address these problems, as the examples in question don’t reflect the current implementation of the Autocomplete component.