Thanks for raising this. We will look into it.
Inputs.text appears to hardcode the attributes that can get passed through - which is unfortunate, given that it’s the fallback for not explicitely supported types:
Looking at the documentation for Inputs.text (here) it looks like min and max are not valid options. Instead, I think you can create a validate function to support custom validation rules.
I think it is worth suggesting adding max and min to the options for Inputs, text (and possibly the other Inputs also). Please log a feature request in the GitHub repo for Inputs. That way you will be notified when it is resolved or when the authors have questions about it.
.text() is currently the only widget that lets you override the
type attribute, and as such restrictions for
type=text cannot be applied here. The naming is unfortunate, but
Inputs.input is already reserved.
Whitelisting more and more attributes isn’t going to help either. Instead, the widget should simply pass through any option which it doesn’t handle explicitely as attribute on the element.
Please log a feature request in the GitHub repo for Inputs.
I don’t have a horse in this race, so could you please go ahead and file one, linking to this thread? Thanks!
I filed the issue and linked this forum discussion
I found that adding a validate: function leads to an unusable UI
Agreed. Thanks for raising it!
I want to create a pull request to address this issue. I plan on just adding min and max to the attributes being passed to a text input. I will write tests and also do snapshot tests.
Being a newbie to open source commits (virgin in-fact), I do have a couple of questions. Is there a preferred code formatter to use? Any special code formatting settings required? I noticed that doing a local build modified yarn.lock which is included in the git repo. Should I include my (later) yarn.lock in the pull request.
newbie to open source commits
Any special code formatting settings required?
Try to be consistent with the general style—atm this repo isn’t enforcing something like prettier rules.
I noticed that doing a local build modified yarn.lock which is included in the git repo. Should I include my (later) yarn.lock in the pull request.
That is unexpected. Did you use yarn to install it in the first place? yarn.lock should change only if you modify the list of dependencies, or use something like
yarn upgrade. A local build (with
yarn bundle) shouldn’t modify it.
These changes should not be included in the PR (unless they are actually needed, but it doesn’t seem to be the case here).
Also check that all the tests run properly (by calling
yarn test). They will be run on the server in any case, but it can save some effort.
Thank you for the prompt response. Yes I did do a yarn upgrade at some point.
Do you think I can (or should) just over-write the yarn.lock with the one in the repo?
Yes, you can undo your changes to that file, then run
yarn to “refresh” node_modules/ to the probably slightly older versions that are mentioned in yarn.lock.