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

Validator Request: required_if & required_unless #20

Closed
dawiyo opened this issue Dec 2, 2016 · 9 comments
Closed

Validator Request: required_if & required_unless #20

dawiyo opened this issue Dec 2, 2016 · 9 comments

Comments

@dawiyo
Copy link

dawiyo commented Dec 2, 2016

Would love to see required_if and required_unless rules. Maybe something similar to Laravel's.

@shentao
Copy link
Member

shentao commented Dec 2, 2016

For required_unless I think you can use the or helper.
For required_if I guess you can compose such a method, as validators are just functions that have to end up returning either true or false.

Still, this is a nice idea to have such helpers anyway. Feel free to create a PR with such functionality if this is urgent.

@furey
Copy link

furey commented Dec 3, 2016

Today I came across the need for something like a require_if_set validator.

In my case (using the same Laravel lingo) I was after a between_if_set validator.

I implemented it like so:

const { or, between, required } = require('vuelidate/lib/validators');



validations: {
    field: {
        betweenIfSet: or(between(1, 100), value => !required(value))
    }
}

Is this the recommended way to handle optional validation?

By optional I mean if it's set, validate it, otherwise ignore?

@shentao
Copy link
Member

shentao commented Dec 3, 2016

I think that’s a good approach. Actually, I think we can all work on creating such helpers and create pull requests for them. They won’t affect the bundle size so we can have really lots of them and people would be able to require just the ones they need.

@Frizi
Copy link
Contributor

Frizi commented Dec 6, 2016

I believe this validator or(between(1, 100), value => !required(value)) is pretty redundant.
between alone already accepts empty values, as all normal validators. Otherwise required would have no meaning in combination with them. We assume all fields are optional by default.

If you find it not true, please provide an example, as I consider it a bug.

@Frizi
Copy link
Contributor

Frizi commented Dec 6, 2016

@dawiyo
For required_if, you can easily construct that from or as proposed.

Imagine you have a checkbox to enable more form fields.

We can easily create a function that grabs check state and tells if it's checked. To do it we can use this in validators to access the component's vm instance. Check sameAs for another example.

function checkboxIsChecked () {
  return this.checkboxState === true
}

Later you can just use or combinator for your validator

const requiredIfCheckbox = or(required, checkboxIsChecked)

and in the end use it in your validation

validations: {
  myConditionalField: {
    requiredIfCheckbox
  }
}

It effectively marks the field as valid in presence of checked checkbox, regardless of it's emptiness.

Do you think it's enough for most cases, or any dedicated required_if or required_unless would still be helpful? I can't think of any situation when it would be more convenient on my own, but that may be highly biased opinion, as I really like functional composition.

But here we go, example implementation:

const requiredIf = otherProp => function (value) {
  return this[otherProp] || required(value)
}

const requiredUnless = otherProp => function (value) {
  return !this[otherProp] || required(value)
}

usage, in pair with previous example:

const requiredIfCheckbox = requiredIf('checkboxState')

I'm just not sure if we need it.

@furey
Copy link

furey commented Dec 7, 2016

@Frizi Understood. I have no idea how I arrived at that position. Apologies, and thanks.

@dawiyo
Copy link
Author

dawiyo commented Dec 7, 2016

@Frizi I appreciate the response and solution.

I will say this though. I understand where you're coming from with the "it's not needed approach", however in my opinion, the beauty and genius of this library is its selective import approach. I (obviously) didn't come to the conclusion of using the or validator on my own and others might not as well. My point is, where's the pain point in having a library that's exhaustive and useful in all use cases or needs? Especially when you can just import things you need.

@Frizi
Copy link
Contributor

Frizi commented Dec 7, 2016

@dawiyo I appreciate your input here, and i mostly agree, but there are a few things to add.

where's the pain point in having a library that's exhaustive and useful in all use cases or needs?

It's perfectly good approach to fill as many gaps as possible, as long as it's not making basic use cases any harder. It also means things harder to communicate are harder to use. Too many things in the docs add to the feeling of complexity and heaviness. Even if the library keeps easy things easy and weights only 1.5k in it's core!

Another trait of this library is the easiness of using custom validators or even different libraries, as validator is simply a function. That way we don't have to add every single logical combination to the core and keep it maintained.

the beauty and genius of this library is its selective import approach

Agree again, and we do want to make use of it, and because of that i'm leaning towards accepting such thing. We have to keep in mind that browser bundle has all validator in a single file though, and there are people using it.

Feel free to create a pull request with test coverage and documentation :)

@Frizi
Copy link
Contributor

Frizi commented Apr 6, 2017

This is actually present in current release :)

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

4 participants