Normalise, or nest, and mean it

Nested data reads beautifully and updates badly. To change one comment three levels down you rebuild every ancestor, and if the same comment appears in two places in the tree you now have two of it. Normalised data, entities in a record keyed by id, relationships as arrays of ids, makes that update a single assignment and guarantees one copy.

The cost is that reading requires joins, and joins in JavaScript are a function you write and memoise. For a list of forty items rendered once, that cost is not worth paying. For a collaborative board where any entity can change from any view, it is the only shape that stays sane.

The decision is driven by writes, not reads. Count how many places can modify a given entity. One place and a nested shape is fine. Several places and you want a single keyed home for it, with everything else holding an id. This is also why the server cache in Phase 04 is keyed rather than nested, and recognising the pattern now makes that chapter shorter.