[RFC] Intent to split terra-select into multiple packages
See original GitHub issueFeature Request
Description
We’ve been discussing the idea of splitting the terra-select into multiple packages to make it easier to maintain and test as features and bugs are worked on within the component.
Currently, there is a high amount of code reuse within the package which is good, however there is also high level of understanding one has to maintain as they work on the package to ensure there are not a regressions in one of the 5 variants in one of the many browsers, screen readers, and devices we support.
To help lower this level of understanding, we are looking to break the terra-select package into multiple packages.
Phase 1
The first part of this work would be to split the existing variants in terra-select into multiple packages as-is with the current form of the code moving from all being in 1 package to being in the multiple packages.
Phase 2
Uplift code to resolve accessibility concerns, async concerns, and any other issues we want to address as we work through this uplift.
Work needed for phase 1
For phase 1, we need to reach consensus on how we want to split apart the terra-select package. Based on discussions we’ve been having, we have the following break down.
Current Variants | Phase 1 Update | Phase 2 Update |
---|---|---|
Default | Stays in terra-select, no plans to add async option | No change |
Combobox | Moves to terra-combobox. | Fix accessibility issue with VoiceOver on iOS. Add ansync option. |
Search | TBD | Fix accessibility issue with VoiceOver on iOS. Add ansync option. |
Multiple | Moves to terra-multi-select. | Fix accessibility issue with VoiceOver on iOS. Add async option. |
Tag | Moves to terra-multi-select. | Fix accessibility issue with VoiceOver on iOS. Add async option. |
Some questions with this:
- What do we want to do with the
search
variant of the current terra-select?- We already have a terra-search-field
- Does this become terra-autoselect?
- Does this become terra-search-filter?
- Are there other use-cases teams have needed that we should consider?
- How to handle async:
- React-select provides separate components for the async version of react-select.
import Async from 'react-select/async';
- https://react-select.com/home#async
Some details of Phase 2 may be flushed out more as we get closer to that part of the update, however, it would be good to discuss parts of phase 2 as we work on phase 1.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:4
- Comments:11 (11 by maintainers)
Top GitHub Comments
After more discussion, we’ve landed on continuing to keep 1 package, terra-form-select. Instead of splitting this package into multiple packages, we’ve discussed splitting the rendering of each variant into its own file and having Select.jsx act as an abstraction layer of the different renderings using the variant prop to drive a switch statement for selecting which rendering to use.
There is some logic for this already in Select.jsx
We’ll be separating the rendering even more so than it currently is.
The pros of this include:
Potential diff for multi-select.