Refactor combobox and select for readability, code sharing, and API consistency

[atmgrifter00]

🧹 Tech Debt

After recent work on these components we feel that the codebase isn't as easy to work in as we would like and there are opportunities to improve API consistency. We should focus on improving this. As a side effect (but not the primary goal) this could also include:

Tasks

Beta Give feedback

1. Sever dependency on FAST Listbox from Nimble Select/Combobox #2058
   tech debt +1
2. combobox adopting registerOption from select (see note 1 below)
3. Combobox should stop altering hidden state of options #1902
   tech debt +1
4. combobox autocomplete modes are different from select filtering modes (e.g. diacritic insensitive search)
5. better isolation of related component state. For example, should we have a separate keyboard manager and selection manager like we do for other components?
6. Nimble dropdown components don't match native select option behavior #1915
   tech debt +1
7. Add a way to show a progress indicator while fetching items for combobox #2277
   enhancement +1
8. combobox supporting "Grouping" feature that was added to select
9. Ability to clear the selection from nimble-combobox #2008
   enhancement +1
10. Align rich-text mention listbox implementation behavior #1926
    tech debt +1
11. Combobox ControlValueAccessor should always reflect the value from the input #1168 (this will also be prioritized independently as part of client adoption of select features)

1. The initial attempt to align the Combobox implementation with the Select resulted in a bug in Angular, where the options would ultimately remain hidden upon a reload of the DOM after they had been filtered out. The cause of this seems rooted in the new registerOption implementation, but it's unclear at the moment exactly why this is resulting in the new behavior.

[atmgrifter00]

Ideally, as part of the work to re-align the Combobox with the Select we would also provide a test case that the linked AzDO bug above is representative of. This may be a bit tricky because it involves a re-loading of an Angular component that was hosting the Combobox.

[jattasNI]

@atmgrifter00 we are trying to figure out how to prioritize this tech debt but I think it contains several issues that might have differing priorities. Could you take a pass at listing those and bucketing them into separate issues if we think we should fix them separately?

Brainstormed possible issues with Milan:

• registerOption
• visuallyHidden to track filtered items
• diacritic insensitive search

[jattasNI]

Here's some additional tech and/or architecture debt that might be covered by this.

1. coupled responsibilities of FAST foundation Listbox base class and Nimble concrete derived classes. See Sever dependency on FAST Listbox from Nimble Select/Combobox #2058
2. better isolation of related component state. For example, should we have a separate keyboard manager and selection manager like we do for other components?
3. ensure synchronous state management to match the native select behavior (or be very clear about when we diverge from this). See Nimble dropdown components don't match native select option behavior #1915. Matching native behavior is important because the Angular CVA assumes we do.

Re-adding the triage tag to trigger a discussion about whether these should be separate issues and what their priority is. Hopefully we can prioritize at least some of it because we had multiple instances of select changes unexpectedly breaking client apps and needing to be reverted and we believe these issues contributed to that happening.

[jattasNI]

@atmgrifter00 and the team agreed that he'll work on these issues this cycle and come up with a recommendation of how to split up the work once he's done some initial research. This will be be prioritized after the first 1 or 2 SLE combobox -> select migrations.

[rajsite]

Also need to consider dynamic options equivalents for combobox (i.e. combobox analog to select's filter-mode manual)

[jattasNI]

With Meyer's help I repurposed this issue to be the grab-bag tech debt issue and linked to all the sub-tasks that might be part of it.

[rajsite]

Another item I'd like to see in the alignment design (and might be a bigger set of trade-offs to discuss). It would be "ideal" to have some technical outcomes:

• We did not rely on light dom id associations. Let users completely own ids, also meaning they could do bad things like have duplicate ids on the page. We won't care because we don't rely on ids
• Have the aria presenting target (element that announces the role) be in the shadow root. Currently it's inconsistent, the combobox has an input in the shadow root that is the main aria presentation when the select host element is the aria presentation.
• Drop the element internals polyfill support that has us creating an input element in the shadow root and switch to using element internals directly: https://developer.mozilla.org/en-US/docs/Web/API/ElementInternals
• Switch to popover api for placing an element in the top layer and to calculate positioning find an anchor positioning polyfill / use a library like floating ui.
• Using the native picker for mobile platforms for selecting an option instead of the rendered popup