In this article we’re going to explore various approaches how to implement reactive sub-forms and discuss their trade-offs. At the end you will be able to make informed decision based on the particular use case to deliver best possible experience for your users and great developer experience for your colleagues!
Forms represent one of the most important parts of almost all frontend applications. From a single input field to a multi step wizards, forms enable dialog with the users by providing them with a way to submit many different kinds of data!
When developing Angular application, we will rarely end up with just a single form. It is much more common to implement many different forms for the individual features based on user requirements.
It is quite usual that some of the forms (or their parts) will feel repetitive as we keep re-implementing them over and over again!
An Example
Let’s say we’re implementing a customer form. There will most likely be a part of that customer form which will hold address data. We will use Angular reactive forms and a nested FormGroup to describe address object with properties (and inputs) for stuff like street, city or zip code.
Top comments (2)
Would you mind posting the full article here? You can even set the canonical link to your page.
Nice Tomas; this is what I call refactoring duplication based only on coding patterns! As you know the power of properly used DI, allows us to look at patterns that may repeat, without regard to context. In fact, the concepts of injecting behaviors into templates is what Angular is all about, and it doesn't have to be just code, it can also include html templates. Need to abstract common things to one-time-one-place, in Angular it's "cd ../common; ng g c myCommonThing" works every time and takes about 2 seconds to type that line.