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

Add option to automatically validate #34

Open
adalinesimonian opened this issue Jun 14, 2015 · 5 comments
Open

Add option to automatically validate #34

adalinesimonian opened this issue Jun 14, 2015 · 5 comments

Comments

@adalinesimonian
Copy link

First of all, if this already is possible/exists, please, banish this issue to the shadows!

If not, though, here's what I think would be super swell:

What

  • auto-validate property:
/**
 * If true, automatically validates the input element whenever its value is changed.
 *
 * @attribute autoValidate
 * @type {boolean}
 */
autoValidate: {
  type: Boolean,
  value: false
}
  • Relevant changes in _bindValueChanged:
_bindValueChanged: function() {
  if (this.value !== this.bindValue) {
    this.value = !this.bindValue ? '' : this.bindValue;
  }
  // manually notify because we don't want to notify until after setting value
  this.fire('bind-value-changed', {value: this.bindValue});
  if (this.autoValidate) {
    this.validate();
  }
},

Why

Currently, validation is already easy. Not saying it's hard. Call validate(), and bark at the user for writing any despicable input.

But here's a use case that currently (to my knowledge) isn't possible as written:

<my-validator></my-validator>

<input is="iron-input" validator="my-validator" bind-value="{{value}}"
  invalid="{{valueInvalid}}" auto-validate>

<label hidden$="[[!valueInvalid]]">
  Oh what in heavens are you thinking? That's not even <i>remotely</i> valid input.
</label>

Instead, I've been doing this:

<my-validator></my-validator>

<input is="iron-input" validator="my-validator" bind-value="{{value}}"
  invalid="{{valueInvalid}}" on-input="revalidate">

<label hidden$="[[!valueInvalid]]">
  Again with your invalid input?! Go to the corner and think about your life.
</label>

<script>
...
revalidate: function(e) {
  e.target.validate();
}

It would be much nicer to be able to do it all declaratively and get rid of that one extra handler. It seems to me that when there is a bindable, notifying invalid property that it would seem logical to have the option for it to have its value populated automatically if desired.

@adalinesimonian adalinesimonian changed the title Option to automatically validate and provide bindable "valid" property Option to automatically validate Jun 14, 2015
@adalinesimonian adalinesimonian changed the title Option to automatically validate Add option to automatically validate Jun 14, 2015
@notwaldorf
Copy link
Contributor

Have you checked out paper-input? That already has an auto-validate property. You can use it like this:

<paper-input label="only type letters (auto-validate)" auto-validate pattern="[a-zA-Z]*" error-message="letters only!"></paper-input>

Is there a reason why you want it directly on iron-input? Is it because you don't want the paper style that comes with paper-input?

@adalinesimonian
Copy link
Author

paper-input is fantastic! Sometimes, though, it feels like bringing everything and the kitchen sink.

I think that having validate() begs the need for a feature such as auto-validate, which is far from being a complex addition that would turn iron-input into something other than the simple element that it is. Many times when I (and I would like to assume others) would prefer to use an iron-input instead of a paper-input, it'd be because

  • iron-input has no UI preference
  • they're throwing together a very lean/lightweight app/page and trying not to bring along more code than is necessary

And in those cases, instead of having to wire up some odd handler to get validation up and running, or dragging paper-input in with all its styles and dependencies, it'd be much simpler to throw in an iron-input, set auto-validate to true, and done! If the user wasn't using hidden$= but a CSS rule targeting the iron-input's [invalid] instead, they wouldn't even need a dom-bind template!

So, that's my two cents. I think auto-validate could be a super nifty thing to have on iron-input, and it wouldn't be bringing too much baggage along. I'm certainly not asking that paper-input-behavior gets shifted down to iron-input, that'd be too much. But, auto-validate? I think that the cost of throwing it in far outweighs the cost of not having it.

But that's just me, and I don't make the decisions 'round here (until I start bribing everyone with free coffee).

@notwaldorf
Copy link
Contributor

If this isn't urgent, I'd like to wait a bit and talk it over with @morethanreal before we decide on anything.

@notwaldorf notwaldorf self-assigned this Jun 16, 2015
@adalinesimonian
Copy link
Author

It's certainly not urgent! Better to make a well-thought-out decision instead of rushing into anything, so I'm all for more discussion.

@kshep92
Copy link

kshep92 commented Nov 17, 2016

I agree with this one. I don't always want to use the paper elements, so a 'validate-on-change' feature would really be nice, especially since I'm a big fan of how easy it is to hide/show 'as-you-type' error messages in AngularJS.

@notwaldorf notwaldorf removed their assignment Aug 24, 2018
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

3 participants