Skip to content
tezvyn:

React Navigation State: The App's Internal Map

Source: reactnavigation.orgHardHow cards are made

React Navigation State: The App's Internal Map

Think of React Navigation's state as a JS object that's the single source of truth for your app's screen history. It's essential for advanced tasks like state persistence or deep linking. The footgun: nested navigator state isn't guaranteed to exist.

Why it exists

React Navigation needs a predictable, serializable structure to manage where the user is, where they've been, and what screens are available. This internal state object allows for complex features like state persistence, deep linking, and stack resets, which go beyond just moving between screens.

The mental model

Think of the navigation state as a JavaScript object that is the single source of truth for your app's navigation. It's a detailed map and logbook combined: it describes the layout of all your navigators (the map) and records the user's path through them (the logbook). Every call to navigation.navigate() is an operation that transforms this state object.

How it works

The state is a JS object with several core properties. The type identifies the navigator ('stack', 'tab'). The routeNames array lists all defined screens. The routes array represents the history, containing route objects for each screen visited. The index points to the currently focused route in the routes array. Each route object has a unique key, a name, and optional params. Crucially, a route object can also have a state property, which holds the navigation state for a child navigator nested inside that screen.

When to use it

You'll need to understand and manipulate the navigation state for advanced use cases. Three common scenarios are: first, state persistence, where you save the state to storage and restore it on app launch; second, deep linking, where you construct a state object from a URL; third, resetting the navigation stack, such as clearing history after a user logs out.

When not to use it

For everyday navigation like moving between screens or passing simple parameters, use the provided hooks and functions like navigation.navigate(). Directly manipulating the state object for simple tasks is overly complex and error-prone. Treat the state object as read-only unless you are implementing a specific, advanced pattern that requires it.

One canonical example

A stack navigator has two routes, 'Home' and 'Settings'. The user is on 'Settings'. The state object would look like this: { type: 'stack', routeNames: ['Home', 'Settings'], routes: [ { key: 'home-1', name: 'Home' }, { key: 'settings-1', name: 'Settings' } ], index: 1 }. This object shows there are two possible routes, the history contains 'Home' then 'Settings', and the currently active screen is 'Settings' because its index in the routes array is 1.

Interview question

When is direct manipulation of React Navigation's state object most appropriate?

  • a.To navigate to a specific screen and pass parameters to it.
  • b.To programmatically return to the previous screen in the navigation history.
  • c.To re-establish the full navigation stack and active screen from a saved state after an app restart.Correct
  • d.To dynamically change the header title of the currently focused screen.
Why?

The card states that direct manipulation of the navigation state is for advanced use cases like state persistence, where you save and restore the app's navigation history. Options A, B, and D describe common navigation tasks that are handled by higher-level functions like navigation.navigate(), navigation.setOptions(), or navigation.goBack(), for which direct state manipulation is explicitly advised against.

Just read this? Test yourself on what you have been reading.

Read the original → reactnavigation.org

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on react native — each one lists the topics its interview covers.

See open roles