Remote validator.

[piotrkowalczuk]

New option that gives posibility to validate form by external application eg by http request to backend server.

[ljharb]

Can you elaborate a bit on this one? Remote validations aren't generally possible, because they're async, and form validation usually needs to happen synchronously.

Adding the possibility for an async validation seems like a pretty big feature, so I really want to make sure I understand the use cases first.

[ljharb]

Please don't ever use loops :-) Object.keys(form.fields).forEach(function (fieldName) { … }) would be much better.

[piotrkowalczuk]

I use this library in my project and i like it. Our backend architecture has changed. Only one who knows something about validation is backend server, but the frontend server render a html.

Its not a problem that validation is async. I corrected the code and updated the tests

[ljharb]

why would you want/need to bypass default validators when setting the remote one? If you don't want local validators, you wouldn't set any

[artnez]

This should be implemented as a form validation hook. All you're doing is calling an additional async function on form validation success and assuming a very specific interface for the response.

Also calling it a "remote" validator is unnecessarily specific. What makes this "remote"?

I suggest an alternate implementation that would be more generalizable.

Created a validators array on the unbound form object (unbound_form.validators). This would be an array of validation callbacks that are invoked when bound_form.validate() is called. By default, there would be one validation callback which mimics the current behavior.

So bound_form.validate would invoke every callback in unbound_form.validators in an async series.

[piotrkowalczuk]

Whats your opinion now?

[artnez]

Cool! Extensible form validators like this will be very useful.

One issue though. IMO the async validator should be dropped entirely. All form validators are async, so the name async is redundant (remote isn't appropriate either due to reasons mentioned above). Everyone is going to handle backend responses differently anyway. The current implementation of the validator assumes everyone handles remote errors like you do.

If there did exist stock form validators, they should conform to some common interfaces used by frameworks like Rails or whatever.

[ljharb]

Please make sure all files have a trailing newline.

[ilkkao]

I was little surprised that inside my custom validator I can't make async redis call to check if the account name user is proposing is reserved already and call callback() based on the result inside the redis callback. I think this is a very common use case. I'm not even sure what could be a workaround.

@piotrkowalczuk your PR has some extra files and unnecessary white space fixes. Maybe just create minimal PR that supports async custom validators.

[ilkkao]

There was a solution. I make async validation now separately and set form.fields.account.error if there's an error before re-rendering the form. It'd still be nice to get a validator based solution if possible.

[ljharb]

Please globally gitignore IDE-specific project directories, and please rebase this one out of this PR.