In Angular typed forms, how do you choose between an optional FormGroup key, FormRecord and UntypedFormGroup when a form's keys are not fixed?

## Why this choice exists In strictly typed reactive forms (since **Angular 14**), a `FormGroup<T>` is typed by an object whose keys are the control names and whose values are control types. That is ideal for a fixed shape, but many real forms are not fixed. Angular gives you three ways to express variability, and choosing the wrong one either throws away type safety or makes the compiler reject legitimate code. ## Option 1: an optional key on a typed `FormGroup` When you **know the name** of a control that is only sometimes present, declare it optional in an interface: ```ts import {FormControl, FormGroup} from '@angular/forms'; interface ProfileSettings { displayName: FormControl<string>; bio?: FormControl<string>; // only for public profiles } const profile = new FormGroup<ProfileSettings>({ displayName: new FormControl('Ada', {nonNullable: true}), }); profile.addControl('bio', new FormControl('', {nonNullable: true})); profile.removeControl('bio'); // compiles: bio is optional // profile.removeControl('displayName'); // compile error: required key ``` The typing rules are: - `removeControl()` accepts only keys that are **optional** in the interface. - `addControl()` accepts only keys **declared** in the interface, with the matching control type. - The optional modifier carries through to `value` and to `getRawValue()`. This keeps full type safety for every other key while admitting that one field comes and goes. ## Option 2: `FormRecord` for open-ended, homogeneous keys When the key set is **not known ahead of time** but every control has the **same type**, use `FormRecord`. It extends `FormGroup<{[key: string]: TControl}>` and takes one generic: the control type. ```ts import {FormControl, FormRecord} from '@angular/forms'; // channels come from the server: 'email', 'sms', 'push', ... const channels = new FormRecord<FormControl<boolean>>({}); for (const id of ['email', 'push']) { channels.addControl(id, new FormControl(true, {nonNullable: true})); } ``` Any string key is accepted, and any control of type `FormControl<boolean>` can be added. A `FormBuilder` can build one with `fb.record({...})`. What you give up is knowing which keys exist: reading `channels.controls['sms']` may yield `undefined` at runtime. The builder route follows the same nullability rules as elsewhere. `fb.record({email: true})` on a plain `FormBuilder` produces controls typed `FormControl<boolean | null>`, while the non-nullable builder produces `FormControl<boolean>`. Because a `FormRecord` is a `FormGroup` underneath, it also shares the group's value rules: a disabled channel drops out of `value`, and `getRawValue()` returns every channel. Its value type is an index signature, so every lookup is already possibly missing and the `Partial` adds nothing new. ## Option 3: `UntypedFormGroup` as the escape hatch If the keys are open-ended **and** the controls have different types, there is no type a `FormRecord` can express. Angular's guidance is to use `UntypedFormGroup`, which is declared as `FormGroup<any>` and behaves exactly like a pre-v14 group. The same reasoning applies to arrays: a `FormArray` whose elements differ by position needs `UntypedFormArray`. ## The decision table | Key set | Control types | Model | Type safety kept | |---|---|---|---| | Fixed | Any | `FormGroup<T>` | Full | | Fixed, some keys come and go | Any | `FormGroup<T>` with optional keys | Full, plus add/remove checks | | Open-ended | All the same | `FormRecord<TControl>` | Control type only | | Open-ended | Mixed | `UntypedFormGroup` | None | ## Judgement calls in practice 1. **Prefer the most specific model that fits.** Reaching for `UntypedFormGroup` because a form is "dynamic" often discards safety that an optional key or a `FormRecord` would have kept. 2. **Split heterogeneous records.** A metadata-driven form with mixed field types can often become several `FormRecord`s grouped by value type, or a `FormGroup` of known sections each holding a `FormRecord`. 3. **Contain the escape hatch.** If `UntypedFormGroup` is unavoidable, keep it inside one component or service and map its value to a typed object at the boundary, so `any` does not leak through the codebase. 4. **Narrow at runtime when needed.** Code that receives an `AbstractControl` can use `isFormGroup()`, `isFormRecord()`, `isFormArray()` or `isFormControl()` to narrow before reading children. ## What this answer deliberately leaves out How controls are added, removed and rendered at runtime, the events that fire, and how a metadata-driven template iterates them are the job of Angular's dynamic-form APIs. The question here is only which **type** describes the group. The core point is that "dynamic" is not one thing: known-but-optional, open-ended-but-uniform, and open-ended-and-mixed each have their own model, and only the last one needs to give up typing.