{"id":"l-rn-4-1","courseId":"react-native-apps","lang":"en","kind":"lesson","summary":"Load Trailhead’s trail catalog from a server with fetch, model loading, error, empty and success states explicitly, cancel stale requests, and handle the flaky networks phones live on.","html":"

Up to now, Trailhead’s data has lived on the phone. The next feature, a catalog of trails near you, comes from a server. On a laptop with office Wi-Fi, a request is a formality. On a phone at a trailhead with one bar of signal, it’s the slowest and least reliable thing your app does: requests take seconds, fail halfway, or never come back. Designing for that is most of the work.

\n

Four states, one value

\n

Every screen that loads data has at least four states the user can see: loading, error, empty (it loaded, and there’s nothing), and success. Model them as one value, so impossible combinations can’t happen:

\n
src/lib/types.ts
export type Trail = { id: string; name: string; lengthKm: number; difficulty: 'easy' | 'moderate' | 'hard' };\n\nexport type Load<T> =\n  | { status: 'loading' }\n  | { status: 'error'; message: string }\n  | { status: 'success'; data: T };
\n

Empty isn’t a separate status; it’s success with zero items, and the screen decides how to show it.

\n
\n The screen starts in loading. A successful response moves it to success, which shows either the list or an empty state. A failure moves it to error, and Retry moves it back to loading. Pull to refresh goes from success back to loading.\n \n loading\n \n success\n list or empty state\n \n error\n message + Retry\n \n response ok\n \n fails\n \n Retry\n \n refresh\n
A request moves between explicit states
\n

Fetching with cleanup

\n
src/app/(tabs)/explore.tsx
import { useCallback, useEffect, useState } from 'react';\nimport { ActivityIndicator, FlatList, Pressable, Text, View } from 'react-native';\nimport type { Load, Trail } from '../../lib/types';\n\nconst API = process.env.EXPO_PUBLIC_API_URL;\n\nasync function getTrails(signal: AbortSignal): Promise<Trail[]> {\n  const res = await fetch(`${API}/trails?near=current`, { signal });\n  if (!res.ok) throw new Error(`Server responded ${res.status}`);\n  return res.json();\n}\n\nexport default function Explore() {\n  const [state, setState] = useState<Load<Trail[]>>({ status: 'loading' });\n  const [attempt, setAttempt] = useState(0);\n  const retry = useCallback(() => setAttempt((n) => n + 1), []);\n\n  useEffect(() => {\n    const controller = new AbortController();\n    setState({ status: 'loading' });\n    getTrails(controller.signal)\n      .then((data) => setState({ status: 'success', data }))\n      .catch(() => {\n        if (controller.signal.aborted) return;\n        setState({ status: 'error', message: 'Could not load trails. Check your connection and try again.' });\n      });\n    return () => controller.abort();\n  }, [attempt]);\n\n  if (state.status === 'loading') return <ActivityIndicator style={{ flex: 1 }} size=\"large\" />;\n\n  if (state.status === 'error') {\n    return (\n      <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center', gap: 12, padding: 24 }}>\n        <Text style={{ textAlign: 'center' }}>{state.message}</Text>\n        <Pressable onPress={retry} accessibilityRole=\"button\"><Text>Try again</Text></Pressable>\n      </View>\n    );\n  }\n\n  return (\n    <FlatList\n      data={state.data}\n      keyExtractor={(t) => t.id}\n      renderItem={({ item }) => <Text style={{ padding: 16 }}>{item.name} · {item.lengthKm} km</Text>}\n      ListEmptyComponent={<Text style={{ padding: 24 }}>No trails within 50 km. Try a wider search.</Text>}\n    />\n  );\n}
\n

Three details carry the weight. res.ok is checked by hand, because fetch treats a 500 as a successful delivery of bad news. The AbortController cancels the request in the cleanup, so leaving the screen (or retrying) never lets a stale response overwrite a fresh one. And the error message tells the user what to do, rather than printing TypeError: Network request failed.

\n

EXPO_PUBLIC_API_URL comes from a .env file. Variables prefixed with EXPO_PUBLIC_ are inlined into the JavaScript bundle, which also means they’re readable by anyone who unpacks your app. Put URLs there, never secret keys.

\n\n

Pull to refresh and slow networks

\n

Users expect to drag a list down to reload it. FlatList supports that with two props:

\n
TSX
<FlatList\n  // …\n  refreshing={refreshing}\n  onRefresh={async () => {\n    setRefreshing(true);\n    try { setState({ status: 'success', data: await getTrails(new AbortController().signal) }); }\n    catch { /* keep the old list and show a short \"Couldn't refresh\" message */ }\n    finally { setRefreshing(false); }\n  }}\n/>
\n

A refresh keeps the old list visible while it loads, which is friendlier than the full-screen spinner of the first load. If the refresh fails, keep the old data and show a short message, instead of replacing a perfectly good list with an error screen.

\n

Flaky networks also argue for automatic retries with a growing delay between attempts (1 s, 2 s, 4 s), so a brief signal drop recovers by itself. Only retry what can succeed later: a timeout or a 503 might, but a 404 or a 401 won’t, so failing fast is kinder. You’ll write that helper in the exercise.

\n

Offline is a normal state, not an error

\n

For a hiking app, no signal is the expected condition for hours at a time. Treat it that way. Show the last list you loaded, with a quiet banner saying when it was updated, instead of an error screen. Let users keep logging hikes, save them on the device, and send them when the connection returns. The community package @react-native-community/netinfo tells you whether the device is connected and notifies you when that changes, which is the moment to retry queued work.

\n

None of that needs to be clever on day one. What matters is the decision: for each screen, what does the user see with no network? Write the answer down before writing the fetch, and design the empty, error and offline states with the same care as the happy path.

\n

When to use a data library

\n

The code above is fine for one screen. Across a real app you’d repeat it everywhere, and you’d still lack caching (revisit a screen and see data instantly), request deduplication, background refetching and retries. TanStack Query handles all of that with useQuery, and its docs include the small React Native setup that refetches when the app returns to the foreground. Learn the manual version first so you know what the library is doing, then use the library in production.

\n

Next: data that has to survive without any network at all, stored on the device.

\n","toc":[{"id":"sec-1","text":"Four states, one value","level":2},{"id":"sec-2","text":"Fetching with cleanup","level":2},{"id":"sec-3","text":"Pull to refresh and slow networks","level":2},{"id":"sec-4","text":"Offline is a normal state, not an error","level":2},{"id":"sec-5","text":"When to use a data library","level":2}],"takeaways":["Model a request as one status value (loading, error or success) instead of several booleans that can contradict each other.","fetch only rejects on network failure; check response.ok yourself for 404 and 500 responses.","Abort in-flight requests in the effect’s cleanup, because users leave screens before slow requests finish.","Every list that loads data needs four designed states, including an empty state and an error state with a retry button.","On a phone, localhost is the phone itself; point development builds at your computer’s network address or a deployed API."],"further":[{"title":"Networking","url":"https://reactnative.dev/docs/network"},{"title":"Using fetch","url":"https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch"},{"title":"RefreshControl","url":"https://reactnative.dev/docs/refreshcontrol"}],"quiz":[{"q":"

Trailhead’s API returns 404 Not Found for a deleted trail. What does await fetch(url) do?

","options":[{"text":"It throws, so the catch block handles it.","why":"fetch only rejects when no response arrives at all (offline, DNS failure, aborted). A 404 is a response."},{"text":"It resolves with a response whose ok is false and status is 404, which you must check.","why":"Correct. Check if (!res.ok) and throw or handle it yourself."},{"text":"It resolves with undefined.","why":"fetch always resolves with a Response object when the server answers, whatever the status code."}],"answer":1},{"q":"

A user opens a trail’s detail screen and immediately goes back. The request finishes two seconds later and calls setState. What should the effect have done?

","options":[{"text":"Nothing; React Native ignores state updates from unmounted screens, so it’s harmless.","why":"The update is dropped, but the request still used data and battery, and a slow earlier response can overwrite a newer one when the id changes."},{"text":"Wrapped the call in setTimeout so it runs after navigation.","why":"Delaying the request doesn’t stop it from finishing after the screen is gone."},{"text":"Created an AbortController and called controller.abort() in the cleanup function.","why":"Correct. Aborting cancels the request on unmount or when the id changes, so stale responses never land."}],"answer":2},{"q":"

Which state shape best fits Trailhead’s catalog screen?

","options":[{"text":"{ status: 'loading' } | { status: 'error'; error: string } | { status: 'success'; trails: Trail[] }","why":"Correct. Only valid combinations exist, and TypeScript makes you handle each one."},{"text":"isLoading, hasError and trails as three separate useState calls.","why":"Nothing prevents isLoading and hasError being true together, or stale trails showing next to an error."},{"text":"trails: Trail[] | null, where null means loading or error.","why":"Loading and error look the same, so the screen can’t show the right message."},{"text":"A single trails array that starts empty.","why":"An empty array can’t tell “still loading” from “no trails nearby”, which are very different screens."}],"answer":0}],"exercise":{"kind":"web","mode":"js","starter":{"js":"const wait = (ms) => new Promise((resolve) => setTimeout(resolve, ms));\n\n// Run task(attempt). Retry failures with a doubling delay; give up fast on errors\n// that can't succeed later. `sleep` is injectable so tests don't really wait.\nasync function withRetry(task, { retries = 2, baseDelayMs = 1000, sleep = wait } = {}) {\n return task(1);\n}\n\n// Demo: fails twice with a 503, then succeeds.\nlet calls = 0;\nconst flaky = async () => {\n calls += 1;\n if (calls < 3) throw Object.assign(new Error('Service unavailable'), { status: 503 });\n return ['Ridge Loop', 'Lake Trail'];\n};\nwithRetry(flaky, { baseDelayMs: 10 }).then((v) => console.log('got', v, 'after', calls, 'calls'), (e) => console.log('failed:', e.message));\n"},"solution":{"js":"const wait = (ms) => new Promise((resolve) => setTimeout(resolve, ms));\n\nfunction isRetryable(error) {\n const status = error && error.status;\n if (typeof status !== 'number') return true; // network failure, timeout\n if (status === 408 || status === 429) return true;\n return status < 400 || status >= 500;\n}\n\nasync function withRetry(task, { retries = 2, baseDelayMs = 1000, sleep = wait } = {}) {\n for (let attempt = 1; ; attempt++) {\n try {\n return await task(attempt);\n } catch (error) {\n if (attempt > retries || !isRetryable(error)) throw error;\n await sleep(baseDelayMs * 2 ** (attempt - 1));\n }\n }\n}\n\nlet calls = 0;\nconst flaky = async () => {\n calls += 1;\n if (calls < 3) throw Object.assign(new Error('Service unavailable'), { status: 503 });\n return ['Ridge Loop', 'Lake Trail'];\n};\nwithRetry(flaky, { baseDelayMs: 10 }).then((v) => console.log('got', v, 'after', calls, 'calls'), (e) => console.log('failed:', e.message));\n"},"checks":[{"id":"returns-value","test":"const delays = []; const sleep = async (ms) => { delays.push(ms); }; const fail = (status) => Object.assign(new Error('x' + status), { status }); const v = await withRetry(async () => 'ok', { sleep }); return v === 'ok' && delays.length === 0;"},{"id":"retries-then-succeeds","test":"const delays = []; const sleep = async (ms) => { delays.push(ms); }; const fail = (status) => Object.assign(new Error('x' + status), { status }); let n = 0; const v = await withRetry(async (attempt) => { n++; if (attempt < 3) throw fail(503); return 'done'; }, { retries: 2, baseDelayMs: 100, sleep }); return v === 'done' && n === 3;"},{"id":"backoff","test":"const delays = []; const sleep = async (ms) => { delays.push(ms); }; const fail = (status) => Object.assign(new Error('x' + status), { status }); let n = 0; try { await withRetry(async () => { n++; throw new Error('offline'); }, { retries: 3, baseDelayMs: 100, sleep }); } catch {} return n === 4 && delays.join() === '100,200,400';"},{"id":"gives-up","test":"const delays = []; const sleep = async (ms) => { delays.push(ms); }; const fail = (status) => Object.assign(new Error('x' + status), { status }); let caught; try { await withRetry(async () => { throw fail(500); }, { retries: 1, baseDelayMs: 1, sleep }); } catch (e) { caught = e; } return caught instanceof Error && caught.status === 500;"},{"id":"no-retry-4xx","test":"const delays = []; const sleep = async (ms) => { delays.push(ms); }; const fail = (status) => Object.assign(new Error('x' + status), { status }); let n = 0; let caught; try { await withRetry(async () => { n++; throw fail(404); }, { retries: 3, sleep }); } catch (e) { caught = e; } return n === 1 && caught?.status === 404 && delays.length === 0;"},{"id":"retry-429","test":"const delays = []; const sleep = async (ms) => { delays.push(ms); }; const fail = (status) => Object.assign(new Error('x' + status), { status }); let n = 0; const v = await withRetry(async () => { n++; if (n === 1) throw fail(429); if (n === 2) throw fail(408); return 'ok'; }, { retries: 2, baseDelayMs: 50, sleep }); return v === 'ok' && n === 3 && delays.join() === '50,100';"}],"title":"Retry flaky requests with backoff","prompt":"

Implement withRetry(task, { retries, baseDelayMs, sleep }) for Trailhead’s API calls on bad mountain signal.

\n\n

Always wait with the sleep you were given, so the checks can record the delays.

\n","hints":["A for (let attempt = 1; ; attempt++) loop with try { return await task(attempt); } catch (error) { … } inside reads more simply than recursion.","In the catch, give up (throw error) when attempt > retries or the error isn’t retryable; otherwise await sleep(baseDelayMs * 2 ** (attempt - 1)).","Write isRetryable(error) separately: no numeric status → true; 408 or 429 → true; otherwise retry only when status >= 500."],"explanation":"

Exponential backoff gives a brief signal drop time to recover without hammering a struggling server, and classifying errors keeps the app from retrying requests that will never work: a 404 or 401 fails the same way three times, just slower. Injecting sleep is a small design choice with a big payoff: production uses a real timer, and tests run instantly while still checking the exact delays. Libraries like TanStack Query apply the same policy for you.

\n","checkLabels":{"returns-value":"A successful task resolves with its value, without waiting","retries-then-succeeds":"A task that fails twice then succeeds resolves","backoff":"Delays double between attempts (100, 200, 400)","gives-up":"After the last attempt, the last error is thrown","no-retry-4xx":"A 404 is thrown immediately without retrying","retry-429":"429 and 408 responses are retried"}},"words":661,"readMinutes":3}