If you find yourself wrestling to fit nested trees of data inside of a flat form, Angular has you covered for both simple and complex cases.
Let's assume you had a payment endpoint which required data, similar to the following:
{"contact": {"firstname":"Bob","lastname":"McKenzie","email":"BobAndDoug@GreatWhiteNorth.com","phone":"555-TAKE-OFF" },"address": {"street":"123 Some St","city":"Toronto","region":"ON","country":"CA","code":"H0H 0H0" },"paymentCard": {"provider":"Credit Lending Company Inc","cardholder":"Doug McKenzie","number":"123 456 789 012","verification":"321","expiry":"2020-02" }}
While forms are flat and one-dimensional, the data built from them is not. This leads to complex transforms to convert the data you’ve been given into the shape you need.
Worse, in cases where it is possible to run into naming collisions in form inputs, you might find yourself using long and awkward names for semantic purposes.
A form handler would have to convert that data into a form that your API expects. Thankfully, this is something Angular has a solution for.
ngModelGroup
When building a template-driven form in Angular, we can lean on the ngModelGroup directive to arrive at a cleaner implementation, while Angular does the heavy lifting of converting form-fields into nested data.
Using the alternative HTML5 labeling format; IDs have no bearing on the ngForm / ngModel paradigm
Aside from semantic purposes, ngModelGroup does not have to be used on <fieldset> — it would work just as well on a <div>.
If we were to fill out the form, it would end up in the shape we need for our API, and we can still rely on the HTML field validation if we know it’s available.