New Component / Enhancement: Handle large data lists

[TheBlueDog]

Description

Applications need to be able to provide an experience that allows a user to select from items in a CVD (Coded Value Domain) in their data. The experience needs to allow the user to see the entire list through a simple interaction, in addition to being able to filter the list of option shown by typing into the input.

This may require building a new component and/or enhancing existing components for performance issues.

User Stories

A user needs to be able to select an item from a coded value domain by either scrolling through the list of items or typing into the input to filter the list option.

Acceptance Criteria

I know I'm done when:

• I can select an input and see a list of all the items in a CVD
• I can type into the input to filter the list of items
• I can use the interface with a CVD that contains more than 4,000 items with minimal performance issues
• the interface reflects the UI of other styled items in the library and platform

Helpful Details

In the Field Maps web application, when feeding the calcite-dropdown the dataset containing a CVD with 4,000+ items, some browsers would hang indefinitely, while others managed to become responsive again after 5 mins or so

In the research done by @crowjonah, he has found that native select performs best with monster amounts of options. Datalist performs pretty well, though our 4k option example takes a couple seconds when the DOM gets generated.

Doing a deferred/paged load of existing calcite-option elements is definitely the most robust solution. @timmorey did this work for a user picker list in another of our apps, built upon an Ember component (might be ember-power-select or ember-dropdown). The downside is logic gets pretty complex, and it can be tough to test.

The current solution is to use native browser elements for the input and datalist. While this solves the performance issues and meets the requirements, the UI and UX is less than desirable and differs between each of the browsers.

History on the problem and solution can be seen here: https://github.com/ArcGIS/field-apps-web/issues/951

[driskull]

I think doing a deferred approach is going to be the best from a performance and UX standpoint. There isn't a scenario where you would need to present more than 100 different options to a user and even that is pushing it from a UX standpoint. There's really no reason to create over 100 nodes and place them in the DOM for a combobox/select.

Maybe someone can work on a sample using a deferred approach which uses the combobox events to dynamically insert data into it?

[paulcpederson]

@TheBlueDog I just locally tried a combobox with 4000 items and it was slightly sluggish but overall fine. Have you tried the combobox in single select mode?

[julio8a]

Is this issue still valid?

[TheBlueDog]

Still valid