The same warning has run through the whole module in different words: the bikes field lives in catalogueSlice on a provisional basis, and src/data/domain.js has spent six modules pretending to be a database. The time has come to settle it, and the claim that governs everything here is this: data coming from a server isn't application state. It doesn't belong to you, it goes stale without telling you, other people change it while you're looking at it, and it arrives late. Storing it in useState or in Redux makes you responsible for a very long list of problems — loading, error, cancellation, race conditions, duplicate requests, revalidation, invalidation, retries, pagination — that dedicated libraries have already solved. In this lesson you'll set up a fake API with json-server, learn TanStack Query v5 for real — queries, keys, the cache's lifecycle, mutations, and optimistic updates with rollback —, rewrite useFetchBikes as useBikes and compare the before and after, and settle CicloUrbano's final architecture: Redux for client state, Query for server state. This closes Module 7.

1. Why remote data isn't application state
2. Everything you have to solve by hand
3. The fake API: json-server and db.json
4. TanStack Query v5: installation and setup
5. useQuery: the query and what it returns
6. Query keys: the cache's identity
7. The lifecycle of a cached piece of data
8. Retries, focus revalidation, and pagination
9. Mutations with useMutation and invalidation
10. Optimistic updates and their rollback
11. From useFetchBikes to useBikes
12. How it coexists with Redux: the final architecture
13. Alternatives: RTK Query, SWR, and React Router's loaders

The distinction sounds philosophical and is entirely practical. Compare the two categories point by point.

A concrete CicloUrbano case that makes it all clear. bici-002 shows as alquilada on your screen. While you're looking at the catalogue, the user who had it returns it at the North Park station. At that instant:

• The server knows bici-002 is disponible.
• Your Redux store still says alquilada.
• Redux is working perfectly: it's storing exactly what you told it to store.

The problem isn't that Redux is failing — it's that this isn't a state-management problem, it's a cache-synchronization problem. And a cache asks questions a state store never does: is this data still valid? when should I ask for it again? what do I show while the new version arrives? how long do I keep it if nobody's looking at it?

Redux, context, and useState answer "what's the value?" A server-state cache also answers "is it still true?"

Here's the complete list of what you have to write yourself if you store remote data in useState or in a slice. Read all of it: it's the lesson's whole argument.

The first four you already solved, and they took a whole lesson. The other ten are the ones nobody writes because they're a lot of work, and they're exactly what separates an app that "works" from one that feels fast and reliable.

And there's a hidden cost: every one of those problems has to be solved per resource. Bikes, stations, bookings, users, and incidents, each with its own loading, error, cancellation, and invalidation. It's when you multiply by five that the library stops being optional.

First things first: we need a real server. json-server spins up a complete REST API from a JSON file, without writing a single line of server code.

Create db.json at the project root, with CicloUrbano's canonical data:

Start it on port 3001, so it doesn't clash with Vite's 5173:

And add the shortcut to package.json:

From here on you need two terminals: npm run dev for the app and npm run api for the API.

What you get without writing any server code:

json-server really writes to db.json. POSTs and PATCHes persist to the file, so you can reload the page and see the booking is still there. That's what makes it far more useful than an in-memory mock: it behaves like a real server, failures included if you send it something wrong.

A practical tip: add db.json to version control but expect it to change as you run the app. If you want to go back to the initial state, git checkout db.json.

And, optionally but strongly recommended, the devtools:

TanStack Query revolves around a QueryClient object, which is the cache: it stores data by key, knows when it expires, decides when to revalidate, and notifies subscribed components. It's the conceptual equivalent of the Redux store, for the other category of state.

On placement: QueryClientProvider sits outside the Redux Provider for the same reason the latter sits outside the router — any component might need it, including route error components — and because a Redux thunk might want to invalidate queries, while the reverse never happens. In practice both orders work; what you can't do is leave either one inside RouterProvider.

The QueryClient is created outside the component, in its own module. If you created it inside with new QueryClient() in a component's body, every render would create a fresh cache and you'd lose everything you'd stored.

The two required parameters:

Critical rule for queryFn: it must throw when the request doesn't go well. fetch doesn't throw on a 404 or a 500 — only on network failures — so the response.ok check with its throw is mandatory. Without it, Query will treat an error response as a success and cache the server's error message as if it were data.

What useQuery returns, with the properties you'll use every day:

The distinction between isPending and isFetching is the one people get wrong most often, and it's exactly what makes Query feel fast:

• isPending: there's nothing to show yet. This is when the full-screen loading indicator belongs.
• isFetching: there's data — maybe a bit stale — being refreshed in the background. Show the data and, at most, a discreet indicator.

If you use isFetching where isPending belongs, the screen will empty out every time Query revalidates, and you'll have turned its best feature into a flicker.

The queryKey is the data's identity in the cache. Two components with the same key share the same cache entry, the same request, and the same data; with different keys, they're different data.

Rules for designing keys:

1. General to specific, like a route. This is what lets you invalidate by prefix (section 9).
2. Anything that changes the result belongs in the key. If queryFn uses stationId, that id must be in the key; otherwise switching stations would show the previous one's data.
3. Objects are compared by content, not by reference, and the order of an object's keys doesn't matter: { type: 'urbana', sort: 'precio' } and { sort: 'precio', type: 'urbana' } are the same key. Arrays, on the other hand, are order-sensitive.
4. Centralize keys in a factory, so you don't hand-write them in twenty places:

With this factory, a typo in a key stops being possible, and renaming a resource becomes a one-file change.

The most visible consequence of a shared key is automatic deduplication: if Header, CataloguePage, and FleetSummary all request ['bikes'] at the same instant, only one request is made and all three get the same data. That problem, which in 07-04 needed a hand-written condition, simply doesn't exist here.

Here's the mental model you need to internalize. A piece of data in Query's cache moves through four states.

The two options that govern all of this:

staleTime's default is 0, and it surprises everyone. It means the data goes stale the moment it arrives, so Query will revalidate as soon as there's a reason to — mounting a component, returning to the tab. It's not a bug: it's a conservative value, because Query always keeps showing the cached data while it revalidates, so the user never sees a wait, only a silent update. Even so, in most apps it's worth raising it.

Typical values by data type:

One distinction people often mix up: staleTime and gcTime measure different things. staleTime is "how much I trust this data"; gcTime is "how long I keep it once nobody's looking." A piece of data can be stale and still sit in memory for hours, which is why going back to a screen shows you the old data instantly while Query refreshes it behind the scenes. That's exactly the fast-app feeling we were after.

By default, Query retries three times with exponential backoff before giving up on a query. It's adjustable per query:

Retrying a temporary network failure makes sense; retrying a 401 or a 404 doesn't, ever. Filtering by error type is what separates a useful retry from three pointless requests.

Query revalidates stale data at four moments, all configurable:

The second one is the one that impresses people most the first time: you leave the tab, come back ten minutes later, and the data is already up to date without you doing anything. It's one of the ten problems from section 2's list that nobody writes by hand.

For an operator panel that needs to see the fleet almost live:

When you change page, the key changes, so the new page's data doesn't exist yet and data would be undefined: the list would disappear and come back. placeholderData prevents that.

With keepPreviousData, clicking "Next" keeps the previous list visible, isPlaceholderData is true while that's happening, and the change feels instant. Without it, every page change is a flicker to a blank screen.

Queries read; mutations write. And a write raises a question a read never has: which cached data has just gone stale.

What useMutation returns:

invalidateQueries is the key piece, and it works by prefix:

This is where rule 1 from section 6 pays off: hierarchical keys from general to specific, because they're what let you invalidate an entire branch with one line.

What invalidating actually does: it marks the queries as stale and immediately refetches the active ones (with mounted components). Inactive ones will refetch the next time someone mounts them. It deletes nothing, so the user keeps seeing the previous data while the new one arrives.

Invalidating is correct but not instant: the user clicks "Confirm," waits for the PATCH to finish, waits for the refetch to finish, and only then sees the change. On a slow connection that's a good two seconds of nothing.

Optimistic updates apply the change to the cache before the server responds, and undo it if it fails. It's the pattern that makes good apps feel instant.

The three steps are inseparable, and each one solves a different problem:

When to use optimistic updates and when not to:

Confirming a booking is defensible; creating one, less so, because the server could reject it if someone else just rented that bike, and having a booking appear and disappear is worse than waiting half a second. That's why useCreateBooking invalidates and useConfirmBooking is optimistic.

Time for the moment of truth. This was the hook from 05-06, with everything you had to do by hand:

And this is the version with Query:

The before and after, no dressing up:

Concrete bugs that disappear without writing a line:

1. Navigating quickly between two stations and seeing the wrong station's fleet.
2. Opening two panels that show the same bikes and firing two identical requests.
3. Returning to a screen and waiting again for data you already had.
4. Creating a booking and having the catalogue keep showing the bike as available.
5. Losing the connection, getting it back, and being stuck with ten-minute-old data.
6. Piling up in memory the data for every station visited during the session.

And an important architectural consequence: catalogueSlice loses bikes, loadState, and error, along with the createAsyncThunk fetchBikes and its three extraReducers. What's left is searchTerm and sort, genuine client state. This is exactly what was announced in 07-04 and 07-05: build it and then undo it, just like it happens in a real project when a server-state library gets introduced.

The rule fits in one line: Redux (or context) for client state; TanStack Query for server state. They don't overlap, they don't compete, and there's no need to choose.

The final breakdown, piece by piece:

A nuance about the session worth thinking through. The user is a server resource — it lives at /usuarios — but which one of them you are in this tab is client state. A common and very clean split: identity (the token or the id) in Redux, and the profile data with useQuery(['users', id]). In CicloUrbano, with a fake sign-in, keeping the whole user in sessionSlice is perfectly reasonable.

How much Redux is left. After this move, CicloUrbano's store keeps sessionSlice and a catalogueSlice trimmed to two fields. bookingsSlice all but disappears: bookings are the server's, their transitions are mutations, and their business rules belong to the server — where they always should have lived. That's the honest conclusion 07-05 was building toward: in many real apps, once server state is where it belongs, the client state that's left fits in two contexts. It's a legitimate conclusion, and you can only reach it by having understood Redux, not by avoiding it.

TanStack Query isn't the only answer. These are the four serious options, compared.

When to pick each one:

• TanStack Query: today's default choice. It's the most complete, the best documented, works with any way of fetching data, and doesn't force you into Redux. It's the one used in this lesson.
• RTK Query: if the project already uses Redux Toolkit. You define the API once — endpoints, providesTags, invalidatesTags — and it generates the hooks for you; tag-based invalidation is more declarative than key-based invalidation. Everything also shows up in Redux DevTools, alongside the rest of the state. Its downside is that it ties you to Redux.
• SWR: if you want the essentials — cache, focus revalidation, deduplication — with the smallest possible surface. Fewer features for mutations and pagination, but very solid and tiny.
• React Router's loaders (06-03): solve a different, complementary problem. A loader loads the data before the route paints, removing the "mount → request → wait → paint" cascade and, with it, the loading flicker. Its limit is that the cache is per route, not per piece of data, so it doesn't dedupe across screens or revalidate on focus. Combining the two is the best architecture available today with React Router: the loader prefetches the query into the queryClient, and the component reads it with useQuery, getting both early loading and caching.

Mistake 1: queryFn not throwing on an HTTP error. fetch doesn't throw on a 404 or a 500. Without if (!response.ok) throw, Query will store the server's error message as if it were the data.

Mistake 2: using isFetching where isPending belongs. The screen will empty out on every revalidation, turning Query's best feature into a flicker.

Mistake 3: leaving out of the key a parameter queryFn uses. If stationId isn't in queryKey, switching stations shows the previous one's data. Anything that changes the result belongs in the key.

Mistake 4: creating the QueryClient inside a component. new QueryClient() in a component's body creates a fresh cache on every render. It belongs in its own module, outside.

Mistake 5: copying data into a useState or into Redux. It duplicates the source of truth and cancels out revalidation: your copy never finds out about anything. Use data directly.

Mistake 6: forgetting cancelQueries in an optimistic update. An in-flight revalidation can finish later and overwrite your change with the old data. It's an intermittent bug that's very hard to diagnose.

Mistake 7: mutating the cache inside setQueryData. The updater must return a new object, just like a reducer. Mutating the cache's object breaks reference comparison and components never find out.

Mistake 8: invalidating too much. invalidateQueries() with no key invalidates everything and triggers a storm of requests. Invalidate only the affected branch.

Tip 1: centralize keys in a factory. It eliminates typos, makes the hierarchy explicit, and turns renaming a resource into a one-file change.

Tip 2: tune staleTime per data type. The default of 0 is conservative. CicloUrbano's stations don't change: one hour is fine and saves dozens of requests.

Tip 3: use the Query DevTools from day one. They show every query with its key, its state — fresh, stale, inactive —, when it was last requested, and what data it holds. It's the equivalent of Redux DevTools for this layer.

Tip 4: wrap every query in its own hook. useBikes, useStations, useBookings, useCreateBooking. Components shouldn't see queryKey or queryFn, for exactly the same reason they shouldn't see the shape of Redux state.

Tip 5: don't cut db.json out of your workflow. Having an API that responds for real, that persists, and that sometimes fails is far more educational than a mock that always works.

Exercise 1. Write the hooks useStations() and useStation(stationId) on top of the fake API, with hierarchical keys, a justified staleTime for each, and correct error handling. Then rewrite StationsPage to use them, correctly distinguishing the first load from a revalidation.

Exercise 2. This mutation hook has four problems. Find them and fix it.

Exercise 3. After this module, bookingsSlice is left almost empty. Decide what stays in Redux, what moves to TanStack Query, and what disappears entirely, for each of these, and justify each decision: (a) the ids array and the entities object; (b) loadState and error; (c) submitState; (d) the rule that only an active booking can be confirmed; (e) the createAsyncThunk submitBooking; (f) the selector selectBookingsSummary.

Solution 1.

enabled: Boolean(stationId) replaces the if (!stationId) return; guard that in 05-06 had to be written inside the effect. And notice that this component solves 07-01's Exercise 2: no sync effects, no stored derived values, and server state right where it belongs.

Solution 2. The four problems:

1. mutationFn doesn't check response.ok and is missing the Content-Type header. Without the check, a 500 is treated as a success and the rollback never happens; without the header, json-server might not parse the body.
2. onMutate mutates the cache's objects. b.status = 'cancelada' modifies the original object inside map, so the previous "snapshot" ends up altered too: rolling back would be impossible even with an onError.
3. cancelQueries and onError are both missing. There's no rollback, and an in-flight revalidation can overwrite the optimistic change.
4. invalidateQueries() with no key invalidates every query in the app, causing an unnecessary full reload. And it should go in onSettled, not onSuccess, to resync after a failure too.

Problem 2 is the most instructive one: an optimistic update written with mutation is worse than not having one, because it silently destroys the only copy that would have let you go back. Immutability isn't a Redux quirk; it's what makes undoing possible.

Solution 3.

And the final tally: almost nothing is left of bookingsSlice. That doesn't mean lessons 07-03 through 07-05 were wasted time. The model of actions, pure reducers, normalized state, and selectors is the same one used in Zustand, in Jotai, in useReducer, and — literally — in the setQueryData you just wrote, which is a reducer by another name. What you've learned is to classify before choosing, and the best possible outcome of that classification is discovering you needed less than you thought.

Data coming from a server isn't application state: it doesn't belong to you, it goes stale on its own, other people change it while you're looking at it, and it arrives late. Storing it in useState or in Redux isn't wrong out of taste — it's wrong because it makes you responsible for a list of fourteen problems — loading, error, cancellation, race conditions, deduplication, revalidation on tab focus and on reconnect, invalidation after a write, retries, shared cache, garbage collection, pagination without flicker, stale data while revalidating, optimistic updates — multiplied by every resource. The first four cost you a whole lesson back in Module 5; the other ten are the ones nobody writes by hand.

You've set up a real fake API with json-server and a db.json holding CicloUrbano's canonical five bikes, three stations, two users, and one booking, served at http://localhost:3001 with filters, pagination, sorting, and writes that persist. On top of it, TanStack Query v5: a QueryClient created outside the components and provided in main.jsx, useQuery with its queryKey — the cache's identity, hierarchical from general to specific and centralized in a factory — and its queryFn, which must throw on an HTTP error because fetch doesn't. You can tell isPending apart from isFetching, which is what separates a screen that flickers from one that feels instant, and you know the lifecycle of a cached piece of data — fresh, stale, inactive, garbage collected — governed by staleTime ("how much I trust it") and gcTime ("how long I keep it once nobody's looking"), with values reasoned per data type: an hour for stations, thirty seconds for the catalogue, zero for live availability. And the features nobody writes by hand: retries filtered by error type, revalidation on tab focus and on reconnect, and keepPreviousData to paginate without emptying the list.

On the write side, useMutation with invalidateQueries by prefix — the direct payoff of hierarchical keys — and the full optimistic update: onMutate cancelling in-flight revalidations, saving the previous snapshot, and writing the change immutably; onError restoring that snapshot; onSettled resyncing no matter what. The three steps are inseparable, and an optimistic update written with mutation is worse than not having one. useFetchBikes has become useBikes: from forty-five lines to twenty, with six whole classes of bug that stop being possible and seven new features that didn't exist before.

CicloUrbano's final architecture is split with no overlap: TanStack Query for bikes, stations, bookings, and users; Redux for sessionSlice and a catalogueSlice trimmed to searchTerm and sort; context for the theme and the notices; the URL for the ?tipo= filter; and local useState for modals, drafts, and selections. And the honest conclusion this module has been building toward since 07-01: once server state is where it belongs, the client state that's left is far less than it looked. You only reach that conclusion by having understood Redux, not by avoiding it.

This closes Module 7. CicloUrbano now knows where every piece of data lives and why, has an auditable store with an action history, a cache that syncs itself with the server, and a clean split between what's its own and what belongs to the backend. It does a lot, and it does it well. What it still doesn't do is go fast: there are components repainting without needing to, selectors and calculations redone on every render, lists that repaint whole because a prop changed identity, and a final bundle the browser downloads in full before showing the first screen. Module 8: Performance Optimization takes that on directly: how to identify which renders are genuinely wasted before touching anything, React.memo to avoid repainting components, useMemo and useCallback — the debt this module has been leaving behind since 07-02 and 07-05 — to stabilize values and functions, code splitting and lazy loading so each screen only downloads what it needs, and the React DevTools Profiler to measure instead of guess. The next lesson is Performance Optimization Techniques in React.