Component decomposition and client data model

At the weather service	In the client data model
The register keeps one entry per station, under its code (step 3)	one table per entity type, keyed by id
A regional map lists station codes; each symbol is drawn from its own entry (step 6)	a parent holds ids; each child reads its own record
A new reading at one station redraws that one symbol (step 9)	one record is new, and only its readers run
The old bulletin copied every station's figures into each region's page, so one reading meant a new page and a new bulletin for everyone holding one (step 7)	nested state: a new record makes every ancestor new
Altitude and location sit in the register; the ten-minute readings go on their own feed sheet (step 2)	fast-changing data in its own record
The forecaster draws her marks on a clear overlay, never on the register, which head office reprints (step 5)	view state in its own slice, pointing at records by id

In real terms: a normalized store keeps each record once, under its id, with view state beside it. An update replaces one record and its table, so the only components that run are those that read that record.

Breaks down when: a clerk corrects a register entry in place, and the old entry is gone. A React update leaves the old object untouched and makes a new one; what matters is which objects are new.

Contrasting case: one hand-painted wall map carrying every figure. A new reading means repainting the wall: one component that shows everything.

4.1 ExamHall: the exam page stutters while a candidate types

EXH-1450: candidates saw the ECON-201 exam page stutter while typing. The page kept the exam JSON nested, with each answer inside its question, and the navigator took the whole sections array. MR !1650 normalizes the exam where it enters the app: questions by id, answers by question id, sections holding question ids. Each answer editor and navigator dot reads its own entry. The page has 4 sections of 10 questions, and Q17 is saved twice:

4.1 nested     | first autosave of Q17: ExamPage 1, QuestionNav 1, NavDot 1, SectionPane 1, QuestionPane 1
4.1            | next autosave of Q17:  ExamPage 1, QuestionNav 1, SectionPane 1, QuestionPane 1
4.1 normalized | first autosave of Q17: NavDot 1, AnswerEditor 1
4.1            | next autosave of Q17:  AnswerEditor 1

Nested, each save makes a new question, section and sections array, so the page, the navigator and the section run (steps 7–9). Normalized, only Q17's answer is new. The dot reads "answered or not", so it runs once, when that flips; the editor runs on every save (steps 6, 9).

4.2 Proof domain, catalog: normalizing where the response enters

A listing response holds two lists, bestsellers (12) and lamps (48), and every product embeds its brand:

4.2 response: 2 lists, 60 product entries, 60 embedded brand copies
4.2 normalized: products 52, brands 5, lists hold 12 and 48 ids
4.2 a price change for p-07: nested copies to update 2, normalized records to update 1

Eight bestsellers are also lamps, so the response carries them twice, and 60 brand objects stand for 5 brands. One boundary function turns it into tables (steps 3–4):

{ products: { 'p-07': { id, name, price, brandId: 'b3' } }, brands: { b3: { id, name } },
  lists: { bestsellers: ['p-03', 'p-07', …], lamps: ['p-01', …] },
  view: { expandedIds: {} } }   // view state apart (step 5); picked facets go in the URL (fsd-state-ownership)