How can we improve Breeze.js?

Asynchronous validation

I'd like a feature that will consent to perform asynchronous validation.
Actually, a custom validator like the one below will always return as undefined so a falsy value. It would be great valFunction will be evaluated after the db response.

function createExistingUsernameValidator() {
var name = 'existingUsernameValidator';
var ctx = { messageTemplate: 'Existing username', displayName: "Username" };
var val = new Validator(name, valFunction, ctx);

return val;

function valFunction(value, context) {
var result = ko.observable(true);
require('services/datacontext').getIsUserByUsername(value, result)
.then(function () {
debugger;
return !result();
});
}
}

16 votes
Vote
Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Angelo Chiello shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

6 comments

Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
Submitting...
  • RockResolve commented  ·   ·  Flag as inappropriate

    For other readers benefit ...
    My use case was to validate my entity's foreign key against an entity that may not have been fetched from the server. I had thought the lack of async validation meant this was not practical.

    But the solution is simple:
    Create a "Fetching ..." error while the fetch is pending. Add it as a keyed validationError.
    Once the fetch completes, either update the keyed validationError if the fetch fails, or remove the keyed validationError if the fetch succeeds.

    This means the entity can't be saved until the fetch is resolved (which is what I want for my use case), and so my entity's foreign key is always validated.

  • Ward Bell commented  ·   ·  Flag as inappropriate

    We hate to disappoint. We just don't know what to do about it. We don't understand the scenarios in which this feature would be beneficial.

    For example, what do you do in a form when the user "pages" away while the async validation is in-progress? Should the user be allowed to leave or not? How would the user return if there were a problem?

    How should saveChanges work? At least saveChanges is already async so we could plumb async validation through it. But do you process the save before the async validation returns? I think not. It's not acting as a validation then and if the server rejects it, you now have two competing validations for the same rule. But maybe you'd expect something different?

    My point is that the problem is not as simple as firing off a validation. You have to work through the consequences. I don't know what the right thing to do is in all scenarios for all apps. I don't know where to put the hooks so that we can offer a facility that everyone can use appropriately.

    We're not talking about a "fix" here. This needs real thought. We wouldn't know what to implement until we had good answers.

    On the other hand, it isn't difficult for you to write application-specific async validation logic that does exactly what you want. Post your scenarios to StackOverflow and we can all work through this together. Maybe the proper implementation of a feature will become apparent when we've worked through some real use cases.

  • Angelo Chiello commented  ·   ·  Flag as inappropriate

    Ward,
    I completely understand your point and I am agree. I don't have so much experience to understand if a breaking change in validation chain worth it.
    Right now, I solved my original problem with KO Validation through Breeze. I am using KO Validation for other cases in my web app.
    That solution is not "embedded" in the whole app as I wish but all in all it works. I mean, the code is not so elegant as a native breeze async validation.

  • Ward Bell commented  ·   ·  Flag as inappropriate

    In my experience, async validations rules require such different treatment that they imay be impractical to implement them along side the synchronous validation rules we have today. Validation rules are often used to decide whether a process/workflow can go forward or not. The processes/workflows that consult those rules are generally not written to wait. For example, the Breeze EntityManager.saveChanges does synchronous validation and will not wait. Perhaps there is a way to change that without breaking existing applications. I would favor this proposal **if we plumbed asynchrony consistently throughout Breeze validation processing and provided some way of detecting when async validations are in flight**. Until then, you are better off implementing asynchronous checks (such as uniqueness tests) directly in your validation logic rather than through Breeze. In sum, it's worthy of review in the context of these broader design and implementation implications.

Feedback and Knowledge Base