[RAC] Allow usage of user-input components inside Autocomplete

[meesvandongen]

Provide a general summary of the feature here

Allow input components, such as selects, search fields, text fields, etc. to be used next to the main search/text field of an autocomplete. (inside the autocomplete context).

🤔 Expected Behavior?

Additional fields inside an Autocomplete do not compete for user focus.

😯 Current Behavior

Given an Autocomplete with a menu as collection that should be filtered/focus managed.

• Using an unrelated Select inside an Autocomplete is not possible; when the user opens the select, options are not selectable for the user. (the select auto closes on hover).
• Using an unrelated Textfield inside the Autocomplete will result in focus behavior such that the user is not able to type anything in this text field.

💁 Possible Solution

• Allow setting the slot property on unrelated items, excluding those items from autocomplete behaviour.
• Using render props inside the autocomplete to somehow point to the relevant text field used for filtering.

🔦 Context

This feature could be useful for cases in which you want the user to provide additional information to the search result.

e.g. if the user clicks on a menu item, and a specific option is selected from a select menu, a different action should be taken.

One of the main problems is that the Autocomplete dictates the DOM structure; if you want the main search field to be at the start of a DOM branch, the Autocomplete will be right above it; any subsequent items between the search field and the Menu/Collection will thus also be inside the Autocomplete in a normal layout flow.

[snowystinger]

Thanks for the feedback, some of this may fall out of our API discussion as we solidify what we're offering there.
Related items:
RSP Component Milestones (view)
RSP Component Milestones (view)

[LFDanLu]

@meesvandongen mind sharing your specific use case? I'm not sure I'm understanding the context here 100%.

[meesvandongen]

The use case is mainly outside of a popover;

Here is a toolbar, which might contain a select that filters a menu to only show items of a specific region. This would look like the image below.

I would prefer to collapse the two toolbars into one;

But the order in the DOM is as the image below; leading to a situation in which the second element will always be inside the context of the autocomplete.

[LFDanLu]

I see, thank you for the diagram that was very helpful! Perhaps we could make it so that passing null to the input's slot excludes it from getting the input props from the AutoComplete context, will have to double check if that would be all we'd need to add here.

[snowystinger]

You should be able to work around this using CSS Grid layout and possibly display contents since AutoComplete doesn't actually render any dom.

[meesvandongen]

I suppose using grid and subgrid could work in most cases, though it isn't very ergonomic since the focus order will have to be managed.

[snowystinger]

Shouldn't focus for the List be controlled virtually by the input and not become a tab stop? so the tab order wouldn't change

[meesvandongen]

I will make a stackblitz to test.