In Angular, how does [(value)]="volume" work when volume is a WritableSignal, and why is [(value)]="volume()" rejected?

## Two-way binding to a signal Signals became the default way to hold component state, so two-way binding had to accept them. Since **v17.2**, the expression in `[( )]` may be a **`WritableSignal`**: ```ts @Component({ selector: 'app-player', imports: [VolumeSlider], template: `<app-volume-slider [(value)]="volume" />`, }) export class Player { volume = signal(40); } ``` The key point is that the template names **the signal object**, not the value it holds. Angular needs the object because the event half has to write into it. ## What the compiler generates For the binding above, Angular's compiler emits a two-way property instruction and a two-way listener. Simplified: ```ts // update: property half twoWayProperty('value', ctx.volume); // unwraps a WritableSignal to its value // create: event half twoWayListener('valueChange', ($event) => { twoWayBindingSet(ctx.volume, $event) || (ctx.volume = $event); return $event; }); ``` 1. **Property half.** `twoWayProperty` checks whether the value is a writable signal. If it is, it reads it (`volume()`) and passes the number to the child's input. Otherwise it passes the value as is. 2. **Event half.** `twoWayBindingSet` calls `set($event)` and returns `true` when the target is a writable signal. For a plain field it returns `false`, and the `||` falls back to ordinary assignment. The same template therefore works whether `volume` is `signal(40)` or a plain `40`. Switching a field to a signal needs no template change. ## What the target is allowed to be The template parser checks the right-hand side of every two-way binding. It accepts only expressions that can be assigned to: | Expression | Accepted? | Why | |---|---|---| | `volume` | yes | property read | | `settings.volume` | yes | nested property read | | `levels[channel]` | yes | keyed read | | `volume!` or `$any(volume)` | yes | wrappers around an assignable read | | `volume()` | no | a call; nothing to assign to | | `getVolume()` | no | a call | | `settings?.volume` | no | a safe-navigation read cannot be assigned | Rejected expressions produce the parse error *Unsupported expression in a two-way binding*. `volume()` is the mistake people make most, because every other place in a modern template reads signals with parentheses. The rule to remember: **reads use `()`, the two-way target does not**. ## Signals that cannot be targets Passing a signal is only useful if it can be written: - A **`computed()`** signal is read-only. - A signal **`input()`** is read-only from inside the component that declares it. - A **`model()`** input is writable, so a component can forward its own model to a child with `[(value)]="value"`. The template type checker models the property half as accepting `T | WritableSignal<T>`. A read-only signal is neither, so binding one fails type checking when input types are checked (`strictTemplates`) instead of silently doing nothing at runtime. ## Why a signal target is worth it The parent view refreshes either way: the listener generated for the event half is wrapped like any template listener, so it marks the parent view dirty whenever the child emits. What a signal adds is reach. `set()` also notifies every other reader of `volume`, such as a `computed()` elsewhere in the component or another view that reads it, so derived state updates without extra wiring. ## Migrating a field to a signal Moving a component from a plain field to a signal is a common modernisation step, and two-way bindings make it smooth: 1. Change the declaration from `volume = 40` to `volume = signal(40)`. 2. Leave every `[(value)]="volume"` as it is; the compiled listener now takes the `set()` branch. 3. Update every **read** of the field: `{{ volume }}` becomes `{{ volume() }}`, `this.volume` in TypeScript becomes `this.volume()`. 4. Update every **write** outside the template: `this.volume = x` becomes `this.volume.set(x)`. 5. Leave expanded forms such as `[value]="volume" (valueChange)="volume = $event"` alone only if you also fix them: the longhand needs `volume()` and `volume.set($event)` explicitly, because only the `[( )]` shorthand performs the automatic unwrapping. The last step is where migrations go wrong: people assume the longhand behaves like the shorthand. It does not; the set-or-assign logic is generated only for the two-way form. ## Summary - Name the signal: `[(value)]="volume"`. - The compiled listener uses `set()` for writable signals and assignment otherwise. - Calls, safe navigation and read-only signals are not valid targets.