-
Notifications
You must be signed in to change notification settings - Fork 1.3k
fix: (WIP) Autocomplete context refactor #8695
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
base: baseCollection_filter
Are you sure you want to change the base?
Changes from 10 commits
c111744
24dd7cb
d8969a7
ae3cc84
3a81f31
db91b3a
7177106
dfb80f3
ec8066f
76107ff
cde0977
82cb364
18d3dbc
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -10,29 +10,45 @@ | |||||
* governing permissions and limitations under the License. | ||||||
*/ | ||||||
|
||||||
import {AriaAutocompleteProps, CollectionOptions, useAutocomplete} from '@react-aria/autocomplete'; | ||||||
import {AriaAutocompleteProps, useAutocomplete} from '@react-aria/autocomplete'; | ||||||
import {AriaLabelingProps, DOMProps, FocusEvents, KeyboardEvents, Node, ValueBase} from '@react-types/shared'; | ||||||
import {AriaTextFieldProps} from '@react-aria/textfield'; | ||||||
import {AutocompleteState, useAutocompleteState} from '@react-stately/autocomplete'; | ||||||
import {InputContext} from './Input'; | ||||||
import {ContextValue, Provider, removeDataAttributes, SlotProps, SlottedContextValue, useSlottedContext} from './utils'; | ||||||
import {mergeProps} from '@react-aria/utils'; | ||||||
import {Node} from '@react-types/shared'; | ||||||
import {Provider, removeDataAttributes, SlotProps, SlottedContextValue, useSlottedContext} from './utils'; | ||||||
import React, {createContext, JSX, RefObject, useRef} from 'react'; | ||||||
import {SearchFieldContext} from './SearchField'; | ||||||
import {TextFieldContext} from './TextField'; | ||||||
|
||||||
export interface AutocompleteProps<T> extends AriaAutocompleteProps<T>, SlotProps {} | ||||||
|
||||||
interface InternalAutocompleteContextValue<T> { | ||||||
// TODO: naming | ||||||
// IMO I think this could also contain the props that useSelectableCollection takes (minus the selection options?) | ||||||
interface CollectionContextValue<T> extends DOMProps, AriaLabelingProps { | ||||||
filter?: (nodeTextValue: string, node: Node<T>) => boolean, | ||||||
collectionProps: CollectionOptions, | ||||||
collectionRef: RefObject<HTMLElement | null> | ||||||
/** Whether the collection items should use virtual focus instead of being focused directly. */ | ||||||
shouldUseVirtualFocus?: boolean, | ||||||
/** Whether typeahead is disabled. */ | ||||||
disallowTypeAhead?: boolean, | ||||||
collectionRef?: RefObject<HTMLElement | null> | ||||||
} | ||||||
|
||||||
// TODO: naming | ||||||
interface FieldInputContextValue<T = HTMLInputElement> extends | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
this seems more reasonable, this is specific to the Autocomplete, whereas the CollectionContext is specific to the Collections. Unless we had something in mind for this context that wasn't Autocomplete? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. From my understanding, the eventual intent for these contexts is that they aren't specifically tied to Autocomplete and simply contain values/attributes/properties that a input might have. It may not even be an input though, could be a text area or some other control hence the generic default. The future use case is still a bit hazy though tbh There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure, the one for collections is, but this input one does seem very tied to autocomplete That or I'd argue both context should be defined somewhere else, that isn't inside the Autocomplete package |
||||||
DOMProps, | ||||||
FocusEvents<T>, | ||||||
KeyboardEvents, | ||||||
Pick<ValueBase<string>, 'onChange' | 'value'>, | ||||||
Pick<AriaTextFieldProps, 'enterKeyHint' | 'aria-controls' | 'aria-autocomplete' | 'aria-activedescendant' | 'spellCheck' | 'autoCorrect' | 'autoComplete'> {} | ||||||
|
||||||
export const AutocompleteContext = createContext<SlottedContextValue<Partial<AutocompleteProps<any>>>>(null); | ||||||
export const AutocompleteStateContext = createContext<AutocompleteState | null>(null); | ||||||
// This context is to pass the register and filter down to whatever collection component is wrapped by the Autocomplete | ||||||
// TODO: export from RAC, but rename to something more appropriate | ||||||
export const UNSTABLE_InternalAutocompleteContext = createContext<InternalAutocompleteContextValue<any> | null>(null); | ||||||
|
||||||
// TODO export from RAC, maybe move up and out of Autocomplete | ||||||
// also can't make this use ContextValue (so that we can call useContextProps) like FieldInput for a similar reason. The HTMLElement type for the ref | ||||||
// makes useContextProps complain since it doesn't mesh up with HTMLDivElement | ||||||
Comment on lines
+44
to
+46
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yes, move up There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the error is as follows:
so that a consuming component like Menu can then call
in order to merge its own set of collectionProps and its own ref with the ones being provided by the Autocomplete via context. However, the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it isn't necessary to use useContextProps, hence the current approach working in Menu/Listbox working due to casting the final ref merge as the desired ref type, but it would be nice to have that work IMO There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Updated with another attempt at the types There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could use EventTarget? if it's just for dispatching events? or something else that they both inherit from? |
||||||
export const CollectionContext = createContext<CollectionContextValue<any> | null>(null); | ||||||
// TODO: too restrictive to type this as a HTMLInputElement? Needed for the ref merging that happens in TextField/SearchField | ||||||
// Attempted to use FocusableElement but as mentioned above, SearchField and TextField complain since they expect HTMLInputElement for their hooks and stuff | ||||||
export const FieldInputContext = createContext<ContextValue<FieldInputContextValue, HTMLInputElement>>(null); | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Types are the final problem here. The problem is two fold, ideally we'd be able to have For |
||||||
|
||||||
/** | ||||||
* An autocomplete combines a TextField or SearchField with a Menu or ListBox, allowing users to search or filter a list of suggestions. | ||||||
|
@@ -61,12 +77,13 @@ export function Autocomplete<T extends object>(props: AutocompleteProps<T>): JSX | |||||
<Provider | ||||||
values={[ | ||||||
[AutocompleteStateContext, state], | ||||||
[SearchFieldContext, textFieldProps], | ||||||
[TextFieldContext, textFieldProps], | ||||||
[InputContext, {ref: inputRef}], | ||||||
[UNSTABLE_InternalAutocompleteContext, { | ||||||
filter: filterFn as (nodeTextValue: string, node: Node<T>) => boolean, | ||||||
collectionProps, | ||||||
[FieldInputContext, { | ||||||
...textFieldProps, | ||||||
ref: inputRef | ||||||
}], | ||||||
[CollectionContext, { | ||||||
...collectionProps, | ||||||
filter: filterFn, | ||||||
collectionRef: mergedCollectionRef | ||||||
}] | ||||||
]}> | ||||||
|
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.
disableVirtualFocus i think is a better name, it's not really about allowing or not, it's just whether it is or not
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 debated about this myself a bit haha. I went with the above since it means the default is false as per our API guidelines, but I certainly do like
disable
better (as can be seen fromdisableAutoFocusFirst
)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.
another thing to discuss perhaps: is it a problem that virtual focus doesn't work with grid collection just yet but will be enabled by default later?
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.
that's an excellent question, does seem problematic