new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Redux Toolkit · API · all subjects

rtk query design

4 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

RTK Query is a document cache not a normalized entity graph

RTK Query implements a document cache model, not a normalized entity graph cache. The caching strategy treats entire documents as units rather than normalizing entities across a graph structure.

When to use RTK Query for caching

Use RTK Query by default when the data comes from request/response APIs, document caching is acceptable, and tag invalidation and endpoint lifecycles solve the problem.

When to reach for a different caching tool

Reach for a different tool when the real requirement is a normalized graph cache, or when the stack already has a domain-specific normalized client that fits better. If normalized caching is mandatory and no better library is already in the stack, a slice plus thunk flow may be the fallback.

Use RTK Query for server cache by default

When the problem is server data that should be cached and re-used, start with RTK Query instead of createAsyncThunk or listener middleware. RTK Query handles caching, invalidation, and re-fetching automatically.

Give your agent this brain