At our company, we struggled with Angular Forms at the start. This is because we dived in head first, without talking about how we would want to use it throughout our projects. This post shows how we're currently using Angular Forms to be more productive.
Anyone that has worked on projects of caliber in the past, will know that there is a high probability that these applications will contain large amounts of complex forms. We were not an exception, we're working in a medical domain to make the administration of clients easier. We come into contact with simple and more complex forms on a daily basis.
As a newly formed team starting on a new project we agreed that we would use Reactive Forms, besides that we hadn’t made agreements around forms and form validation. After a few sprints we started to notice that we were writing a lot of (the same) code, both Angular as HTML. At the same time, we received some design feedback and noticed that we had to touch too much code to get everything right. This is where we started to think that there should be a better way of dealing with forms.
We starting writing input form fields containing all of the orchestration code that is responsible for the field’s behavior. The first iteration of these fields consisted of passing the form control and form group as input to these controls. While this worked at the beginning, it wasn’t great. We always had to be reminded to pass down the form group to the form field as this wasn’t the default “Angular way”. For some of the controls, we ended up with an internal form inside the form field component that had to be kept in sync with the main component, with all the problems and nasty code that came with it.
After some iterations, we learned about Control Value Accessors and this opened up possibilities together with NgControl. From the Angular docs we can see that a CVA has the following API:
interfaceControlValueAccessor{
/**
* Writes a new value to the element.
*
* This method is called by the forms API to write to the view when programmatic changes from model to view are requested.
*/
writeValue(obj:any):void
/**
* Registers a callback function that is called when the control's value changes in the UI.
*
* This method is called by the forms API on initialization to update the form model when values propagate from the view to the model.
* When implementing the `registerOnChange` method in your own value accessor, save the given function so your class calls it at the appropriate time.
*/
registerOnChange(fn:any):void
/**
* Registers a callback function is called by the forms API on initialization to update the form model on blur.
*
* When implementing `registerOnTouched` in your own value accessor, save the given function so your class calls it when the control should be considered blurred or "touched".
*/
registerOnTouched(fn:any):void
/**
* Function that is called by the forms API when the control status changes to or from 'DISABLED'. Depending on the status, it enables or disables the appropriate DOM element.
*/
setDisabledState(isDisabled:boolean)?: void
}
This combination allowed us to use our custom form fields just as we would have previously but with more functionality inside of them. The code also looked a lot cleaner. Think of a standardized behavior and visualization for developers as well as for our users, e.g. form validation, and binding the label to the correct input field. For each type of control, we created our implementation and ended up with an abstract class BaseFormField , containing generic code that we needed in each of our form fields.
By following the practice above, it allows us to extend these controls with custom directives. For example, if we want to populate a radio list or a select box, we can simply assign values to our items.
CVA’s allows us to create common reusable components, think of a generic person’s component asking for personal information. Before we learned about CVA’s we implemented these control multiple times, with all drawbacks included. More than less whenever a new ticket appeared to add a new field, tweak the validation, or change the behavior of a form field we forgot to update a form on another location. By using a CVA, this can be prevented. It allows us to define the form template and to define the form group with validation built-in. This is nothing special since this can also be done with a default component. The difference lays inside the parent component, where we can use the CVA as a normal form field by just defining it inside the form group. In other words, we can now create a part of a form and just use it as a normal form field. For example, if we would take a very simple form asking for the person’s first and last name, the implementation looks as follows:
There was already a glance visible about validation in the previous code snippets. Here again, we felt the pain of writing and maintaining the same code every time we had to implement form validation. That’s why we created an error container, which sole responsibility is to show error messages.
We also have a humanizeFormMessages pipe to map the error to a human-friendly message. We inject FormMessages, containing the default messages. An enterprise environment wouldn't be an enterprise environment if there are no exceptions to the default behavior, that's why we made it possible to override the default messages with case-specific messages.
To make big wizard forms more manageable we chopped them up into multiple smaller steps. For every step in the wizard, we create an isolated form. The wizard form is made up by stitching up all these little forms together. This improves the maintainability and the testing capabilities. By having this loose coupling it becomes easier to make some modifications to the forms, you have the option to re-use the step forms in different screens e.g. using the form in the wizard and using the form as a stand-alone form.
To implement this, use the FormGroupDirective as ControlContainer and provide them via viewProviders (not via providers). We can now inject the FormGroupDirective inside the component and append the child form to its parent form, in our case this is the wizard.
To test our forms we’re using @angular-extensions/testing-library, which is an Angular wrapper around dom-testing-library. This prevents us from testing implementation details and we're testing our forms the way our users would use them.
We navigate to the form fields by using the form labels, we submit forms by clicking on the submit button. We don't care about the methods from the form component, we care about what our users see.
test('login form submits using the component syntax',async()=>{
