linkedSignal: Derived State You Can Still Write To In short: gives you a value with no connection to anything. gives you a connection you cannot write to. fills the gap in between — and that gap turns out to be everywhere. Between v16 and v19 there was no tool for the middle case: a value that comes from something else but can also be changed locally , and resets when its source changes. That case is extremely common, and everyone filled the gap the same wrong way. The gap A dropdown whose options come from an input, with a selection that starts as the first option — but the user can change it, and it should reset when the options change. cannot work: the user must be able to change . So people reached for : Three problems: 1. It runs after the update that changed , so there is a moment where is the new list and still points at something from the old one. 2. It creates a second way to change that is invisible from where is declared. 3. It uses a side effect to work out a value — the exact thing lesson 1 warned about. — the short form can be changed — works. And when changes, it resets to the new first option at the same time , not one step later. No effect. No moment where things disagree. And the connection is written where is declared , so anyone reading the code sees it. The long form — when a plain reset is not enough The short form throws away the old value. Often you want to consider it. The full form separates the source from the calculation and gives you both previous values: is — the old source and the old result — or nothing on the first run. This "keep the selection if it survived the refresh" behaviour is what users expect from any list that reloads, and it is fiddly to write any other way. Choosing between the three The decision is mechanical: Question Use --- --- Is it independent, based on nothing? Is it fully determined by other signals, never changed directly? Is it worked out and changeable, resetting when its source changes? The case has a recognisable smell in old code: a plus an that sets it. Wherever you find that pair, it is a . How this fits with the migration tools The last lesson noted that the input migration skips inputs the component writes to. That is this: An cannot be written to, so the tool correctly refuses to guess. The answer depends on what you meant: That second pattern — plus — is the standard way to say "the parent provides a default, the user can override it, and a new default wins." It comes up constantly once you start looking. A warning resets on every source change, including one that produces an equal-looking value. If returns a new array with the same contents — which any or fresh server reply will — the calculation re-runs and the user's choice is thrown away. Two ways out. Give the source your own comparison, or make the source narrower so it only changes when something meaningful does: If users report "my selection keeps resetting for no reason," this is almost always why. "But isn't this a rare, specialised tool?" That is the usual first reaction. It is the opposite. names a pattern that appears in nearly every real screen — which is why so much code contains a hand-written version of it. Once you know the shape, you see it everywhere: Screen The value that is worked out but changeable --- --- Paged table Current page — resets to 1 when filters change Dropdown with loaded options The choice — resets when options reload List and detail Selected row — clears when the list refreshes Multi-step form Current step — resets when the record changes Editable profile Draft values — reload from the server copy on refresh Sortable table Sort column — falls back if that column disappears Date range picker End date — moves when the start date passes it Every one of these was written before v19 as a plus an . is not adding a new ability. It is giving a name to something people were already doing, badly. "Why not just ?" Because the user must be able to change it. The moment a value has two sources — a calculation and a user action — is out. "Why not ?" sends changes upward to a parent. keeps them local and resets from a source. Different directions. The architect's view The classic case for is a paged, filtered table — and it is worth walking through because the naive fix looks correct. The bug. The user is on page 5. They apply a filter that leaves three pages of results. is still 5, so the request asks for rows that no longer exist and the screen shows nothing — while the count says there are results. The obvious fix, and why it is not enough: This works, and it brought three new problems: 1. The effect runs after the update, so for one moment the page requests page 5 of the filtered list — a wasted request and a visible flash of the empty state. 2. There are now two places that change , and neither is visible from where it is declared. 3. is a line whose only purpose is to be watched. The next developer will "tidy it up" and silently break everything. With : The reset…