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.
- Firstly I set out to handle error messages for each of Angular’s built-in validators.
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
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.
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)