Validators API

[mohsen1]

My proposal:

each schema can have a validators property which is an array of validator objects. A validator object have the following properties:

• message(string) the error message shown if validation fails
• fn(function) validation function that can return boolean, accept the user input and a callback or returns promise that resolve to boolean

The validation functions will get executed with the array order and if all validations passed the entry is valid. The validator starts with leafs of the Schema tree and crawls up to the root of the schema.

Example

{
  type: "object",

  "properties": {
    "email": {
      "type": "email",
      "validators": [
        {
          message: 'You were unlucky!',
          fn: function(){
            return Math.random() > 0.4; // :D
          }
        }
      ]
    }, 
    "password": {
      "type": "password",
      "validators": [
        {
          message: 'Password can not have letter M in it!',
          fn: function(password) {
            return password.indexOf('M') === -1; // ?!?
          }
      ]
    }
  }, 

  "validators": [{
    message: 'email and password should not be equal',
    fn: function(obj) {
      return obj.password != obj.email;
    }
  }]
}

[bvaughn]

Might be nice for custom validation functions to be allowed to reject with an error message that overrides the one specified in message.

[bvaughn]

In general, I also prefer more descriptive attribute names (ex "function" vs "fn"). I realize that function is one of those special words, but maybe something like validator? or method?

[mohsen1]

How about this: You can return (or resolve to) boolean or string(custom error)

I'm open for a replacing fn with something more meaningful

[kentcdodds]

I must say that I am against the JSON schema-like format of having field configuration separate from the validation config. I think that field config should be able to stand on its own. It is much easier to build abstractions for different field types this way.

[bvaughn]

Could you clarify a little Kent?

Are you proposing that the full form markup should be generated from a single configuration object? Or something else...

[mohsen1]

@kentcdodds I'm not sure if I understand your concern correctly. Each filed can have it's own list of validators and is completely independent from it's parent and siblings. For example email itself in my example is a complete schema.
Being recursive is a key feature of JSON Schema

{
      "type": "email",
      "validators": [
        {
          message: 'You were unlucky!',
          fn: function(){
            return Math.random() > 0.4; // :D
          }
        }
      ]
    }

[kentcdodds]

Ah, I think I misread that. Sounds good to me. I don't mind the fn abbreviation. In angular-formly, I use expression because it can either be a string expression (as you'd see in an angular template) or a function. But fn I think is pretty well accepted by people. Also, would probably be a good idea to make it be an object instead of an array. That way you can override validators. This follows the $validators api of angular which I think was a good decision.

[mohsen1]

@kentcdodds overriding validators sounds interesting! Can you write an example of that? I'm not sure I did understand it right.

[kentcdodds]

Type definition:

{
  name: 'foo',
  defaultOptions: {
    validators: {
      isFoo: function(val) {
        return val === 'foo';
      }
    }
  }
}

then later, in a field definition:

{
  type: 'foo',
  validators: {
    isFoo: {
      message: 'That is not foo!',
      pattern: /^foo$/ // <-- just kinda threw that in there, I think we should allow them to specify a fn, a pattern and anything else that makes sense :-)
    }
  }
}

[kentcdodds]

Oh, also notice that in the type definition, the validator isFoo is a function. In this scenario, it would be the same as:

{
  isFoo: {
    message: null,
    fn: function(val) {
      return val === 'foo';
    }
  }
}

[bvaughn]

+1 for using named validations. I like the flexibility of being able to override requirements for a specific context.

Although this kind of raises another question- if our validations are spread across multiple schema files- how do we pass them to form-js?

[mohsen1]

forms-js should not solve that problem. User have to pass everything in one object or write custom validators that call third party validators.

[bvaughn]

Sorry, let me rephrase. My question is higher-level than that: what interface does forms-js expose for validations? (How do you pass any validation to forms-js.)

[mohsen1]

oh you mean global static validators?
I think we should avoid that. It's going to lead to a lot of surprises. The most global validators list is the one in the schema root