{"id":"l-rn-3-3","courseId":"react-native-apps","lang":"en","kind":"lesson","summary":"Share Trailhead’s hike list across tabs and screens with a reducer and context provided from the root layout, derive totals instead of storing them, and know when a state library earns its place.","html":"

Four parts of Trailhead now care about the same data. The Log tab lists hikes, the Stats tab totals them, the detail screen shows one, and the add-hike form (next lesson) creates them. If each screen loads and keeps its own copy, they drift apart: you delete a hike on the detail screen, go back, and the Stats tab still counts it, because stack screens and visited tabs stay mounted and don’t reload.

\n

The fix is the React principle you already know, applied to a navigation tree: one source of truth, held above everything that needs it.

\n

Where shared state lives in Expo Router

\n

In a web app you’d put the provider near the root component. In Expo Router, the root component is src/app/_layout.tsx: it renders the Stack, which renders the tab group and every pushed screen. A provider placed around that Stack covers the whole app.

\n
\n HikesProvider wraps the root Stack in src/app/_layout.tsx; the Log tab, the Stats tab and the hike detail screen all read the same hikes and dispatch actions to the same reducer.\n \n HikesProvider\n src/app/_layout.tsx\n \n root Stack\n \n \n Log tab\n \n Stats tab\n \n /hikes/[id]\n \n \n \n \n dispatch\n
One provider in the root layout feeds every screen
\n

A reducer for every change

\n

Hikes get added, edited, deleted and favorited. Rather than scattering setHikes calls across screens, describe each change as an action and handle them all in one pure function:

\n
src/state/hikesReducer.ts
export type Hike = { id: string; name: string; date: string; distanceKm: number; favorite: boolean };\n\nexport type HikesAction =\n  | { type: 'added'; hike: Hike }\n  | { type: 'updated'; id: string; changes: Partial<Omit<Hike, 'id'>> }\n  | { type: 'deleted'; id: string }\n  | { type: 'favoriteToggled'; id: string };\n\nexport function hikesReducer(state: Hike[], action: HikesAction): Hike[] {\n  switch (action.type) {\n    case 'added':\n      return [action.hike, ...state];\n    case 'updated':\n      return state.map((h) => (h.id === action.id ? { ...h, ...action.changes } : h));\n    case 'deleted':\n      return state.filter((h) => h.id !== action.id);\n    case 'favoriteToggled':\n      return state.map((h) => (h.id === action.id ? { ...h, favorite: !h.favorite } : h));\n  }\n}
\n

Every case returns a new array, and a new object for the hike that changed. That’s how React knows something changed, and it’s what lets a memoized HikeRow skip re-rendering the 599 rows that didn’t.

\n

Notice the action names: added, deleted, favoriteToggled. They describe what happened, not how to update state. That keeps screens simple (the detail screen reports that the user toggled a favorite and doesn’t care how the list is stored) and gives you one place to change when the rules change, for example when deleting a hike should also remove its photos.

\n

Because the reducer has no React Native imports, it runs anywhere. You’ll test reducers like this one with plain Jest in section 5, and you’ll write one in this lesson’s exercise.

\n

The provider and its hooks

\n
src/state/hikes.tsx
import { createContext, use, useMemo, useReducer, type Dispatch, type ReactNode } from 'react';\nimport { hikesReducer, type Hike, type HikesAction } from './hikesReducer';\n\nconst HikesContext = createContext<Hike[] | null>(null);\nconst DispatchContext = createContext<Dispatch<HikesAction> | null>(null);\n\nexport function HikesProvider({ initial, children }: { initial: Hike[]; children: ReactNode }) {\n  const [hikes, dispatch] = useReducer(hikesReducer, initial);\n  return (\n    <DispatchContext value={dispatch}>\n      <HikesContext value={hikes}>{children}</HikesContext>\n    </DispatchContext>\n  );\n}\n\nexport function useHikes() {\n  const hikes = use(HikesContext);\n  if (!hikes) throw new Error('useHikes must be used inside HikesProvider');\n  return hikes;\n}\n\nexport function useHike(id: string | undefined) {\n  const hikes = useHikes();\n  return useMemo(() => hikes.find((h) => h.id === id), [hikes, id]);\n}\n\nexport function useHikesDispatch() {\n  const dispatch = use(DispatchContext);\n  if (!dispatch) throw new Error('useHikesDispatch must be used inside HikesProvider');\n  return dispatch;\n}
\n

Then wrap the Stack in the root layout: <HikesProvider initial={sampleHikes}><Stack>…</Stack></HikesProvider>. In section 4 the initial data will come from the device’s database instead.

\n

A few details worth copying. React 19 lets you render a context directly as its provider (<HikesContext value={…}>) and read it with use. Splitting state and dispatch into two contexts means components that only dispatch, like a delete button, don’t re-render when the list changes. And the hooks throw a clear error if someone forgets the provider, instead of failing later with “cannot read properties of null”.

\n

A screen now reads like this:

\n
TSX
const hike = useHike(id);\nconst dispatch = useHikesDispatch();\n// …\n<Pressable onPress={() => dispatch({ type: 'favoriteToggled', id: hike.id })}>
\n

Derive, don’t duplicate

\n

The Stats tab needs total distance, hike count and the longest hike. None of those are state. They’re derived from the hike list, so compute them:

\n
TSX
const hikes = useHikes();\nconst stats = useMemo(() => {\n  const totalKm = hikes.reduce((sum, h) => sum + h.distanceKm, 0);\n  const longest = hikes.reduce((best, h) => (!best || h.distanceKm > best.distanceKm ? h : best), undefined as Hike | undefined);\n  return { count: hikes.length, totalKm, longest };\n}, [hikes]);
\n\n

When context isn’t enough

\n

Context re-renders every consumer when its value changes. For Trailhead’s hike list that’s fine. It becomes a problem when a value changes very often (a live GPS position updating every second) or when a large app has many unrelated consumers. Teams then reach for Zustand, a small store with selectors so components re-render only for the slice they read. Data that lives on a server has different problems again (caching, refetching, staleness), which is the job of TanStack Query; you’ll meet that in section 4. Start with reducer plus context, and move when you’ve measured a reason.

\n

Next, the screen that creates hikes: a form that works with a phone keyboard.

\n","toc":[{"id":"sec-1","text":"Where shared state lives in Expo Router","level":2},{"id":"sec-2","text":"A reducer for every change","level":2},{"id":"sec-3","text":"The provider and its hooks","level":2},{"id":"sec-4","text":"Derive, don’t duplicate","level":2},{"id":"sec-5","text":"When context isn’t enough","level":2}],"takeaways":["State used by several routes belongs above all of them, which in Expo Router means a provider in the root _layout.tsx.","A reducer keeps every change to the hike list in one pure, testable function that returns new arrays and objects.","Wrap context in small hooks such as useHikes() and useHike(id), so screens never touch the context object directly.","Derive totals and filtered lists from the source state with useMemo; don’t store them separately.","Reach for a library like Zustand when context re-renders become a measured problem, and for TanStack Query when the data lives on a server."],"further":[{"title":"Scaling Up with Reducer and Context","url":"https://react.dev/learn/scaling-up-with-reducer-and-context"},{"title":"Choosing the State Structure","url":"https://react.dev/learn/choosing-the-state-structure"},{"title":"useReducer","url":"https://react.dev/reference/react/useReducer"}],"quiz":[{"q":"

The Stats tab stores totalKm in its own useState, updated in an effect. After a user deletes a hike, the total is wrong until the app restarts. What’s the best fix?

","options":[{"text":"Add the hikes array to the effect’s dependency list.","why":"That patches the symptom, but you still have two copies of the truth and an extra render on every change."},{"text":"Move totalKm into the reducer and update it on every action.","why":"Now every action has to remember to keep the total in sync, which is where this kind of bug comes from."},{"text":"Re-mount the Stats tab whenever it gains focus.","why":"Throwing away the screen’s state to recover from a sync bug costs more than the bug."},{"text":"Delete the state and compute the total from the shared hikes with useMemo.","why":"Correct. Derived values computed from one source of truth can’t drift out of sync."}],"answer":3},{"q":"

What’s wrong with this reducer case?

\n
JavaScript
case 'favoriteToggled': {\n  const hike = state.find((h) => h.id === action.id);\n  hike.favorite = !hike.favorite;\n  return state;\n}
\n","options":[{"text":"It mutates the existing hike and returns the same array, so React sees no change and nothing re-renders.","why":"Correct. Return a new array with a new object for the changed hike, for example with state.map."},{"text":"Reducers can’t contain block-scoped const declarations.","why":"Block-scoped declarations inside a case with braces are fine."},{"text":"find is too slow for a reducer; it needs an index lookup.","why":"For hundreds of hikes find is instant. The bug is mutation, not speed."}],"answer":0},{"q":"

Where should Trailhead’s HikesProvider be rendered so the Log tab, the Stats tab and the /hikes/[id] screen can all read it?

","options":[{"text":"Inside (tabs)/index.tsx, since the log owns the hikes.","why":"Siblings and the detail screen are outside that component, so they can’t read its context."},{"text":"In src/app/_layout.tsx, around the root Stack.","why":"Correct. Everything rendered by the root layout, tabs and stack screens alike, is inside the provider."},{"text":"In every screen that needs it, each with its own copy.","why":"Separate providers mean separate state; an edit on one screen wouldn’t show on the others."}],"answer":1}],"exercise":{"kind":"web","mode":"js","starter":{"js":"// Trailhead keeps hikes sorted newest first (dates are 'YYYY-MM-DD').\nfunction hikesReducer(state, action) {\n switch (action.type) {\n case 'added':\n state.push(action.hike);\n return state;\n case 'updated': {\n const hike = state.find((h) => h.id === action.id);\n Object.assign(hike, action.changes);\n return state;\n }\n case 'deleted':\n return state.filter((h) => h.id !== action.id);\n case 'favoriteToggled': {\n const hike = state.find((h) => h.id === action.id);\n hike.favorite = !hike.favorite;\n return state;\n }\n default:\n throw new Error('Unknown action ' + action.type);\n }\n}\n\nconst start = [\n { id: 'a', name: 'Lake Trail', date: '2026-10-19', distanceKm: 11.2, favorite: false },\n { id: 'b', name: 'Ridge Loop', date: '2026-10-04', distanceKm: 8.4, favorite: true },\n];\nconsole.log(hikesReducer(start, { type: 'added', hike: { id: 'c', name: 'Fern Gully', date: '2026-10-10', distanceKm: 3.6, favorite: false } }).map((h) => h.id));\n"},"solution":{"js":"const byNewest = (a, b) => b.date.localeCompare(a.date);\n\nfunction hikesReducer(state, action) {\n switch (action.type) {\n case 'added':\n if (state.some((h) => h.id === action.hike.id)) return state;\n return [...state, action.hike].sort(byNewest);\n case 'updated': {\n if (!state.some((h) => h.id === action.id)) return state;\n return state\n .map((h) => (h.id === action.id ? { ...h, ...action.changes, id: h.id } : h))\n .sort(byNewest);\n }\n case 'deleted':\n return state.filter((h) => h.id !== action.id);\n case 'favoriteToggled':\n return state.map((h) => (h.id === action.id ? { ...h, favorite: !h.favorite } : h));\n default:\n return state;\n }\n}\n\nconst start = [\n { id: 'a', name: 'Lake Trail', date: '2026-10-19', distanceKm: 11.2, favorite: false },\n { id: 'b', name: 'Ridge Loop', date: '2026-10-04', distanceKm: 8.4, favorite: true },\n];\nconsole.log(hikesReducer(start, { type: 'added', hike: { id: 'c', name: 'Fern Gully', date: '2026-10-10', distanceKm: 3.6, favorite: false } }).map((h) => h.id));\n"},"checks":[{"id":"add-sorted","test":"const mk = () => [{ id: 'a', name: 'Lake Trail', date: '2026-10-19', distanceKm: 11.2, favorite: false }, { id: 'b', name: 'Ridge Loop', date: '2026-10-04', distanceKm: 8.4, favorite: true }]; const s = mk(); const n = hikesReducer(s, { type: 'added', hike: { id: 'c', name: 'Fern', date: '2026-10-10', distanceKm: 3.6, favorite: false } }); return n !== s && n.map((h) => h.id).join() === 'a,c,b' && s.length === 2;"},{"id":"add-duplicate","test":"const mk = () => [{ id: 'a', name: 'Lake Trail', date: '2026-10-19', distanceKm: 11.2, favorite: false }, { id: 'b', name: 'Ridge Loop', date: '2026-10-04', distanceKm: 8.4, favorite: true }]; const s = mk(); const n = hikesReducer(s, { type: 'added', hike: { id: 'a', name: 'Copy', date: '2026-01-01', distanceKm: 1, favorite: false } }); return n === s;"},{"id":"update","test":"const mk = () => [{ id: 'a', name: 'Lake Trail', date: '2026-10-19', distanceKm: 11.2, favorite: false }, { id: 'b', name: 'Ridge Loop', date: '2026-10-04', distanceKm: 8.4, favorite: true }]; const s = mk(); const n = hikesReducer(s, { type: 'updated', id: 'b', changes: { name: 'Ridge Loop East', date: '2026-10-25', id: 'zzz' } }); return n !== s && n[0].id === 'b' && n[0].name === 'Ridge Loop East' && s[1].name === 'Ridge Loop' && n.length === 2;"},{"id":"toggle","test":"const mk = () => [{ id: 'a', name: 'Lake Trail', date: '2026-10-19', distanceKm: 11.2, favorite: false }, { id: 'b', name: 'Ridge Loop', date: '2026-10-04', distanceKm: 8.4, favorite: true }]; const s = mk(); const n = hikesReducer(s, { type: 'favoriteToggled', id: 'a' }); return n !== s && n[0].favorite === true && s[0].favorite === false && n[1] === s[1];"},{"id":"delete","test":"const mk = () => [{ id: 'a', name: 'Lake Trail', date: '2026-10-19', distanceKm: 11.2, favorite: false }, { id: 'b', name: 'Ridge Loop', date: '2026-10-04', distanceKm: 8.4, favorite: true }]; const s = mk(); const n = hikesReducer(s, { type: 'deleted', id: 'a' }); return n.length === 1 && n[0].id === 'b' && s.length === 2;"},{"id":"unknown","test":"const mk = () => [{ id: 'a', name: 'Lake Trail', date: '2026-10-19', distanceKm: 11.2, favorite: false }, { id: 'b', name: 'Ridge Loop', date: '2026-10-04', distanceKm: 8.4, favorite: true }]; const s = mk(); let n; try { n = hikesReducer(s, { type: 'somethingElse' }); } catch { return false; } return n === s;"}],"title":"Make the hikes reducer immutable","prompt":"

Trailhead’s hikesReducer mutates state, so screens don’t update. Rewrite it so every case returns new arrays and objects and never changes state. Keep the list sorted newest first by date (YYYY-MM-DD strings).

\n\n","hints":["Create a comparator once: const byNewest = (a, b) => b.date.localeCompare(a.date);. [...state, hike].sort(byNewest) sorts a copy.","state.map((h) => (h.id === action.id ? { ...h, ...changes } : h)) copies only the changed hike. Put id: h.id after the spread so it wins.","Returning state itself (same reference) is how a reducer tells React that nothing changed."],"explanation":"

React decides whether to re-render by comparing references, so a reducer that mutates and returns the same array hides every change. The fixed version builds new arrays with spread, map, filter and a sort on a copy, creates a new object only for the hike that changed, and returns the original state when nothing should change (a duplicate add or an unknown action). Unchanged hikes keep their identity, which is exactly what lets memo(HikeRow) skip them.

\n","checkLabels":{"add-sorted":"Added hikes land in date order in a new array","add-duplicate":"Adding an existing id returns the same state","update":"Updates merge, re-sort, keep the id and don’t mutate","toggle":"Toggling a favorite copies only the changed hike","delete":"Deleting returns a new, shorter array","unknown":"Unknown actions return the same state without throwing"}},"words":641,"readMinutes":3}