-
Notifications
You must be signed in to change notification settings - Fork 1.3k
docs: Use autocomplete docs example #7959
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
b68cb41 to
3b008de
Compare
| ListBox, | ||
| ListBoxItem, | ||
| useFilter, | ||
| UNSTABLE_InternalAutocompleteContext |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like the main thing to determine is whether we want to export this or if we want to change approaches. For example, we could consider providing ListBoxContext and MenuContext instead of having those components consume InternalAutocompleteContext. Not sure which is better. The same kind of thing applies to TextFieldContext and SearchFieldContext and we chose the opposite approach there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's a good question. I like the idea that users aren't restricted to our components (without basically implementing what is in this page to add/remove other contexts).
I'm not sure why we went the other way on the inputs, do you or @LFDanLu have a short summary of that? Or did it just kind of happen?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't quite remember the exact reasoning, but I recall there being a concern with how many collection components may end up being supported by Autocomplete (table, gridlist, listbox, etc) and thus the number of individual contexts that would be needed vs a single one. I'd be happy to shift to individual contexts if only to reuse the existing collection contexts + match our TextField/SearchField context usage here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically we have the same issue with TextField/SearchField, it's possible there may be other ways to control the filter (maybe a predefined set of radio options/tags?)
So how do we want to handle that as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it feels like input fields are smaller in number (radios/tags would take a separate set of props than the ones coming via textFieldProps from useAutocomplete) but we'd still use individual contexts there (aka radioGroupContext/tagGroupContext or something)
## API Changes
react-aria-components/react-aria-components:UNSTABLE_InternalAutocompleteContext+UNSTABLE_InternalAutocompleteContext {
+ UNTYPED
+} |
|
Closing as this is actively being rewritten |
Closes
✅ Pull Request Checklist:
📝 Test Instructions:
🧢 Your Project: