fix(combobox): add combobox pattern

[Westbrook]

Description

Add a Combobox pattern to the library:

<sp-combobox label="Declarative combobox">
    <sp-menu-item value="0">Declare this</sp-menu-item>
    <sp-menu-item value="1">Declare that</sp-menu-item>
    <sp-menu-item value="2">Declare the other</sp-menu-item>
</sp-combobox>

<sp-combobox
  label="Imparative combobox"
  options='[
    {"value": "0", "itemText": "Imperative this"},
    {"value": "1", "itemText": "Imperative that"},
    {"value": "2", "itemText": "Imperative the other"}
  ]'
>
</sp-combobox>

Visit the docs for more information.

Related issue(s)

• fixes Add Spectrum Combobox Pattern #478

How has this been tested?

• Test case 1
  1. Go here
  2. Test an autocomplete="none" Combobox
• Test case 2
  1. Go here
  2. Test an autocomplete="list" Combobox

Screenshots (if appropriate)

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• If my change required a change to the documentation, I have updated the documentation in this pull request.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have reviewed at the Accessibility Practices for this feature, see: Aria Practices

[github-actions]

Branch Preview

• Documentation Site
• Storybook

Visual regression test results

When a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:

• High Contrast Mode | Medium | LTR
• Classic | Lightest | Medium | LTR
• Classic | Lightest | Medium | RTL
• Classic | Lightest | Large | LTR
• Classic | Lightest | Large | RTL
• Classic | Light | Medium | LTR
• Classic | Light | Medium | RTL
• Classic | Light | Large | LTR
• Classic | Light | Large | RTL
• Classic | Dark | Medium | LTR
• Classic | Dark | Medium | RTL
• Classic | Dark | Large | LTR
• Classic | Dark | Large | RTL
• Classic | Darkest | Medium | LTR
• Classic | Darkest | Medium | RTL
• Classic | Darkest | Large | LTR
• Classic | Darkest | Large | RTL
• Express | Lightest | Medium | LTR
• Express | Lightest | Medium | RTL
• Express | Lightest | Large | LTR
• Express | Lightest | Large | RTL
• Express | Light | Medium | LTR
• Express | Light | Medium | RTL
• Express | Light | Large | LTR
• Express | Light | Large | RTL
• Express | Dark | Medium | LTR
• Express | Dark | Medium | RTL
• Express | Dark | Large | LTR
• Express | Dark | Large | RTL
• Express | Darkest | Medium | LTR
• Express | Darkest | Medium | RTL
• Express | Darkest | Large | LTR
• Express | Darkest | Large | RTL

[github-actions]

Tachometer results

Currently, no packages are changed by this PR...

[najikahalsema]

Question that came up for me as I work on the benchmark test: do we want to expand this API to also to accept an array of strings that could get converted to ComboboxOptions? The id could match the value, or we could do some fancy RegEx or whatever to convert the value to something more multipurpose.

The reason I ask is because I have an String array of a list of countries, and it's annoying for me to have to convert them into an object so I can fit it into this API. It'd be nice if I could just have the combobox do the work of converting it for me. I'm also thinking about that in case we end up using the select-only combobox as a basis for the lazy picker or something... What do you think, @Westbrook?

[najikahalsema]

Currently, we can do this with a map and have all the values in the lightDOM, but I wouldn't want that to be the only option.

        <sp-combobox>
            ${countryList.map(
                (value, index) => html`
                    <sp-menu-item id=${index} value=${value}>
                        ${option.value}
                    </sp-menu-item>
                `
            )}
        </sp-combobox>

[Westbrook]

This is a great question for potential consumers of the element. I'm not opposed to it so much as I would be surprised to see someone with a functional data set that didn't already have not a unique identifier AND a user readable value.

In that case that there were, conditioning data to support this is also not too crazy:

<sp-combobox
    .options=${countryList.map((value, index) => ({ value, index }))}
></sp-combobox>

This repeats the data processing more than would be appropriate, so you would probably cache a conditioned array in the parent context. That's not so different than us doing it as well, so maybe we would just do it by default.

The question will always go back to whether it actually makes sense to for consumers to actually reference values by their visible value vs always having a unique ID for them.

[hunterloftis]

In earlier testing it appeared case-insensitive, but now it's case-sensitive:

vs

I'm not sure what the right default is between these two, just wanted to point out that change.