The future API

[nandorojo]

I'm going to jot down some thoughts about what navigation should look like. Feedback welcome.

There are a few different concepts to deal with:

1. Getting around from one "page" to another
2. Opening "modals" which don't take you to another "page"
3. Knowing what to display

1. Getting around from one page to another

I've found that the most elegant solution to get around an app is a URL. Instead of navigate('artists'), we should do linkTo('/artists').

For native, in our linking.config, we define all the mappings of URL → state. On web, we leave linking={undefined}, and defer to Next file system routing for getting around from page-to-page.

2. Modals 😱

This is a tricky one. Sometimes, modals should be reflected in URLs. But maybe there are cases where they shouldn't.

Here's the solution I think could work. Create a web-only modal stack per Next.js page. The modal should show based on the URL. Example in this tweet.

Each "modal" (which is technically a screen) would pop on top of the base screen, depending on the URL. This is all handled by Next.js' shallow routing. To close it, you just goBack. Meanwhile, on native, you just use stackPresentation: 'modal' with the native-stack.

Caveats

Are there times when you want to open modals but not change the URL? Presumably you could "shallow" route to the current pathname on web using as, but then it won't deep link there on native. I guess that's fine. Need to give it some thought.

3. What to display

React Navigation handles this on native elegantly.

On web, next router does too. Except for modals. My current method was to make a react-navigation stack per Next.js page on web. For my native-stack, I use the same screens, and make sure to give them the same name. Holy shit is that a fragile approach. Luckily TypeScript ensures that I use the same screen names (I guess), but I really don't like it. URLs are much more reliable IMO.

What's next

I think all APIs should be consolidated into URLs. Stacks on web should render per-page based on the URL. This helps with code splitting too, I suppose.

On native, you should have a single native-stack that has all of your screens. You should use linking.config to map URL → screen. If you need to push multiple of the same screen on top of each other, you should use the getId field on react-navigation's <Stack.Screen /> component.

We should get around from page-to-page like so:

<Link to="/artists/djkhaled"></Link>

// or
linkTo('/artists/djkhaled')

We can open modals like so.

openModal('edit') // this needs intellisense! 

Now that I think about it, maybe opening modals should be constrained to URLs too. The only problem is, they're less typed.

Maybe it should be this?

linkTo('/artists/djkhaled/edit')

Oof, I don't know. This is hard.

What about query parameters?

There needs to be a better abstraction for using query parameters as state.

I often want to do this:

beatgig.com/search?query=djkhaled

I end up creating a useQuery.web.ts that uses the URL params on web, and local state on native. Don't love that approach. We need something more standardized.

[nandorojo]

One crazy cool thing would be to use typescript's new string literal syntax for typed URL paths. Types are essential. But 1) expo doesn't support these for some reason, so we need to figure that out, and 2) I'm not a TS grand wizard.

[cmaycumber]

I guess my biggest question is the single stack approach on native.

Do you have a Tab Navigator in your application, if so how are you choosing to handle it across web and mobile? This has been one of the hardest things for me to solve personally because I would like to have the native tabs on iOS and Android but also provide custom tabs on the web that might render at the top or bottom based on desktop size.

My biggest fear with a single Root stack approach which I use for most screens in my application is losing some of the "behind the scenes" functionality that the Tab Navigator provides (Maybe it's not all that special and a custom tab will work just fine, I really don't know).

[nandorojo]

I do have a tab navigator. Every tab renders the same stack, the only difference being the initialRouteName.

The linking.config lets you determine which tab screen should open in from deep links. It also lets you set the initial route name, such that if you open a deep link to /artists/djkhaled, you can have the artist page pop on top of home.

A benefit I've found of a single stack (specifically with Native stack, that's important) is that you can open any screen from anywhere Instagram-style.

[cmaycumber]

Sweet that's awesome. That is a good idea, do you think web would suffer at all performance-wise rendering all the screens for each page?

Otherwise, that approach makes a lot of sense to me, I'll probably start implementing it that way.

[nandorojo]

Also, you can always jump from one tab to another as long as the tab names don't match the screen names in the nested stack.

That's certainly another hard problem, though.

I suppose I've come to view my app as letting you open any screen from anywhere, where the tabs are just starting points. I know it might not work for every app, but it's the experience I've felt I get when I use Instagram and just open profiles and comments from anywhere.

[cmaycumber]

I suppose I've come to view my app as letting you open any screen from anywhere, where the tabs are just starting points. I know it might not work for every app, but it's the experience I've felt I get when I use Instagram and just open profiles and comments from anywhere.

I think this is definitely the best experience in my opinion as well, and it opens up the opportunity for the largest amount of flexibility. Keeping track of a bunch of navigators quickly becomes a huge headache.

[nandorojo]

Oh yeah web would definitely suffer, but my web approach is totally different.

On web, next router does too. Except for modals. My current method was to make a react-navigation stack per Next.js page on web.

So on native, I have a single native-stack with every screen.

But on web, I create a stack per-Next.js page. The stacks on web are only there for pages that use modals.

This works very well. The problem is, it doesn't reflect in the URL at all, so my future plan is to (maybe) circumvent React navigation altogether on web, and use my own ModalStack that renders modals based on the next router state.

I have a proof of concept made, but I haven't implemented it much on BeatGig yet since I'm focusing on making our native app currently.

[nandorojo]

Or did I misread that, are you asking if web suffers from importing every screen from its given stack?

I haven't noted a difference, but you could always use lazy imports. I stopped doing that because it gave me slow startup times in dev and messed with my fast refresh. I've found it to be fine.

[cmaycumber]

No, you read it correctly, I was talking about the root stack in its entirety. I'm less worried about the required modals associated with that stack being imported.

[nandorojo]

Got it, let me know if I should clarify.

Single stack on native, used in many places based on its initialRouteName.

Then, a stack per-Next.js page on web, whose screen names match those from the native stack. Or they should open based on URL path, in which case we configure their native screens using linking.config.

[cmaycumber]

Like this approach a lot. I'll probably start moving some pieces around in my repo today to start moving toward this approach.

[nandorojo]

I wish I'd done it sooner re the URL paths. I have deep linking set up perfectly thanks to linking config, and the new getId prop on screens means I no longer even need to use push (like when I'm opening one artist screen on top of another)

There are some exceptions to the rule here. For instance, you usually don't want the first screen of tab A pushing on top of a screen in tab B. But with the linking config, this would be solved easily.

The alternate API that exists now would be to use navigate with a nested screen param. But I find that much less elegant.

[nandorojo]

Also regarding monorepo. It might just be worth moving core into this package. The only reason I made that was to support Gatsby too. But I think Next is a way better fit for RN and don't plan to maintain the Gatsby lib.

[nandorojo]

One idea: what if screen names matched next.js page file paths?

<Screen name="/artists/[slug]" />

The reason this is convenient is we could just pass those paths to the linking.config.

I really like the mental model of URLs over semantic names.

The problem with this idea is I don't see how it could play nicely with nested navigators.

Say we wanted this:

const Routes = { artist: "/artists/[slug]" }

const linking = {
 config: { [Routes.artist]: '/artists/:slug' }
}

If possible, this could be really cool. We could even have a function that transforms the Next.js syntax into the React Navigation syntax.

The issue is, what if that artist screen is in a stack, and that stack nested inside of a tab navigator. Suddenly, that URL should really point to the tab. So it should be the tab that has the path for /artists, and the nested screen that handles the rest of the URL.

Given the nature of nested navigators, I'm not sure how possible this is. But I am certain that I would prefer to stay away from names if possible, so I'm going to give this more thought.

[nandorojo]

I've been using my modal stack on web for a new big feature I'm building on BeatGig. It's working seriously so well, I am loving it.