Validator Request: required_if & required_unless

[vuelidate]

Validator Request: required_if & required_unless

[Frizi]

@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]

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.

[shentao]

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]

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]

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]

@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]

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

[dawiyo]

@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]

This is actually present in current release :)