RFC: decentralized validations

[jamesarosen]

Background

ember-validations and ember-cp-validations are fundamentally centralized, with a single form or backing model declaring all validation rules. Key benefits of centralized validations include

• it's easy to write validations that involve multiple fields
• if done at the model layer, they do not need to be replicated for each view of the model
• if done at the model layer, keeps validations near other business logic

HTML's built-in validation (which admittedly is not widely used, I think primarily because it's hard to style) is fundamentally decentralized. Each field declares its own validation rules and can intercept and block the form submission. Key benefits of decentralized validations include

• a complex form element can apply validations wherever it is used
• it's easy to change validation rules to fit different use-cases; in a centralized world, this requires duplicating the ruleset, then adding/removing/modifying as needed

I'm particularly interested in that first benefit of decentralized validations. I have a few scenarios in my app where an individual field knows more about its validation rules than the surrounding form or backing model. I'd like a way for the field to look up the "closest thing with validations" and add one to it when it is instantiated, then remove it when it is destroyed.

Use Case: sudo

Some forms require entering into "sudo mode," which involves re-entering your password. This is exchanged for a token that is valid for a few minutes, after which sudo mode expires.

One way to model this in the UI is to have a two-step (wizard-style) form:

1. if not in sudo mode, enter password
2. the rest of the form

Many people find that extra step a burden, so we would prefer to have a single form. One of the fields would be a {{sudo-field}}, which has two states:

1. if not in sudo mode, a password field
2. if in sudo mode, display that the user is in sudo mode and don't require a password

The difficulty, though, is that the {{sudo-field}} needs to make a request to exchange the password for a token before the form submission can continue. There are several ways to do this, but I think the most elegant is to treat it as an async validation.

Use Case: dangerous field

I have a "user settings" form that has a grab-bag of options, none of which have any relation to one another; they're simply all attached to the same model. Most of those fields are "normal," but a few of them are "dangerous." If a user changes the value of one of those fields, we want to interrupt the save to have them confirm it.

I'd rather have the individual fields know whether they are dangerous than have the user know the set of dangerous fields. A good way to model that would be to have the fields add an async validation to their parent form.

Implementation Ideas

One approach might be something like

{{#validated-form action=(action 'save') as |validations|}}
  {{sudo-field validations=validations}}

  {{regular-field}}

  {{dangerous-field validations=validations}}
{{/validated-form}}

Then {{sudo-field}} and {{dangerous-field}} would do something like

validations: undefined,

registerValidation: Ember.on('didInsertElement', function() {
  this._validation = this.get('validations').add(buildAValidation());
}),

unregisterValidation: Ember.on('willDestroyElement', function() {
  this.get('validations').remove(this._validation);
})

It's a little unwieldy, though.

Parting Thoughts

Perhaps this is so big it deserves to be its own addon. I'm totally fine with that. If so, it would be good to iron out the API over which that addon could talk to ember-cp-validations.

I wrote about this previously. I didn't get any responses there, though, so I'm not sure how helpful that post is.

[Kilowhisky]

Are you talking about manipulating current validations or adding a new validation rule to an existing set?

Couldn't this be simplified down to overridable / expandable validations?

I think i have another use case that can work with this.

Validations for the format of a string are stored in the model because a validation regex is also stored with the model. However the message to display for that regex validation is dependent on the component that displays the validation error message.

Currently the only solution is to repeat the validation in every component that needs a different message.

[jamesarosen]

Are you talking about manipulating current validations or adding a new validation rule to an existing set?

My use-case only covers adding a validation to a set, then removing it.

Couldn't this be simplified down to overridable / expandable validations?

Possibly. I'd need to hear more about that.

Your use-case sounds similar. Adding only add/remove (and not modify) to the API, you could have the components add a validation that combines the rule from the model and the text from the context, then remove the validation when the component is torn down (which is probably exactly when the ancestor component that has the validations is torn down, but not necessarily).