Cross field validation and customized feedback visibility based on interaction states and types

[jorenbroekema]

Hi.

In a pet project I decided I needed an authentication form and I used Lion for it mostly because validators are so easy to create and it has all the behavior of showing/not showing feedback based on interaction states already working.

The form ended up pretty cool and it works very nicely, here's a small gif. Yes, it's both a form for logging in and signing up, my auth form component transforms the form on demand.

https://i.imgur.com/uVRhngW.gif

I ran into a few things that I implemented, but that I think could be improved on lion's end.

Cross field validation

The example here is the password match validator. This was quite tricky to get right, because of a few requirements:

• Validation should happen on both the primary password input and the confirmation password input, and it should be in sync
• Showing feedback should only happen when both fields are touched + dirty || submitted || prefilled
• Validator needs to know about the modelValue of both fields when executing

How I ended up implementing:

export class PasswordsMatch extends Validator {
  static async getMessage(data) {
    return localize.msg(`cwk-input:${data.type}.${data.name}`, data);
  }

  static get validatorName() {
    return 'PasswordsMatch';
  }

  constructor(param, cfg) {
    super(param, cfg);
    // Re-validate second field when the first field changes, so that both fields validations stay synced
    param.first.addEventListener('model-value-changed', () => param.second.validate());
  }

  execute(value, { first, second } = this.param) {
    let hasError = true;
    if (first.modelValue === second.modelValue) {
      hasError = false;
    }
    return hasError;
  }
}

As you can see, we pass both the first and second field as params so we can easily access them when evaluating validity.
The event listener in the constructor is what ensures that both fields are kept in sync. It's perhaps not the cleanest solution but it works well.

confirmPasswordInput.validators.push(
  new PasswordsMatch({ first: initialPasswordInput, second: confirmPasswordInput }),
);
confirmPasswordInput.addEventListener('showsFeedbackForErrorChanged', () => {
  initialPasswordInput.validators.push(
    new PasswordsMatch({ first: confirmPasswordInput, second: initialPasswordInput }),
  );
  // When user triggers confirm pw validation, we should consider initial as prefilled so that validation
  // and feedback happens on both inputs.
  initialPasswordInput.prefilled = true;
  initialPasswordInput.validate();
});

The reason I implemented it like this is because:

• I don't want to show validation the primary field yet before I actually start getting problems on the confirm field, so I just add the validator as soon as these problems start to happen in the confirm field.
• As soon as the shows feedback for error changed event is dispatched on the confirm field, I want the primary field to validate and also set prefilled to true here as a "hack" to make the feedback show and to make them have "synced" validation feedback immediately

It's admittedly a little hacky and weird and that's because my password match validator is pretty "dumb" and is not really aware of the interaction states of both fields, and changing the show/not show feedback condition based on it.

Suggestion

What would be really cool is if we had some way in Lion to create Validators that accept multiple fields, so that:

• We can be smart about showing validation only when all fields fall under a certain interaction state condition
• Synchronise the hasFeedbackFor and showFeedbackFor at all times
• Easily access all fields and do comparisons between them

Focus first error showing field

It's not really clear from the GIF perhaps, but my form is a bit smart about shifting focus whenever the user submits using either the login or signup buttons. If there's a problem, it will focus the first field that has an error, so the user can immediately start fixing it. This even applies to fields that have an error but feedback is not showing. For example, I fill in a username + password and click "signup". The first field with an error is confirm password field, so focus goes to that. The feedback is not shown however because the field is not yet touched + dirty || submitted || prefilled.

It would be quite cool if we could make this a default feature in lion. Perhaps as opt-in, perhaps as smart default with an opt-out. I propose the latter, because I think it fits the overwhelming majority use case.

My form does it like so:

focusFirstFieldWithError() {
  this.formElements.filter((elem) => elem.hasFeedbackFor.includes('error'))[0]._inputNode.focus();
}

Password manager support

My form is working with password managers. The reason is, the native input fields don't have any shadow boundary above them. However, we should be able to make password managers work with input fields inside shadow roots.

How?

1. Create issues and perhaps even contributions for password managers to move from querySelector to deepQuerySelector. https://www.npmjs.com/package/query-selector-shadow-dom
2. Push AOM (Accessibility Object Model) so we use this tree to query for input fields. We'd have to push password managers to start using this instead of the shadow boundary agnostic query selectors.
3. Create a hidden input field that mirrors and is attached to the real input field, but spawn it somewhere in Light DOM. I haven't really thought very far on how it would work or how to implement though, so it needs a POC by someone.

@ruphin I'm tagging you because I heard you had some kind of experiment for password managers, my assumption would be it will be most similar to suggestion 3? Or do you have another way?

Validator non-static getMessage

Quite often you will want your validation feedback message to depend on your validation params (e.g. { min: 4, max: 7 }).

Currently your first attempt will be getMessage which static, and params is only available on the instance. We already have a demo explaining that you can instantiate a Validator and override the getMessage config option "publicly", but we don't have a demo yet that shows you can extend a validator and override the protected _getMessage. Probably someone will force themselves into having localized validation messages since it works with the static method and in translations the params are always passed, before they realize there's a protected way which does not require you to use localized approach.

We should probably also add a demo of a localized validation message example, I had to go into source code to figure out how that works exactly.

[tlouisse]

Nice thoughts and suggestions.

Cross Field validation

Would be very cool to add as an example to the docs. An alternative in some cases can be to put the validation on the wrapping fieldset.
I think the validator that has access to multiple FormControls is a user friednly way of solving this (the dev only has to apply a Validator and it works).

Would it also be possible to change the showFeedbackCondition =>

Maybe we can do (pseudo code):

    _showFeedbackConditionFor(type) {
      const originalCondition = (type) => (this.touched && this.dirty) || this.prefilled || this.submitted;
      if (typeof this.showFeedbackConditionFor === 'function') {
        return this.showFeedbackConditionFor(type, originalCondition)
      }
      return originalCondition(type);
    }    

<first-input .showFeedbackConditionFor=$"(type, originalCondition) => originalCondition(type) && second.showsFeedbackFor.includes(type)">

So we would not have to set prefilled (this feels a bit hacky).

Focus first error showing field

• I would indeed implement these suggestions and make an opt-out: https://www.w3.org/WAI/tutorials/forms/notifications/#after-submit

Password manager support

Would go for 3 (lack of browser and plugin support for other opts)

Validator non-static getMessage

i'm not sure if I understand completely.
We always have access to all instance data via data param in static getMessage, right?
It's also possible to 'provide' messages on constructor level, (if you don't load validate-messages package). This is usually what you would do if your changes should affect the complete app.