Footer and header render in combobox

[ghost]

Component Lookup is deprecated and instead we have to use combobox. But I didn't find footer render in combobox. Can we add this functionality ?

[interactivellama]

Yeah, looks like the search header could be added. https://www.lightningdesignsystem.com/components/combobox/#Displaying-options-based-on-user-input-2

And it looks like you could do entity search here with two or three headers. https://www.lightningdesignsystem.com/guidelines/search/global/#instant-results

I don't have the footer + New Contact markup, but it looks like it's the same markup as the header.

It looks like we need a new Combobox variant called lookup will add the the search header on by default, once typing starts.

We can add optionsSearchEntity as a prop that takes options just like normals options that way folks can have the "searchTeam" in Entity option added at the top.

As for the footer, I've not seen anything besides Add an item like "+ New Contact" there. I'm thinking that we add an addItemOption prop with an labels.addItemOption string with a default label of "New Entity".

What do you think?

[ghost]

It sounds great, but i think that we have to make footer the same as header with possibility to add custom node element for bigger flexibility.
Also would be nice to add disabled prop to input
defaultValue for uncontrolled behavior
iconAlign: PropTypes.oneOf(['left', 'right']) for selecting preferable position of icon
Functionality for working with scope, something like targetScope: PropTypes.string, defaultTargetScope: PropTypes.string, onScopeMenuClick: PropTypes.func, onScopeChange: PropTypes.func, scopes: PropTypes.arrayOf( PropTypes.shape({ label: PropTypes.string, value: PropTypes.string, icon: PropTypes.string, }), ),.
Please select features which possible to add in Combobox and I will create PR with approved features.
Would be nice if you will approve all features )

[interactivellama]

Input

disabled
defaultValue for uncontrolled behavior
iconAlign: PropTypes.oneOf(['left', 'right'])
As for the input props, please add an input prop that allows an input to be passed in that overrides any existing props. (From a UX pattern, I don't think "search/lookup" inputs should ever be disabled, but read-only Picklists can be, but that's an opinion.)

Menu: Footer and Header

I'm good with optionsSearchEntity and optionsAddItem as arrays that get merged into the options array.

I propose that the default props be something like:
optionsSearchEntity: [{ id:'search-entity-1', icon: <Icon assistiveText={{ label: 'search' }} category="standard" name="search" /> , ] and it only get used if the variant is lookup or cross-entity.

I'm unsure about how to get "searchTeam" in Entity in the label of the option. I'll think about and your other prop proposals to support a cross-entity variant tonight.

[interactivellama]

I thought about it some more. Let's make label a function that gets inputValue from the component and returns a string to render. If consumers want to go crazy with some other markup, they can use the menuItem render prop.

optionsSearchEntity: [{ id:'search-entity-1', icon: <Icon assistiveText={{ label: 'search' }} category="utility" name="search" /> , label: ({ inputValue }) => `${inputValue} in Entity` } ]

optionsAddItem: [{ id:'add-item-1', icon: <Icon assistiveText={{ label: 'add' }} category="utility" name="add" /> , label: 'New Entity' } ]

When working with scope, are you referring to Grouped Comboboxes?

I propose adding a variant: 'cross-entity'. That has an entityCombobox or objectSwitcherCombobox render prop that by default is a read-only Combobox itself and you pass a Combobox into it with it's own options array. I think this should bypass any additional props.

@futuremint What do you think about this prop API for Grouped Comboboxes (Cross-entity / Polymorphic)?

[ghost]

Yes , when I am talking about scope I mean Grouped Comboboxes

[ghost]

If we will merge optionsSearchEntity or optionsAddItem in options we will be able to select its as a value but in my vision it's has to be as a button.
So, may be better to set optionsSearchEntity or optionsAddItem values as object and render it above or below menu ?

[interactivellama]

I don't think you can have a button in a menu listbox from ARIA/Accessibility Tree stand point. A button would have a tab index and remove focus from the input.

Also from what I can tell from the Salesforce Platform keyboard interactions, you just press down arrow to seamlessly go from items in optionsSearchEntity to options to optionsAddItem, so it appears to be the same role="listbox".