Skip to content
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

Input Transform Function #84

Open
indolering opened this issue Mar 11, 2016 · 2 comments
Open

Input Transform Function #84

indolering opened this issue Mar 11, 2016 · 2 comments

Comments

@indolering
Copy link

iron-input feels like it's striving to provide a solid interface for building more complex text-input elements but leaving the particulars up to developer and elements that extend iron-input as a base. For example, instead of assimilating a kitchen sink of common input validation settings, it provides a regex pattern for basic checks and a validation function for arbitrarily complex logic.

While the preventInvalidInput feature is handy, I think a transform function is needed to provide a complete solution and it would be handy for virtually all input types. This would allow developers to trim whitespace, lowercase text, insert or remove formatting, etc.

@notwaldorf
Copy link
Contributor

You could just do this by adding an observer for _valueChanged, and doing the transformation yourself. It sounds like a very specific feature that is easily implemented as an element consumer (unless I'm misunderstanding)

@indolering
Copy link
Author

You could just do this by adding an observer for _valueChanged, and doing the transformation yourself.

But then I have to somehow forward that information to the real on-change function, which means littering my element with convenience functions or stuffing static variables into the data-binding and using a dispatcher to figure out which function to call. I want a clean separation between input sanitization, validation, and data binding.

It sounds like a very specific feature

Honestly, I thought of it as completing the sanitization piece. Regex is good for simple stuff, but trimming input, coercing numbers, and cleaning strings (think phone numbers or credit cards) is really common.

that is easily implemented as an element consumer (unless I'm misunderstanding).

I was thinking that most dedicated child elements would need to do this anyway and it would be nice if the upstream element handled it correctly. I'm also worried about accessibility, which my boss won't pay for it unless it's an external requirement.

Would you be welcoming of a pull request?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants