Primitive Components for Collection #5270
Description
Currently we have some components like DropDown.Group, DropDown.Item, Option for Picker, Autocomplete.Item for Autocomplete, VerticalBar.Panel and VerticalBar.Item for VerticalBar and other similar components that serve the same function in a component that defaults to Collection.
They all have something in common, they are used to render an element in a Collection the difference is that each one has its own different markup. The problem with this is that we end up having many specific components for each component, which can sometimes be a little bad because reuse and composition are different for the developer.
One idea about this is to create two main public components <Item /> and <Group /> that can be used in any Collection composition but the rendering result changes according to its context. Internally we can change what this component will render depending on where it is being used this will help us at least remove more than 6 public components by the two components, this number can be higher because there are more components for apply the Collection pattern #5032.
Some immediate benefits are for example the case at #5265 (comment), where DropDown.Group is the same markup for Picker but when in mobile mode it needs to render otherwise, ideally I didn't want to create yet another component to handle just that in Picker as a Picker.Group, so this issue raises more of a need for this to work internally and improve usability for developers.
The purpose of this issue is to propose an RFC that studies the DX of components that aim to:
- Improve compositing DX with Collection
- Improve the learning curve
- Remove the amount of components with the same pattern
- Check internal API design to change rendering context according to its parent component