davewhitley
commented
5 years ago Props audit
As an addendum, here is a deeper evaluation of the props for these components. This is an effort to expand the components to be more useful and to answer the question, "Are properties well thought out and consistently applied?" This only covers visual props. Event handler props will be evaluated at a later date.
TextField
Validation
Validation is complex. A simple strategy that many libraries employ is to just have a default non-error state and an error state. This means there is no "success" or "warning" state. I like the simplicity of this and seems easier to implement. It also mirrors what is available in native html5 validation.
On the other hand, it can be useful to provide the user with encouraging feedback when the they correct the error with a "success" state.
We could start small and expand if we need a success state.
- validationMessage or errorMessage or error: the error message to display if the input is invalid.
- variant: if we need more states. Accepts error, success, and warning.
✨ New
- fullWidth: 100% width of container
- multiline: makes a multiline text field (textarea)
- hideLabel: to visually hide the label while retaining accessibility.
- dense: makes the field smaller, for denser layouts
- prefix and **suffix***: Text to display before/after input value
- iconStart and **iconEnd***: Icon located at the start/end of the input
- **characterCount***: display a character counter next to the field
- required
- disabled
- readOnly
- placeholder
*nice-to-haves but will greatly improve the usefulness of the component
📋 Rename
- help → helpText
👍 No change
- label
- type
mapk
Is your feature request related to a problem? Please describe.
This issue is part of a review on the naming, structure, and composition of the UI components as brought up in https://github.com/WordPress/gutenberg/issues/16367
These are the current components that are related to text input fields that I considered in this issue:
TextControl / TextareaControl
Audit
Opportunities I came across while reviewing this component.
Suggestions
multilineprop to enable a multiline text field. Atextareahtml element would be used in this case. This aligns with thearia-multilineattribute.FormTokenField
Audit
Opportunities I came across while reviewing this component.
Suggestions
BaseControl
Audit
I could use some feedback on this one. It took me a while to understand what it actually provided and how it relates to the input elements like Radio and Checkbox. I’ve learned that it provides a label and help text for some components. In the future, I'm sure it could provide validation and RTL handling perhaps.
Different strategies I've found in other component libraries:
These different strategies are interesting to me, but I don’t know why some libraries went the direction they chose, or what the pros/cons are. Whatever we decide to do, we should weigh the options and take into consideration that we need to add field validation to some of these components. Material seems to only provide validation on text input elements. Maybe that’s why they don’t provide a help text in their FormField? Do we really need validation on checkboxes and radios, etc.? Regardless, we should have a
helptextprop on all applicable elements for ease of use.Suggestions
Aside from the features it provides, I think any of the names above are better alternatives for BaseControl (FormField, FormItem, FormControl, etc.)
Autocomplete
I wouldn't list this as a top-level component. Because it seems like an enhanced TextField or a variation, I would group it with that.
Feedback
The feedback I'm looking for is related to naming, structure, and composition. I'm not looking for visual feedback of the components. Prop audit can be seen in the comment below.