-
-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Binding behaviors "validate" and "updateTrigger:'blur'" don't mix #423
Comments
@RomkeVdMeulen I don't see |
Hmm, seems that when on gist.run I fork the gist mentioned in the issue template, it overwrites any previous fork of the same gist I already had. You were looking at the gist I wrote for that doc section. I've manually recreated and cloned the gist, so hopefully this one won't be overwritten: https://gist.run/?id=90009f5381244e168efcfe46e8c886ac |
Any suggestions on this? It's blocking our adoption of aurelia-validation. |
Haven't looked at this yet. Have you tried the validateOnBlur binding behavior in place of the validate binding behavior? |
I have: same result. |
Hi @RomkeVdMeulen, I tried this with validateOnBlur and validation occurred with the newly entered value.
Here is a gist which (I believe) gives the behaviour you want? Admittedly, the model does not get updated on blur with this so may still not be what you want. Edit
I get the same result, the old value gets validated, not the new one. |
@alastair-mcdonald The Results probably vary by browser. Both behaviors add an event handler to the blur event, and AFAIK it's up to the browser to decide which to call first. Some may see the new value being validated, some the old one. Is this something Aurelia can solve? It's going to be difficult to have two listeners to the same event always being called in a particular order. |
@RomkeVdMeulen Perhaps Aurelia could hook up a single event handler for blur which specifies all the behaviours which are to be carried out by the blur event, so enabling Aurelia to control sequence. Not sure how much of a change that would require internally for Aurelia though; possibly a breaking change needed. |
I've decided to hack around this problem. In my case I was using it like this:
The intention here was to normalise the user-entered value on blur and, if necessary, update the input with the normalised value. To ensure the normalised value is validated, I'm manually triggering another blur event after updating the input in my binding behaviour: const updateSource = binding.updateSource.bind(binding);
binding.updateSourceOriginal = binding.updateSource;
binding.updateSource = function(value: any) {
const normal = normalise(value);
updateSource(normal);
if (normal !== value) {
/* Update view to normalised value */
this.updateTarget(normal);
/* Trigger blur to ensure other listeners, like validation,
* are triggered again on the normalised value. */
binding.target.dispatchEvent(new FocusEvent("blur"));
}
}; Not ideal, but at least I can finally proceed. |
I'm seeing a similar problem with this binding: If I type and blur quick enough, an old value is validated - sometimes even the empty value before I started typing! Then if I focus the input and blur it again, the correct value is validated. |
Any plans for fixing this issue? Will aurelia@next handle it correctly? |
As a workaround for when I am using a Value Converter with udpateTrigger:'blur', I replace validate with validateManually, and then use blur.trigger to call a method that manually calls validate for this property. View: ViewModel: But would be great if |
I'm submitting a bug report
Library Version:
1.0.0
Browser:
Chrome 55
Current behavior:
When applying both the
updateTrigger:'blur'
andvalidate
binding behaviors to a binding, the value is validated before it is updated.See https://gist.run/?id=c533e53e62cb348cc96aa9445bae612a and note when entering characters and blurring the input the validated value is always the previously entered value.
Expected/desired behavior:
The validation should only run after the source value has been updated. This should also work when using
validateOnBlur
rather thanvalidate
in the same scenario. I'm not sure how something likevalue.bind="myVal & updateTrigger:'blur' & validateOnChange"
should be handled - perhaps a warning against this in the documentation would suffice.The text was updated successfully, but these errors were encountered: