Aurelia-validation detaches custom elements


I am trying to use aurelia-validation for client-side validation. Though the client-side validation works quite well, it forces reevaluation of the custom elements in the view. For example, a typical flow is as follows (the order in which the custom-elements are detached/“unbinded” may differ from time to time):

validation starting
custom-element#1 detached
custom-element#2 detached
custom-element#3 detached
custom-element#2 unbind
custom-element#3 unbind
custom-element#1 unbind
validation ended
custom-element#1 bind 
custom-element#2 bind
custom-element#1 attached

Naturally, re-activating the custom elements means also getting the data from the server which are needed in-order to render the elements in a meaningful way (for example, options in a dropdown, or items in a list, and so on).

Some more detail about the application: The validation rules are defined on server side (WebAPI), and an endpoint can deliver the rules for a “Entity” type. These rules are then translated to aurelia-validation rules on client-side. And then it is simple matter of using those rules with my target entity object (which can be of any “Entity” type, depending on the scenario; naturally rules are fetched accordingly). The example code looks like below:

this.clientRules = this.ruleAdapter.toAureliaRules(validationRules);
this.validationController.addObject(this.targetEntity, this.clientRules);

// and finally invoke validate when required

Please note that targetEntity is being used by the custom elements as well.

Thinking the targetEntity is being modified during validate, I also tried with following code:

const dummyEntity = JSON.parse(JSON.stringify(this.entity));
this.validationController.validate({ object: dummyEntity, rules: this.clientRules });
// naturally, while trying this code I removed the addObject call

However, this too didn’t work :frowning:

I am not sure how to isolate the problem and look for the root cause. I have posted this question in StackOverflow as well. Any suggestion in either of these two places would be really great.



I haven’t come across this behaviour - that’s not to say it isn’t a bug, but I can’t tell from the code you’ve posted.

My thought as I was reading was that you were modifying targetEntity in the validation rules - then I see you’ve tried to rule that out. What exactly was the result after “deep copying” to the dummy?

Can you reproduce this result with a small targetEntity (or subset of it)? Can you try writing some of your validation rules the “usual” way without creating them from the server? i.e.

ValidationRules.ensure((e: EntityType) => e.title).required().minLength(3).on(this.targetEntity);

If you can reproduce it like this with a contrived entity, it might help find out what rule is causing the issue.

I assume your code is private/commercial otherwise you would have posted some more?

hope this helps!


@thinkOfaNumber Thank you for your reply.

To answer your questions:

  • The result is exactly same even after trying with the dummyEntity (deeply copied).

  • I tried with a simple rule application as below. However the validation itself didn’t work.


// followed by validate() on submitting the form
  • When i tried the old style such as shown below, the validation worked, but with re-activation of custom-elements.
this.clientRules = ValidationRules.ensure("Name").required().rules;
this.validationController.addObject(this.targetEntity, this.clientRules);

The result of the last attempt was expected because the following line of code (from my original post)


does exactly the same. The validationRules is a misnomer here, this should be called more validationSpecification (whether a property is required or not, if there is any associated regex or not etc.). The ruleAdapter.toAureliaRules simply checks for those attributes in the validation specification and applies usual aurelia-validations using ensure, required, matches, minLength etc.

There is another thing that I tried is to not removing the submit.delegate on my form and rely on click.delegate of the submit button instead ([type="button"]), as I thought (??!!) submitting the form is forcing re-activation. But that too didn’t stop the re-activation.

And finally, you are right that I am not at liberty to post the actual code (it might also be confusing).


Sharing another finding if it helps. During debugging it seemed that the custom elements were detached even before starting the validation, that is before the control reaches this line. Then is it possible that the root cause lies elsewhere?


Sorry. My bad :stuck_out_tongue: it has indeed nothing to do with aurelia-validation. The solution was to change a if.bind to show.bind :joy: