Comparison
Normalised statevsQuery key
Normalised state
you store each record once by id and keep lists as arrays of ids rather than nested copies.
Flattening client-side data into a lookup table keyed by identifier, with relationships expressed as ids. It means an update touches one place rather than every list the record appears in, which is what makes editing a shared entity behave. The cost is indirection at read time and a good deal of ceremony, which is why per-query caching has largely replaced it for server data.
Full entry →Query key
two screens asking for the same data shared one request because they named it the same way.
The identifier under which a cached request is stored, usually including every parameter the request depends on. It is what makes deduplication, revalidation and targeted invalidation possible without a manual cache. Getting it wrong in either direction hurts: a key missing a parameter serves one user's data to another, and a key including something volatile refetches on every render.
Full entry →