Cab Booking（Context 版）Cab Booking (Context version)

In one line: createContext() lays a pipe, Provider pours a value into it, and any component in the subtree reads it with useContext — no prop drilling.

What each of the three parts is for:

• const CabContext = createContext() — the pipe. Note the source project gives no default value, so without a Provider useContext returns undefined. That is deliberate; see below.
• CabProvider — an ordinary component. Two useState calls hold the state, one function changes it, and all three go into value.
• useCabContext — a custom hook. It is not just an alias for useContext; it carries a guard that throws when there is nothing to read.

What that guard is protecting you from (the highlighted lines 26–28 in the code below): without it, forgetting the Provider leaves context as undefined, and then const { rideHistory } = undefined throws an opaque destructuring error (Cannot destructure property ... of undefined). With the guard you get useCabContext must be used within a CabProvider — the actual cause, stated plainly.

Follow-up: “Why not give createContext a default value?” — because then forgetting the Provider makes the code quietly run on fake data, and you go hunting for a broken feature instead of a missing wrapper. No default plus a throwing guard makes the mistake surface immediately.

In one line: a component cannot read a Context it provides in its own return. useContext looks up the tree for a Provider, never down.

Why this question in particular punishes it: look at line 14 of App below — App calls useCabContext() itself, because handleSelectCab needs updateBookedCabDetails. So App is a consumer, not the provider.

Put the Provider inside App’s return and that useCabContext() at the top of App runs while App itself is rendering, before any Provider is mounted. context is undefined, the guard throws useCabContext must be used within a CabProvider, and all four tests go red.

The right layering: in index.jsx, <CabProvider> wraps <App />. The test file wraps it the same way — that is not a coincidence, it is the test telling you where the Provider belongs.

Follow-up: “Could the Provider go even higher, outside StrictMode?” — yes; it only has to sit above every consumer. The source project keeps it inside StrictMode, which means the development double-render covers the Provider too and surfaces things like effects written into render sooner.

In one line: updateBookedCabDetails(details) does two things — marks this cab as the current booking and appends it to the history.

Why both belong in one function: if the caller had to make two calls (setBookedCabDetails(cab) plus setRideHistory(...)), then the business action “pick a cab” would live in the callers. Add a rule later — say, do not log the same cab twice — and you have to edit every call site. One function, one place for the rule.

The Context ends up exposing three things:

• bookedCabDetails — the current cab; CabConfirmation uses it for “X is on the way”
• rideHistory — every record; RideHistory takes the newest three from it
• updateBookedCabDetails — the only way to write; App uses it

Notice how spread out the consumers are: App only writes, CabConfirmation only needs bookedCabDetails, RideHistory only needs rideHistory. Three components take what they need and know nothing about each other — that is the payoff over props. With props, rideHistory would have to travel from App through Home into RideHistory, and Home has no use for it at all.