-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Masked inputs / customizeable input fields #1003
Comments
Thank you for requesting this feature, we value your feedback! We had a few rounds during development on how we wanted to do component compositions and such. We ended up with the current implementation of We'll bring this up at our next planning meeting this week and we'll get back to you! 😄 |
We have looked over this feature on todays planning and decided that we need to do a spike in terms of technical re-write, features, impact on other components and accessibility issues that might arise. #1015 Hopefully after we do the spike we can come with a more concise answer on what we want to do with this feature 😅 |
Sure thing! I believe you should be able to preserve most a11y functionality by going this route (although for custom/masked fields I believe that should be the developers responsibility). Imo, from EDS' perspective I believe the approach should be exposing a set of fields, to be used e.g like this:
I would expect Label, TextField and HelperText a11y to work out of the box. However, if I want to create an input mask for phone numbers (like my example), I would expect to have to type that out myself. It would also be possible to use e.g React.cloneElement() in my codesandbox, where you could automatically wire up the label to the textfield with a generated id. Like I said, I just slapped it together really quickly and I'm 100% certain there are multiple ways of improving on my example :) Let me know if you want any input from me :D |
This is partially facilitated by |
Describe the solution you'd like
At the moment EDS supplies some very specific input fields, but we use a fair bit of customized fields (e.g masked fields, but also fields that formats numbers with 1 000 separators and similar). I experimented a bit with this, and my solution was to write a FormField wrapper, that applies styling to the children. This allows reuse, and maintaining the styles with more flexibility.
(Obviously this might not be best practice and could probably be optimized / rewritten in a better way.)
See codesandbox example
A different approach would be EDS exposing a field that takes in either children for just the input-field, render-props or similar (for masked inputs):
This approach is more limited, but could also be feasible.
Describe alternatives you've considered
Writing all our fields w/ styling from scratch, but this seems tedious / repetitive. If EDS would facilitate this, it would be easier to avoid straying far away from the EDS design.
The text was updated successfully, but these errors were encountered: