{"action":"created","issue":{"url":"https://api.github.com/repos/aurelia/validatejs/issues/93","repository_url":"https://api.github.com/repos/aurelia/validatejs","labels_url":"https://api.github.com/repos/aurelia/validatejs/issues/93/labels{/name}","comments_url":"https://api.github.com/repos/aurelia/validatejs/issues/93/comments","events_url":"https://api.github.com/repos/aurelia/validatejs/issues/93/events","html_url":"https://github.com/aurelia/validatejs/issues/93","id":161102425,"number":93,"title":"Async validation - Promises et al","user":{"login":"jsobell","id":834155,"avatar_url":"https://avatars.githubusercontent.com/u/834155?v=3","gravatar_id":"","url":"https://api.github.com/users/jsobell","html_url":"https://github.com/jsobell","followers_url":"https://api.github.com/users/jsobell/followers","following_url":"https://api.github.com/users/jsobell/following{/other_user}","gists_url":"https://api.github.com/users/jsobell/gists{/gist_id}","starred_url":"https://api.github.com/users/jsobell/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jsobell/subscriptions","organizations_url":"https://api.github.com/users/jsobell/orgs","repos_url":"https://api.github.com/users/jsobell/repos","events_url":"https://api.github.com/users/jsobell/events{/privacy}","received_events_url":"https://api.github.com/users/jsobell/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/aurelia/validatejs/labels/enhancement","name":"enhancement","color":"84b6eb"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":28,"created_at":"2016-06-20T01:23:59Z","updated_at":"2016-06-23T10:39:25Z","closed_at":null,"body":"It seems odd that given the powerful and extensive use of Promises throughout Aurelia that they are not used in the validation module.\r\nIt seems to me that all validation rules should be promise based. Differentiating between the two (as Validate.js does) is something of a pain, and in grofit's treacherous library he's wrapped every rule as a Promise, most of which return Promise.resolve, but  this allows very easy creation of slow-running validation rules.\r\nOne issue he had was with waiting for all rules to validate, and knowing when there were outstanding Promises.  Obviously we can use Promise.all, but that has a couple of issues; it can't be 'read' by other async tasks, and any error exits without waiting for the remaining Promises to resolve (or fail).\r\nI wrote a bit of a hacked but valid example of implementing the Promise based validation process in the following gist:\r\nhttps://gist.run/?id=044f37f5e4211717f3834bef29aba618\r\nIt doesn't perform the validation (that's left for validate.js or similar) but it does show a tidy method of counting outstanding validation rules, and enabling validation methods to wait for all outstanding validation rules to resolve, and has the advantage of introducing a tri-state to enable the UI to reflect the fact that validation is still in progress.\r\nMy thought is that this can transform the current synchronous process into an async one, which allowing easy creation of custom rules, both sync and async.\r\n"},"comment":{"url":"https://api.github.com/repos/aurelia/validatejs/issues/comments/228012566","html_url":"https://github.com/aurelia/validatejs/issues/93#issuecomment-228012566","issue_url":"https://api.github.com/repos/aurelia/validatejs/issues/93","id":228012566,"user":{"login":"jsobell","id":834155,"avatar_url":"https://avatars.githubusercontent.com/u/834155?v=3","gravatar_id":"","url":"https://api.github.com/users/jsobell","html_url":"https://github.com/jsobell","followers_url":"https://api.github.com/users/jsobell/followers","following_url":"https://api.github.com/users/jsobell/following{/other_user}","gists_url":"https://api.github.com/users/jsobell/gists{/gist_id}","starred_url":"https://api.github.com/users/jsobell/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jsobell/subscriptions","organizations_url":"https://api.github.com/users/jsobell/orgs","repos_url":"https://api.github.com/users/jsobell/repos","events_url":"https://api.github.com/users/jsobell/events{/privacy}","received_events_url":"https://api.github.com/users/jsobell/received_events","type":"User","site_admin":false},"created_at":"2016-06-23T10:39:25Z","updated_at":"2016-06-23T10:39:25Z","body":"@RWOverdijk I also think it's illogical, which is why I keep pushing for option 2, and Option 1 requires the code I posted which seems unnecessarily complicated.\r\nThere's just something wrong with calling a function with a collection of rules, and not knowing if it will generate an error because I don't know which rules are sync or async. Is `rule[\"checkUser\"]` a sync or an async rule? What if I'm dynamically attaching rules; will my app start crashing at runtime with a \"no async rules allowed\" error because it turns out that \"checkUser\" was async and missed in our UI tests due to a complex run-time logic condition?\r\nI know validate.js does this, and I think it's awful, and I would suggest we do not copy it.\r\n"}}
{"actor":{"display_login":"jsobell"}}