Closed davewhitley closed 4 years ago
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.
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.
*nice-to-haves but will greatly improve the usefulness of the component
I'm closing out the Component Audit issues for now.
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
multiline
prop to enable a multiline text field. Atextarea
html element would be used in this case. This aligns with thearia-multiline
attribute.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
helptext
prop 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.