Support for asynchronous validation

[validatorjs]

Support for asynchronous validation

[chriso]

It's fairly easy to add this yourself. Try this:

var Validator = require('node-validator').Validator;

Validator.prototype.userExists = function (callback) {
    User.findOne({username: this.str, function (err, user) {
        callback(err, !!user)
    });
}

You still need use the method asynchronously and add a callback though, so you're not really removing any..

Validator.check('[email protected]').userExists(function (err, exists) {
    //
});

[foxbunny]

Thanks for the tip. I wasn't looking at the source carefully. Do you think it can be made chainable, though? For now the callback version will have to work.

[chriso]

Hmm I'll have to think about that.. There may be a way to chain callbacks so that errors are carried forward. It does raise some questions though, e.g. what if a validation relies on previous one passing? What if you need to check whether a user exists, and then check if one of their details matches?

[chriso]

It's also worth noting (although it's generally opposed by the node.js community) that there is a way to convert these simple async methods into sync ones using fibers. I describe the technique here if you're interested.

require('synchronous')
Validator.prototype.syncGetter('userExists');

var exists = Validator.check('[email protected]').userExists(); 
//Throws an exception if the user doesn't exist

[foxbunny]

Yeah, not a trivial problem.

I'm new to the framework, so this is probably naive, but...

Would it be better to have the validation methods accept and return an independent object rather than the validator itself? Once the set-up method (#check) is adjusted to be async, that little change would allow it to handle multiple validation chains running asynchronously without creating new validation objects for each (which would inefficiently create a new set of validation methods for each object). Then we could use the set up method to break off a new validation chain to run on nextTick, allowing multiple validations to run effectively in parallel. We could set a method on the Validator prototype to handle the end of the validation chain, such as #then. We might end up with a call in our models such as validator.check('email').isEmail.then(callback).

With a validations hash (object) in a model, we could have all the validations on the object run asynchronously (though within a single validation chain it will run synchronously of course), and the change to the current API is virtually nil.

[foxbunny]

@introspectif: I sort of like the way you don't have to add a callback explicitly, and have everything resolved in an error handler. I know it's very similar to callbacks, but it's nicely tucked away from the actual validation code, and that's perfect in my book. I don't want to mix error handling code with validation, and clutter the request handlers that way.

So, the example with sychornous perfectly shows the ideal situation where you could have async code in a validator function and still keep the nice callback-less chain.

Anyway, the debate about fibers vs callbacks exploded on Node mailing list, and I think this particualr case, for me, is ideal for stuff like fibers.

@chriso: What happens if I want to add more validators here:

Validator.check('[email protected]').userExists(function (err, exists) {
    // HERE
});

Would I do it like this?

Validator.prototype.userExists = function (callback) {
    var that = this;
    User.findOne({username: this.str, function (err, user) {
        callback(err, !!user, that)
    });
}

[guileen]

I want to convert userId to User, if not exists, throw an error.

Filter.prototype.toUser = function(){
   User.findOne({username: this.str, function(err, user){
      if(err) this.error(this.msg || 'User does not exists');
      this.str = user;
   }
}

but Filter and validator does not share this.error and this.msg.

I really think Filter and Validator can share error msg str and combine check modify together.

[chriso]

I think this is outside the scope of the library. I wrote node-validator as a simple, synchronous way of validating / sanitising / filtering strings with chainable methods. Incorporating validation beyond strings (or asynchronous validators) is a bit of a far-cry from what I originally intended and IMO not the right separation of duties that you should have in your app. Also, chainable asynchronous methods are difficult to get right and would require a significant refactor.