SeamusLeonardHPE
commented
7 months ago Open issues
Bugs https://github.com/grommet/hpe-design-system/issues/3741 Accessibility https://github.com/grommet/hpe-design-system/issues/3622 Dateinput https://github.com/grommet/hpe-design-system/issues/3736 Dateinput https://github.com/grommet/hpe-design-system/issues/3145
Research & refactor existing inputs to use a more atomic approach to their build. This will ensure better consistency & maintainability.
These changes will likley create breaking changes for product design teams so we need to factors a release strategy that may include versioning, batch release or trickle rollout
- [ ] input type="button"
- [ ] input type="checkbox"
- [ ] input type="color"
- [ ] input type="date"
- [ ] input type="datetime-local"
- [ ] input type="email"
- [ ] input type="file"
- [ ] input type="hidden"
- [ ] input type="image"
- [ ] input type="month"
- [ ] input type="number"
- [ ] input type="password"
- [ ] input type="radio"
- [ ] input type="range"
- [ ] input type="reset"
- [ ] input type="search"
- [ ] input type="submit"
- [ ] input type="tel"
- [ ] input type="text"
- [ ] input type="time"
- [ ] input type="url"
- [ ] input type="week"`
Consideration for masked inputs also
Exploratory work here https://www.figma.com/file/8EqTWkAB2JhQhR5Aiub4ZW/%233685-Input-refactor-experiments?type=design&node-id=0%3A1&mode=design&t=qil4Ljx5Y3qFz486-1
CillianHPE
Follow on to https://github.com/grommet/hpe-design-system/issues/3675
"Architecturally, to provide consistency and reduce maintenance, can we build a FormField component which wraps a child input. The FormField provides the label, description, info/error messages, and validation states. Then the various inputs are only worried about the input's internals and doesn't have to worry about it's outside elements. If we don' have an existing issue for this refactoring, please create one."
Explore alternative ways to atomically refactor the numerous "input" components. Input components only contain placeholder, value, state, focus, validation
Options for the 'input container'
1 - Create a parent "input container" that hosts "slots" for our various inputs Cautious of performance for this approach, also would we need to create instances for each input type?
2- Create 2 components to stack alongside the input components
Considerations How would these approaches impact using nested components inside "multiselect" "checkbox group" "radio group" How would this impact "form field" variants, should that even be a core part of individual inputs