{"id":"l-rn-3-2","courseId":"react-native-apps","lang":"en","kind":"lesson","summary":"Give Trailhead bottom tabs with a route group, add a hike detail screen with a dynamic [id] route, and read its params safely, remembering that params always arrive as strings.","html":"

Trailhead now has more than one place to be: the hike log, a stats page, and settings, plus a detail screen for each hike. The first three are peers that users switch between all the time; the detail screen is something you drill into and come back from. That’s the classic mobile shape: tabs for peers, a stack for drilling in.

\n

A route group for the tabs

\n

Here’s the file structure Trailhead uses:

\n
Text
src/app/\n  _layout.tsx          root Stack\n  (tabs)/\n    _layout.tsx        Tabs navigator\n    index.tsx          /          (Log)\n    stats.tsx          /stats\n    settings.tsx       /settings\n  hikes/\n    [id].tsx           /hikes/42  (pushed over the tabs)
\n

A folder in parentheses is a route group. It lets the three tab screens share a layout without adding anything to their URLs: (tabs)/stats.tsx is /stats, not /tabs/stats.

\n

The tab layout returns a Tabs navigator, one Tabs.Screen per tab, in the order they should appear:

\n
src/app/(tabs)/_layout.tsx
import Ionicons from '@expo/vector-icons/Ionicons';\nimport { Tabs } from 'expo-router';\n\nexport default function TabLayout() {\n  return (\n    <Tabs screenOptions={{ tabBarActiveTintColor: '#2f6f4e' }}>\n      <Tabs.Screen\n        name=\"index\"\n        options={{\n          title: 'Log',\n          tabBarIcon: ({ color, size }) => <Ionicons name=\"list\" color={color} size={size} />,\n        }}\n      />\n      <Tabs.Screen\n        name=\"stats\"\n        options={{\n          title: 'Stats',\n          tabBarIcon: ({ color, size }) => <Ionicons name=\"stats-chart\" color={color} size={size} />,\n        }}\n      />\n      <Tabs.Screen\n        name=\"settings\"\n        options={{\n          title: 'Settings',\n          tabBarIcon: ({ color, size }) => <Ionicons name=\"settings-outline\" color={color} size={size} />,\n        }}\n      />\n    </Tabs>\n  );\n}
\n

The root layout then puts the whole tab group into the Stack, with the group’s own header hidden (each tab has its own), followed by the detail route:

\n
src/app/_layout.tsx
import { Stack } from 'expo-router';\n\nexport default function RootLayout() {\n  return (\n    <Stack>\n      <Stack.Screen name=\"(tabs)\" options={{ headerShown: false }} />\n      <Stack.Screen name=\"hikes/[id]\" options={{ title: 'Hike' }} />\n    </Stack>\n  );\n}
\n

Because hikes/[id] belongs to the root Stack rather than to the tabs, opening a hike slides a full screen over the tab bar, and the back gesture returns to whichever tab you came from. That’s what most iOS and Android apps do, and it gives the detail screen the whole height of the phone.

\n

Two habits keep tabs pleasant. Keep them to between three and five top-level destinations users visit often; a sixth tab usually means some of them belong inside settings. And remember that tabs stay mounted once visited: switch from Log to Stats and back, and the log keeps its scroll position. That’s the behaviour users expect, so don’t reset it. If one tab needs its own drill-down screens that keep the tab bar visible, give that tab a folder with its own _layout.tsx returning a Stack; nesting navigators is just nesting folders.

\n\n

Dynamic routes and params

\n

A file named with square brackets, [id].tsx, matches any single URL segment and exposes it as a param named id. Read it with useLocalSearchParams:

\n
src/app/hikes/[id].tsx
import { Stack, useLocalSearchParams } from 'expo-router';\nimport { Text, View } from 'react-native';\nimport { useHike } from '../../state/hikes';\n\nexport default function HikeDetail() {\n  const { id } = useLocalSearchParams<{ id: string }>();\n  const hike = useHike(id);\n\n  if (!hike) {\n    return (\n      <View style={{ flex: 1, padding: 24 }}>\n        <Text>That hike doesn't exist anymore.</Text>\n      </View>\n    );\n  }\n\n  return (\n    <View style={{ flex: 1, padding: 16 }}>\n      <Stack.Screen options={{ title: hike.name }} />\n      <Text style={{ fontSize: 16 }}>{hike.distanceKm} km</Text>\n    </View>\n  );\n}
\n

To get there, link to the URL. Either build the string or let Expo Router fill in the pattern:

\n
TSX
<Link href={`/hikes/${hike.id}`}>{hike.name}</Link>\n\n<Link href={{ pathname: '/hikes/[id]', params: { id: hike.id } }}>{hike.name}</Link>
\n

Anything in params that isn’t part of the path becomes a query string: params: { id: hike.id, units: 'mi' } produces /hikes/42?units=mi, and the detail screen reads units with the same hook.

\n\n

Ids in params, data from state

\n

Pass the smallest thing that identifies the data, usually an id, and look the data up on the destination screen. Passing a whole hike object seems convenient, but params are serialized into the URL: the object becomes a string, a deep link can never recreate it, and if the user edits the hike, the detail screen shows the stale copy it was handed. The next lesson builds the shared state that useHike(id) reads from.

\n

useLocalSearchParams returns the params of the screen it’s called in, which is what you want almost always. Its sibling useGlobalSearchParams updates whenever any route changes, even routes in the background, which causes extra renders; reserve it for things like analytics that genuinely care about every navigation.

\n

Next, the state behind those lookups: one source of truth for hikes, shared by every tab and screen.

\n","toc":[{"id":"sec-1","text":"A route group for the tabs","level":2},{"id":"sec-2","text":"Dynamic routes and params","level":2},{"id":"sec-3","text":"Ids in params, data from state","level":2}],"takeaways":["A folder in parentheses, like (tabs), groups routes under a layout without adding a segment to the URL.","Put the tab navigator in (tabs)/_layout.tsx and push detail screens from the root Stack so they cover the tab bar.","A file named [id].tsx matches any single segment; read it with useLocalSearchParams().","Route params are strings (or arrays of strings), so convert and validate them before use.","Pass ids in params, never whole objects, and look the data up on the destination screen."],"further":[{"title":"Navigation layouts","url":"https://docs.expo.dev/router/basics/navigation-layouts/"},{"title":"Tabs","url":"https://docs.expo.dev/router/advanced/tabs/"},{"title":"URL parameters","url":"https://docs.expo.dev/router/reference/url-parameters/"}],"quiz":[{"q":"

What URL does src/app/(tabs)/stats.tsx serve?

","options":[{"text":"/(tabs)/stats","why":"Parentheses mark a group, and groups never appear in the URL."},{"text":"/tabs/stats","why":"The group name is dropped entirely, not just the parentheses."},{"text":"/stats","why":"Correct. The (tabs) group only decides which layout wraps the screen."}],"answer":2},{"q":"

The detail screen does this, and a hike with id 7 never matches. Why?

\n
TSX
const { id } = useLocalSearchParams<{ id: string }>();\nconst hike = hikes.find((h) => h.id === id); // h.id is a number
\n","options":[{"text":"useLocalSearchParams only works inside tab screens.","why":"It works in any route. The issue is the comparison, not where the hook runs."},{"text":"id is the string “7”, and 7 === "7" is false; convert with Number(id) and check the result.","why":"Correct. URL params are always strings. The generic only types them; it doesn’t convert anything."},{"text":"The route file must be called [hikeId].tsx for the param to arrive.","why":"The file name only sets the param’s name. [id].tsx gives you id."}],"answer":1},{"q":"

A teammate passes a whole hike object as a route param so the detail screen doesn’t need to look it up. What’s the main problem?

","options":[{"text":"Params are serialized into the URL, so the object gets stringified, deep links can’t recreate it, and the screen shows stale data after an edit.","why":"Correct. Pass the id and read the current hike from your state or storage on the destination screen."},{"text":"Route params are limited to one character.","why":"There’s no such limit. The problem is that URLs carry strings, not objects."},{"text":"Objects in params make the app crash on Android only.","why":"It misbehaves the same way on both platforms. It just doesn’t crash."},{"text":"Expo Router encrypts params, so it would be slow.","why":"Params aren’t encrypted; they’re part of a URL. Speed isn’t the issue."}],"answer":0}],"exercise":{"kind":"web","mode":"js","starter":{"js":"// params is whatever useLocalSearchParams() returned for /hikes/[id]\n// Return { id, units, photo } with real types and safe defaults.\nfunction parseHikeParams(params) {\n return { id: params.id, units: params.units, photo: params.photo };\n}\n\nconsole.log(parseHikeParams({ id: '42', units: 'MI', photo: '2' }));\nconsole.log(parseHikeParams({ id: 'abc' }));\n"},"solution":{"js":"function first(value) {\n return Array.isArray(value) ? value[0] : value;\n}\n\nfunction parseHikeParams(params) {\n const rawId = first(params.id);\n const id = /^\\d+$/.test(rawId ?? '') && Number(rawId) > 0 ? Number(rawId) : null;\n\n const rawUnits = String(first(params.units) ?? '').toLowerCase();\n const units = rawUnits === 'mi' ? 'mi' : 'km';\n\n const rawPhoto = first(params.photo);\n const photo = /^\\d+$/.test(rawPhoto ?? '') ? Number(rawPhoto) : 0;\n\n return { id, units, photo };\n}\n\nconsole.log(parseHikeParams({ id: '42', units: 'MI', photo: '2' }));\nconsole.log(parseHikeParams({ id: 'abc' }));\n"},"checks":[{"id":"valid","test":"return typeof parseHikeParams === 'function' && (() => { const r = parseHikeParams({ id: '42', units: 'mi', photo: '2' }); return r.id === 42 && r.units === 'mi' && r.photo === 2; })();"},{"id":"bad-id","test":"return (() => { const r = parseHikeParams({ id: 'abc' }); return r.id === null && r.units === 'km' && r.photo === 0; })() && parseHikeParams({ id: '0' }).id === null && parseHikeParams({ id: '4.5' }).id === null && parseHikeParams({ id: '-3' }).id === null && parseHikeParams({}).id === null;"},{"id":"units","test":"return parseHikeParams({ id: '1', units: 'MI' }).units === 'mi' && parseHikeParams({ id: '1', units: 'miles' }).units === 'km' && parseHikeParams({ id: '1' }).units === 'km';"},{"id":"photo","test":"return parseHikeParams({ id: '1', photo: '0' }).photo === 0 && parseHikeParams({ id: '1', photo: '3' }).photo === 3 && parseHikeParams({ id: '1', photo: 'x' }).photo === 0 && parseHikeParams({ id: '1', photo: '-2' }).photo === 0;"},{"id":"arrays","test":"const r = parseHikeParams({ id: ['7', '8'], units: ['mi', 'km'], photo: ['1'] }); return r.id === 7 && r.units === 'mi' && r.photo === 1;"}],"title":"Read route params safely","prompt":"

Trailhead’s detail screen at /hikes/[id] can be opened from the app, from a notification, or from an old link with anything in it. Write parseHikeParams(params) that takes the object from useLocalSearchParams() and returns { id, units, photo }:

\n\n

Any param may also arrive as an array of strings (a repeated query key). Use the first value.

\n","hints":["Write a tiny helper first: const first = (v) => Array.isArray(v) ? v[0] : v;.","/^\\d+$/ accepts only digits, so it rejects -3, 4.5 and abc in one test. Then check the number is above 0 for the id.","For units, lower-case the string and compare with 'mi'; everything else falls back to 'km'."],"explanation":"

Params come from a URL, so they’re strings or arrays of strings, never numbers, whatever the TypeScript generic says. Normalizing them in one pure function gives the screen real types and safe defaults, and turns a broken deep link into id: null, which the screen renders as a friendly “hike not found” instead of a crash. The digits-only regular expression is stricter than Number(), which happily accepts '4.5', ' 7 ' and '' (as 0).

\n","checkLabels":{"valid":"A normal set of params is converted to real types","bad-id":"Invalid or missing ids become null","units":"Units are case-insensitive and default to km","photo":"Photo index defaults to 0 for missing or invalid values","arrays":"Array params use their first value"}},"words":659,"readMinutes":3}