In an Angular template, what is the difference between user?.name and user!.name, and what does each do when user is null?

## Two operators that look alike Both operators sit between an object and a property, and both appear when a value "might be null". They do completely different jobs. | | `user?.name` | `user!.name` | |---|---|---| | Name | safe navigation (optional chaining) | non-null assertion | | Exists at runtime | yes - compiled into a check | no - erased by the compiler | | When `user` is `null` | yields `undefined` (v22+) | throws `TypeError` | | Effect on type checking | result type includes `undefined` | removes `null`/`undefined` from the type | | Typical use | value genuinely optional | value guaranteed but checker cannot prove it | ## The safe-navigation operator `?.` guards a read at **runtime**. If the left side is `null` or `undefined`, evaluation stops and the whole chain produces a nullish result instead of throwing. - **Since Angular 22** that result is `undefined`, the same as JavaScript's optional chaining. **Before v22** Angular returned `null`. Code that compared the result with `=== null` or passed it to a function checking for `null` behaves differently after the upgrade; the `ng update` migration wrapped such uses in `$safeNavigationMigration(...)` to keep the old result. - In **interpolation** the difference is invisible, because `null` and `undefined` both render as an empty string. - It combines naturally with `??`: `{{ user()?.name ?? 'guest' }}` shows a fallback for any missing link. - With strict templates, applying `?.` to a value whose type cannot be `null` or `undefined` triggers the extended diagnostic "Optional chain not nullable", which is a hint that the guard is dead code. ## The non-null assertion `!` comes from **TypeScript**. Angular's template parser accepts it so that templates can talk to the **template type checker** in the same way class code talks to `tsc`: - It narrows the type: `user!.name` is typed as if `user` could not be `null`. - It is **erased** from the generated code; nothing checks the value at runtime. - If the assumption is wrong, the read throws a `TypeError` ("Cannot read properties of null") while Angular checks the view, and the error goes to Angular's error handling instead of the value rendering. A related tool is `$any(expr)`, which casts to `any` for the checker and is likewise erased at runtime. ## How the type checker sees each With strict templates, Angular type-checks every expression against the component's types, so both operators change what the checker infers: 1. `user()?.name` on a `User | null` signal is typed `string | undefined`, so passing it to an input typed `string` is an error until you add a fallback (`?? ''`). 2. `user()!.name` is typed `string`, so the same input binding compiles - which is exactly why the assertion is tempting and why it hides a real `null` state. 3. `$any(user()).name` is typed `any`, turning checking off for that expression entirely. ## When to use which 1. **Value can really be missing** (a signed-out user, data still loading): use `?.`, usually with `??` for display text. 2. **Value is guaranteed** by something the checker cannot see (a route resolver ensured it, a parent only renders the child when set): `!` is acceptable, but document why. 3. **A block of markup depends on the value**: prefer a control-flow block such as `@if (user(); as u) { ... }`, which narrows the type for everything inside and avoids repeating either operator. ## Common mistakes - Using `!` "to make the red squiggle go away" on a value that is `null` during the first render - for example a signal that starts as `null` until an HTTP response arrives. The template then throws on first check. - Believing `!` provides a default value or skips rendering. - Chaining `?.` everywhere on values that can never be nullish, which hides real type errors and makes readers think the data is optional. - Expecting `user?.name` to still be `null` in v22 code that compares with `=== null`.