RTK Query Caching
Compare a naive fetch-heavy implementation with an RTK Query version that dedupes network traffic and invalidates on mutation.
The demo instruments request counts, cache hits, and render counts so you can see the impact of the caching strategy in real time.
Naive Fetch & Local State
Two components each call `fetch` inside `useEffect`, so every change triggers redundant network requests. Caching is manual, error paths are fragile, and both lists manage their state independently.
RTK Query Caching & Mutations
A single RTK Query slice dedupes requests, keeps data warm, and invalidates on mutation. Metrics show fewer HTTP calls while the UI stays consistent across components that share the cache.
How to test this demo
Each panel owns its own network meter with a cache-hit counter. Try this sequence:
- Press “Reset metrics” on both sides.
- Type
alpha, thenbeta, thenalphaagain in each filter.(Try searching for: alpha, beta, gamma, delta, epsilon) - Watch how the naive totals climb twice as fast (two fetches per component) while the RTK version only issues a single request per filter and serves the second list from cache.
- Mutation test:Click the "Mutate first item" button in the RTK panel. Watch how the preview updates instantly and the network makes exactly one invalidation refresh. If you interact or type again, notice how cache hits increment as the newly-warmed data is reused without extra network calls.
Naive implementation
Naive list
Naive list
RTK Query implementation
RTK Query list
RTK Query list
What is happening in both lists for each panel?
In modern React applications, it is very common for multiple disjoint components on the same screen to require the exact same piece of data (for example, a user's profile picture might be needed in both the top navigation bar and a sidebar).
The two lists simulate this real-world scenario where two different components ask for the exact same data at the exact same time:
- In the Naive Implementation: Each list independently calls
useEffectto fetch data. Because there are two components, typing triggers two entirely redundant network requests simultaneously. The browser does twice the work necessary. - In the RTK Query Implementation: Both components ask for the data at the exact same time, but RTK Query acts as a middleman. It realizes both components are asking for identical data, deduplicates the requests, hits the network exactly once, and then shares the single resulting payload with both components.
Having two lists visibly proves that RTK Query solves the "N+1" redundant fetch problem out-of-the-box, saving significant bandwidth and computing power!