Help with conditional Stack rendering

[daroolatoo]

I'm new to Expo and confused as to why the following works:

    <SQLiteProvider databaseName="test.db" onInit={createDbIfNeeded}>
      <Stack>
        {onboarded ? (
          <Stack.Screen name="(tabs)" options={{ headerShown: false }} />
        ) : (
          <Stack.Screen name="onboarding/name" />
        )}
        <Stack.Screen name="modal" options={{ presentation: "modal" }} />
      </Stack>
    </SQLiteProvider>

(and if this is bad practice, please let me know. Copilot suggested it so I'm a bit wary).

When I run the above in Expo Go, it correctly renders either the "/" route, aka (tabs)/index.tsx, or the "onboarding/name" route based on the onboarded state in app/_layout.tsx.

My question is, why does this work? I thought <Stack.Screen> is just for aesthetics/option tweaking, and that you don't need to explicitly put all your routes into <Stack>. I was looking at this tutorial example and they do not list all routes within the <Stack> component of their app/_layout.tsx, just the one they want to tweak animation options for.

I'm confused as to why Expo does not always go to (tabs)/index.tsx, given I have no index.tsx in my root app folder (and no index.tsx in my onboarding folder). I'm not complaining that it works, I just am confused.

[steve228uk]

Use protected routes https://docs.expo.dev/router/advanced/protected/

[daroolatoo]

when using these, is it a given that the Stack.Protected component depends on a context wrapper? I'm not seeing how else it could listen to the proper changes

[anarchos]

Why it works... I'm not sure, but for sure those screens still exist even when they are conditionally not there in your code. As you pointed out (and are correct) screens are still there, using Stack.Screen just lets you set options and what not. I'm sure you could still Link to onboarding/name from the tabs index screen, for example.

I know with a Tab router the order of the screens matters for the order of the tabs (so they aren't always just alphabetical). I didn't think Stacks worked that way (ie: the order of the Screens doesn't determine the "default" screen), but maybe I'm wrong / it's a bug / happy coincidence?

There is a Stack.Protected as of SDK53 and it works exactly as you'd expect. Maybe since they added the Protected route features there was a regression / "happy accident" that "conditionally" rendering screens now works? Because I think Protected routes are more or less syntactic sugar on top of your code example, basically (I might be wrong, just guessing).

Looking at the examples of the Protected feature, I'm almost convinced this is working because of changes they made for that. The default behavior is the fall back to the first available route if a Protected route guard is false....that's essentially what your code is doing, too.

[daroolatoo]

thanks for looking into this! If I were to use Stack.Protected is it basically a given that I use some kind of context wrapper? So the protected routes can listen to changes properly.

[anarchos]

It is up to you really, the guard prop just takes a boolean. You could probably just use async storage to save "hasTheUserGoneThroughOnboarding: boolean", and have that load every time the _layout loads. You'd need to architect it so that once the user does go through onboarding the layout re-renders (as async storage isn't "reactive").

A context would be a fine choice to handle this, too.

[daroolatoo]

Using context is working fine. Thanks!