🏠 back to Observable

Text Input type date not validating max nor min

Notebook demonstrating Input type=date issue

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.

@Cobus .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! :slight_smile:

1 Like

I filed the issue and linked this forum discussion

1 Like

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

welcome!

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?

Thank you
David

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.