Please cast your vote for a proposed change to validation@v2

vNext
1

Hi,

The aurelia project would like to ask the community for help. We would like to get your vote on a change proposal to how validation is triggered in v2 vs v1.

Details + the option to vote can be found here: https://fast-poll.com/poll/results/d9794d9f
In case you vote for “I think this is a bad idea”, leaving a comment with a short motivation, either here or at the voting site would be highly appreciated

Thanks!!!

2

I voted against, there have been some studies indicating that immediately displaying error messages or while typing is bad for UX, for example: https://alistapart.com/article/inline-validation-in-web-forms/

That being said, I think it depends on the audience/customer… Could this be a plugin-level configuration? If you were to configure this behavior globally, I wouldn’t really care what the default is.

3 Likes
3

Good article. Its clear that it depends on the use-case and type of field. The developer can of course change it on a global level and on field level. The change is to change the global default. The article mentions that one of the reason is the reduced form completion time when validation happens on every key-up and the user waiting for the feedback before typing ahead… If that is the case (takes too long to provide feedback) then I would vote against it for sure!

2 Likes
4

IMHO it depends. In most cases that I can think of it’s better to validate when losing focus. A typical scenario where validation-as-you-type is favored is validating password strength.

2 Likes
5

I’m not going to vote as I don’t want to sway it either way. I use both scenarios. Just make it a required configuration or leave it as is.

1 Like
6

I voted yes. As long as there’s a way to change the default in the config, I’m fine with it.

7

What is HTML validation doing here? I believe it validates on blur (but I might be wrong, there may even not be a standard). I’d say: when in doubt, follow HTML standards

1 Like
8

I agree, if there is standard, follow that. I’d personally rather not see a breaking change for something like this.

One of my forms requires instant saving so we validate on change with throttling
Another area we don’t validate until blur.
And one case, because I was running into issues with some custom controls I built, I don’t validate until a button is clicked.

1 Like
9

Its not about HTML validation. Its about user (form) input validation. There isn’t a standard that we could follow. Its a matter of preference mostly.

1 Like
10

Though a tad bit late to the party, I want to point out couple of things.

Firstly the changrOrEVENT trigger (where EVENT is blur or focusout) does not trigger the validation until the field is either validated by one of the EVENT-triggered validation or manual validation. Once the field is validated, every change in the field will trigger the validation. Apart from this, also note that the EVENTwill not trigger validation if the field is not dirty; for example, you focus the field and then leave it without change, the validation won’t be triggered as the field is not dirty. This change of behavior has been introduced in aurelia-validation@2.x. Here are the relevant resources in case you have missed it:

This serves 2 purposes:

  • Reduce yelling at user when she/he has not finished typing the input, and thereby delaying the punishment.
  • If the field has already failed validation, and user is making correction (changing the field value), provide early feedback by validating eagerly, and thereby reward early.

The motivation behind this change is to provide better UX. BTW the originally @jods4 told me about this idea of “Reward early, punish later”, and I took that to heart.

Anyway, coming back to the issue at hand. It is clear that using changeOrEVENT trigger won’t necessarily provide feedback for every change and the validation is triggered pragmatically. In comparison to the change trigger, this should reduce triggering the expensive validation rules needlessly.

Naturally, the same behavior is also incorporated in Aurelia 2. As blur is the default trigger, used in aurelia-validation, focusout has been kept as the default trigger in Aurelia2 validation (as the event focusout works for larger use-cases, and quite well supported by browsers). However, with blur or focusout there is no dual behavior like changeOrEVENT trigger, and the validation is triggered whenever the event is raised(in accordance with aurelia-validation).

Therefore, in the light of the changed behavior of the changeOrEVENT trigger , the question at hand boils down to whether focusout being the default trigger serves better than the changeOrEVENT trigger, or not?

I am bit biased to say that thechangeOrFocusout trigger serves better as the default trigger. However, it really depends on the use-case at hand. But whatever the OOTB default trigger is, you can always change that as per your need when you register the plugin (refer the Aurelia2 doc).

I hope this clarifies some of the questions raised.

2 Likes
11

@sspilleman there is indeed HTML validation. See " Using built-in form validation" here:

I don’t see (or perhaps I missed) mention of when validation is triggered, but by using the demos on that link it feels like the change event.

2 Likes
12

Yes there is, but thats not related to what this aurelia plugin is doing… Plugin is doing custom javascript validation, aurelia style and optionally give you the tools to e.g. display elements or implement styling to element to provide feedback. This discussion is about how/when the javascript validation is triggered.

1 Like
13

@mcorven My previous experience with the native validation is that different browsers displays different behaviors for same validation rule. However, frankly I have not went down that road for a long time. Can you please share your experience with that?

It is a nice thing that you have pointed out. Aurelia has always stayed close to the standards, and if the HTML validation is working nicely for all browsers, I sure won’t mind to extend the support.

1 Like
14

I was referring to input validation on HTML form controls as @mcorven mentioned

1 Like
15

@Sayan751 I don’t have much to say in any means of defense to HTML input validation, only because I’ve never used it. However I do consider it the default input validation pattern and implementation, and I see it’s distinctly recognizable validation message popups from time to time, especially on login forms - perhaps I can reach to defend it by saying that it offers the only validation implementation without involving JavaScript - although you can since it’s fully accessible via the native events and public methods.

I’m only suggesting that we consider it as a factor for consideration - as long as we are remaining true to Aurelia’s roots. The validation message styling does differ by browser engine, but at least between Chromium and Firefox I see that they are consistent in rendering as I press keys - not on blur.

2 Likes