React Native Auth Flows: Conditional Navigators
Think of your app as having two sets of maps: one for guests, one for members. React Navigation swaps the entire map when a user logs in, not just moves them. This is the key to preventing users from back-navigating to the login screen after.
Why it exists
Apps need to strictly separate screens for authenticated and unauthenticated users. A logged-in user should never be able to use the hardware back button to return to the login screen, and a logged-out user must not access private app content. This requires more than simply navigating from one screen to another; it requires changing the fundamental navigation structure.
The mental model
Don't think of it as navigating between a login screen and a home screen. Instead, picture two entirely separate sets of screens, or navigation graphs. One set is for the authentication flow (Login, SignUp, ForgotPassword). The other is for the main application (Home, Profile, Settings). Based on the user's login state, you render one set or the other, completely swapping them out.
How it works
React Navigation handles this with conditional screen configuration. You define screens within a navigator but add an if property to each. This property takes a hook, like useIsSignedIn, that returns a boolean. When the app state changes (e.g., a user logs in), the hook's return value flips. React Navigation detects this, automatically unmounts all screens that no longer match their condition, and mounts the new set of screens that now do. This means the SignInScreen is literally removed from the navigator and replaced by the HomeScreen.
When to use it
This is the standard pattern for almost any React Native app with a login wall. Use it to manage the transition between public-facing authentication screens and the private, user-specific content of your main application. It's triggered when the app first loads (by checking a stored token from SecureStore) and when the user explicitly signs in or out.
When not to use it
This pattern is for top-level authentication state. Do not use it for conditional UI within an already-authenticated part of the app. For example, showing an "Admin" button to certain users is better handled with simple conditional rendering inside a component, not by swapping out entire navigators.
One canonical example
A common setup involves a React Context that provides an isSignedIn boolean and functions to signIn and signOut. The root navigator component consumes this context. It then conditionally defines its screens: if: isSignedIn for the main app screens (Home, Profile) and if: !isSignedIn for the auth screens (Login, Register). When a user successfully logs in, the signIn function updates the context, which triggers React Navigation to automatically swap the visible screens.
Interview question
What is the main advantage of using conditional navigators for authentication in React Native?
- a.It ensures a clear separation of navigation history, preventing authenticated users from returning to login screens.Correct
- b.It dynamically loads screen components, reducing the initial bundle size for users.
- c.It allows for conditional rendering of UI elements within screens based on user permissions.
- d.It simplifies the process of managing user session tokens and authentication state.
Why? this is the answer
The card states that conditional navigators are crucial because "A logged-in user should never be able to use the hardware back button to return to the login screen," which is achieved by completely swapping navigation graphs. Option C is a common misconception, as the card explicitly advises against using this pattern for conditional UI within an authenticated part of the app.
Just read this? Test yourself on what you have been reading.
Read the original → reactnavigation.org
- #react native
- #react navigation
- #authentication
- #mobile
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.
We are hiring for this. Open roles that interview on react native — each one lists the topics its interview covers.
See open roles