An Angular template-driven sign-up form moves its address inputs into a child component, and they stop affecting the parent form's value and validity. Why, and how do you fix it?

## The setup that breaks A sign-up form grows, so the address fields move into their own component: ```html <!-- parent template --> <form #f="ngForm"> <input name="email" ngModel required /> <app-address /> </form> ``` Inside `AddressFields`, the inputs still use `ngModel` with names. They render and accept typing, but `f.value` has no address and `f.valid` is `true` even when they are empty. Nothing throws. ## Why the child cannot see the form `NgModel` receives its parent container through dependency injection: it asks for **`ControlContainer`**, the abstract class that `NgForm`, `NgModelGroup` and the reactive container directives provide. It asks with **`@Optional() @Host()`**. - **`@Host()`** restricts resolution to the injectors of the current component's template, stopping at the host element of that component. The `<form>` lives in the **parent's** template, beyond that boundary. - **`@Optional()`** turns "not found" into `null` instead of an error. With a `null` parent, `NgModel` concludes it is **standalone**: it manages its own `FormControl`, never calls `addControl`, and does not even require a `name`. The child's fields are live but invisible to the form. ## The dev-mode warning Since Angular **22.1.3**, a development build detects this case and logs warning **`NG01354`**: an `ngModel` in a child component cannot register with the parent's `NgForm` because `@Host()` stops injection at the component boundary. The message suggests the two fixes below. Earlier versions failed silently, which is why this bug has a long history in real projects. ## Fix 1: re-expose the container with viewProviders ```ts @Component({ selector: 'app-address', imports: [FormsModule], viewProviders: [{provide: ControlContainer, useExisting: NgForm}], template: ` <input name="city" ngModel required /> <input name="zip" ngModel required /> `, }) export class AddressFields {} ``` - **`viewProviders`** scopes the token to the child's **own template**, which is exactly where `@Host()` lets `NgModel` look; it is the placement Angular's error guide uses, and content projected into the child is not affected. - **`useExisting: NgForm`** resolves `NgForm` from the element injector chain **outside** the child, where the parent's `<form>` provides it, and aliases it as the `ControlContainer`. - If the child is placed inside an `ngModelGroup`, alias **`NgModelGroup`** instead so the fields land in that group. For a reactive parent the equivalent is `FormGroupDirective`. The child is now coupled to being used inside a form; that is the trade-off. ## Fix 2 and 3: other designs | Option | How | Best when | |---|---|---| | Bridge with `viewProviders` | alias the parent container | the child is a template fragment of this form | | Mark fields standalone | `[ngModelOptions]="{standalone: true}"` | the child's fields are UI state, not form data | | Inputs and outputs | parent binds values down and events up | the child is a reusable, presentational section | | Custom form control | implement `ControlValueAccessor` and use `ngModel` on the child element | the child represents one value such as an address object | The custom-control route is the most reusable, since the parent then treats the whole address as one control, but it is more code. The mechanics of writing one belong to the value-accessor topic. ## Testing the split form A component test should render the **parent** with the real child, fill the child's inputs, and assert on the parent's `NgForm`: `f.value` should contain the child's names and `f.valid` should turn `false` when a required child field is empty. A test of the child alone passes even when the bridge is missing, which is how this bug usually slips through. ## Checklist when fields go missing from a template-driven form 1. Is the `ngModel` in the same component template as the `<form>`? If not, bridge or redesign. 2. Is it inside `ngModelOptions` `standalone: true` by accident? 3. Does it have a unique `name`? 4. Is the dev console showing `NG01354`?