Spike consequences of de-coupling Textfield and providing each individual sub-component

[mimarz]

Spike what needs to be done technically in terms of breaking up TextField and providing its inner components as individual components. Check what we loose or/gain in terms of a11y, affecting other components and margin of boilerplate needed to make a standard Textfield

related to #1003

[wenche]

This should probably affect other form components as well.

• Selection controls (radio, checkbox and switch)
• Select
• Search
• Slider (?)

If we manage to do this in a thoughtful and consistent way, things will be a whole lot easier for #1033 , #1003, #801, #1035, #1034, #960, #939 and the input elements inside tables stuff.

[wenche]

Approach

@mimarz and I just discussed the approach for moving forward with this, and we both feel that it should be a "Yes to both ways" approach. That means we should provide both a TextField component for those who needs a ready to use TextField component out of the box along with individual components if one needs more control, adjustments or flexibility.

This is also the way Material UI solves this, and will (hopefully) reduce the amount of times spent for end users to migrate.

Today's solution

TextField

• Consists of Label, Input and HelperText. These components are not exposed.
• Label is optional
• Label is connected with a for/id relationship.
• The Label component provide support for meta text
• When a label is not used, you could use the aria-label or aria-labelledby. However, this is not documented not to mention mandatory

Selection controls

• Consists of an Input and a text.
• Label is mandatory
• The input and label text is wrapped in a html label element
• It is technically possible to add an aria-label or aria-labelledby but this will not affect the mandatory label text
• Validation or helper text must be done outside of the component itself

Select

Native

• Consists of a Select and a Label. The Label element is the same as for the TextField, but it's not exposed externally
• Label is mandatory
• Label is connected with a for/id relationship.
• The Label component provide support for meta text
• It is technically possible to add an aria-label or aria-labelledby but this will not affect the mandatory label text
• Validation or helper text must be done outside of the component itself

Single and Multi

• Consist of Button, List, Input, Label and Icon. Only Button, List and Icon is exported externally. The Input and Label element are the same as in TextField
• List and Button is restyled to reflect the design
• Input element has some added padding styles for placing the dropdown arrow button
• Label is mandatory
• Meta text is supported by the Label element
• It is technically possible to add an aria-label or aria-labelledby but this will not affect the mandatory label text
• Validation or helper text must be done outside of the component itself

Search

• Consist of an Input element, but not the same as the TextField
• Has no visible label
• Provides an optional aria-label, with a default text of "search input"
• Validation or helper text must be done outside of the component itself

Slider

• Slider is so complex
• Does not have a label in Figma or in code
• Validation or helper text must be done outside of the component itself

[wenche]

• Use htmlFor instead of inputId in TextField