Academy
hardReact Native#8

Navigation deep link handling

Prompt

Configure deep linking for a React Navigation stack so that opening the app via "myapp://profile/42" navigates directly to the Profile screen with userId 42.

Solution

const linking = {
  prefixes: ['myapp://'],
  config: {
    screens: {
      Home: '',
      Profile: 'profile/:userId',
    },
  },
}
// Pass linking prop to NavigationContainer: <NavigationContainer linking={linking}>
Mentor's take

Deep linking exists because navigation state is serializable: the linking config is a declarative bidirectional mapping between URLs and that state. prefixes declares which URLs belong to you (custom schemes like myapp://, plus https domains for universal/app links); config.screens maps paths to screen names, with :userId segments parsed straight into route.params. Handing this to NavigationContainer covers both hard cases for free: the cold start (app launched by the URL — the container resolves the initial state from it) and the warm link (app already running — it navigates in place).

The senior caveat: the JS config is only half the feature. The scheme itself is registered natively — CFBundleURLTypes on iOS, an intent filter in AndroidManifest.xml (or the scheme field in Expo's app config) — and verified https links need Associated Domains / assetlinks.json. And you test from the terminal, not by tapping links in Notes: xcrun simctl openurl booted "myapp://profile/42" and adb shell am start -W -a android.intent.action.VIEW -d "myapp://profile/42" exercise the same resolution production traffic hits, deterministically covering cold and warm starts.

Red flag: manually parsing Linking.getInitialURL() and calling navigate imperatively — that re-implements what the config does and usually misses the cold-start race.

Say it: "The linking config declaratively maps URLs to navigation state — cold start and warm link both — and I test it with simctl and adb because that's the path production traffic takes."