Success Handling is Everyone’s Responsibility

After reading Building Brand Loyalty and Reducing Anxiety with UI Animation it was clear that I needed to think about UX actions in my own Angular project. The article explains how animations can bring “delight-inducing and anxiety-reducing” actions to your app.

Having some fun with success messaging could demonstrate how great your branding is. Does one of your projects come to mind?

The task was set to build a reusable validation component for our forms anyways.

1. Firstly I set out to handle error messages for each of Angular’s built-in validators.

Validation has a way of bloating code in our views

2. I extended the component to handle one custom validator to break the ice for others.

3. Then I remembered the brand loyalty article and began working on a strategy to add the success messaging setup I had duplicated across forms.

That’s when I realized that although my component was handed the FormGroup object I had no access to the actual submit event.

In Angular, events exist on DOM elements but I would have to pass the form’s submit $event from the parent component (where the form lives) into the child component (my validator component). Each component that used my validator component would need to be setup this way which kind of defeats the purpose of having reusable components if the parents that use them must duplicate code to set them up.

This bothered me because ValidationComponent was already being sent the entire FormGroup and subscribed for value changes and errors.

You may know about Angular’s FormGroup. It “tracks the value and validity state of a group of FormControl instances.”

We work with FormGroup’s errors for most of our validation checking and reacting.

Hmm nothing but “null” for a clean form, valid/invalid booleans and status‘s VALID, INVALID, PENDING and DISABLED.

Turns out that submitted is not built into Angular’s FormGroup. In other words, we have a list of errors or a valid status to guide us on our journey to great user experience but no tooling for the submitting process experience.

My Proposition

The feature request.

1. submitted:true be added to FormGroup’s statusChanges when the form has been submitted by the user and ngSubmit has triggered a submit event.

Oh fudgy…

But the submit event only means the form was submitted. It does not imply that it was successful within the application, on the server, or that the object returned is as expected.

This is where custom statusChanges messages could solve the entire problem.

Angular allows custom validation to set our own error messages. This validator will add “number:true” to the formGroup’s error's object.

If we could write custom events into FormGroup’s statusMessages the possibilities are endless. But we can’t (as far as I can tell).

2. submitted:invalid could denote that a form submission has been attempted while a form control(s) was invalid.
3. submitted:finished when the application has returned from the server and the application updates the form’s statusChanges that a successful round trip has occurred.

Perhaps even going as far as successfulsubmitted: GET/POST/PUT/DELETE.

Form usage after “finished” could typically trigger setting the form to pristine, status:FINISHED, submitted:null and the UX process would start over.

Success Handling — Did I Just Coin That? (clap up to 50 times)