State ownership taxonomy

Every fact about a flat has one keeper, and everyone else asks that keeper.

At the branch	In the app
The signed lease and the rent sit with the landlord's solicitor; the branch file is a copy that may be out of date	server state (step 2)
The flat's address on a viewing slip, which anyone can carry to the door	URL state (step 3)
The applicant's half-filled form on the clipboard, handed in only when complete	form state (step 4)
A negotiator's own jotting of her next viewing	local state (step 5)
The whiteboard of keys out, read by every desk	a shared store (step 6)
"Keys out: 3" written beside that list, wrong the day someone forgets to change it	a stored derived value (step 10)

In real terms: each value has one owner (the server, the URL, a form, a component or a store); everything else reads it, and derived values are recomputed from the owners on every render.

Breaks down when:

• The whiteboard stays on the wall overnight. A store is gone after a reload (step 6).
• A negotiator's note survives her lunch break. A component's state is discarded the moment its owner unmounts (step 9).

Contrasting case: pinning every negotiator's private notes on the shared whiteboard "so anyone can find them". That is the global store as a default: every desk reads round them, and a note outlives the viewing it was for.

4.1 ExamHall EXH-1460: the header's flagged count goes stale

The proctor console header said "2 flagged" while one tile was marked. flaggedCount was stored beside flaggedIds, and the flag and unflag handlers kept it in step; the live feed removes a candidate who finishes, from the tiles and from flaggedIds, and nobody remembered the count. MR !1660 computes it during render: const flaggedCount = flaggedIds.length.

4.1 stored   | flag c-41, c-42, c-43: header "3 flagged", tiles 3 | unflag c-42: header "2 flagged", tiles 2 | feed: c-43 finished: header "2 flagged", tiles 1
4.1 derived  | flag c-41, c-42, c-43: header "3 flagged", tiles 3 | unflag c-42: header "2 flagged", tiles 2 | feed: c-43 finished: header "1 flagged", tiles 1

Both versions agree until a third path changes the list (step 10). An effect that copies the count is a different bug, with an extra render: react-effects-synchronization.

4.2 Catalog: a search draft owned too high

CatalogPage renders a SearchBox and 48 ProductCards. The typed draft is read only by the search box; the submitted query is read by the grid.

4.2 draft page-level | typing "boots" (5 keys): ProductCard renders 240 | Search: 48 | query boots
4.2 draft colocated  | typing "boots" (5 keys): ProductCard renders   0 | Search: 48 | query boots

With the draft in CatalogPage, every keystroke re-renders all 48 cards (step 8). Moved into SearchBox, typing renders no card; only the submitted query, which the grid needs, stays in the page (step 7).

4.3 ExamHall: whose is the draft answer?

A textarea can show the server's saved answer and save on every change, or keep its own draft until Save. The candidate types "abc"; the server's replies then arrive in order.

4.3 field shows the saved answer | typed "abc" | shows "c" | saves while typing 3 | sent ["a","b","c"]
4.3 form keeps the draft       | typed "abc" | shows "abc" | saves while typing 0 | sent ["abc"]

A server-owned field snaps back to the saved value after each keystroke, so letters are lost. The draft belongs to the form, and the server gets it on submit (steps 2 and 4). Controlled and uncontrolled fields: react-actions-forms step 1.