Jed Bartausky:

Welcome back to another episode of the React Native Radio Podcast, episode 304 React Navigation version seven with Sketch Sahu.

Jamon Holmgren:

Hey everybody. I'm Jamon Holmgren, your host and friendly CTO of Infinite Red. None of my co-hosts are with me today. They left me all alone in the studio just sitting here all by my lunch. It's not true. I actually have an amazing guest with me today, Satya. Satya, can you introduce yourself?

Satyajit Sahoo:

Hello everyone. I'm Satya Zho and I'm a ER of React Navigation and I'm very excited to be on this podcast today and hello again. Yeah,

Jamon Holmgren:

I really appreciate you. We've known each other for a few years now, I think. Something like that. Of course, I've always followed your work. You do a lot of amazing work in the React native ecosystem and of course react navigation is a huge deal. So I want to get into all of those things. I have a ton of questions for you before we get into our topic. I do want to remind the audience that this episode is sponsored by Infinite Red. Infinite Red is a Premier React native development agency located fully remote in the us. If you're looking for React native expertise and more velocity for your next project, hey, that's a new part of my script here. Hit us up at Infinite Red slash React native. Don't forget to mention that you heard about us through the React Native Radio podcast. Alright, let's talk about React navigation version seven, which as of this recording is not yet fully released. I assume at some point it'll be released. We'll get into that. Before we get into the main changes with version seven, I want to first for those, there may be people in the audience who actually don't know what React navigation is, as funny as that is because it's so embedded into our industry. So can you give sort of the elevator pitch of what React Navigation is just like in general?

Satyajit Sahoo:

Well, it's a difficult thing to say because people don't usually ask this, but yeah, basically React Navigation is a navigation library. If you're coming from the web, you probably know React Router, which is a routing library, but React Navigation is not a routing library per se. The difference is on React router, it provides you with a logic, it provides you integration with the URLs. It provides you the logic to handle your views, but in the end, you are the one building all of the animations or any views, transitions or whatever you have, right? So React navigation builds upon that idea. It provides you the logic. In addition, it also provides you the UI to mimic how native apps have their UI set up, how native apps behave. Because native apps have a lot of different kind of navigation as in moving from screen to screen. They have tabs drawer, they have that navigation, which is just screens on top of each other. So React navigation provides all that. It handles all of the logic, it handles all of the ey, it handles all of the animations for you. So that means if you're building a mobile app, these things are very important and with React navigation, you don't need to build it again and again for every app.

Jamon Holmgren:

That is a great explanation. And I remember when React Navigation came into the scene, we were using other things, react Native Router Flux, and some other older libraries and it was a big deal when it came in. Now one of the questions we get is why is it called React Navigation? Not React native navigation? Can you use it with React as well? Yeah,

Satyajit Sahoo:

That's a good question and you can totally the Code of React navigation, at least when React navigation was added initially it did not have the structure, but in React navigation four, I think, I don't remember which version it was, we split it into multiple packages like React navigation core, then React navigation native, and we still have the same structure. So React navigation code is just logic. It is only JavaScript, pure JavaScript. There is no platform specific APIs, no React native APIs, no web APIs. It is pure JavaScript logic. So you can take that, you can write a web-based navigation library on top of that. Fun fact there is actually a library for native script using React navigation. Yeah, so you can use React navigation, native script even if it doesn't have anything to do with React native.

Jamon Holmgren:

That's really cool. So you've abstracted it to the point where it is kind of a general purpose navigation library and then it can be used in different contexts. I love that. So I really want to get into version seven. One of the things that I think is the coolest thing that I've seen about version seven, it's not released yet as of this recording, but it may be very soon. It brings back from version three, which you mentioned the static configuration API, but it doesn't totally roll back to it. It brings it in kind of a smart way with all the learnings of the years in between and how people use it. So I want to know what was sort of the main motivation between bringing back the static configuration API, and then how does that compare to the dynamic API that was introduced in version five and six?

Satyajit Sahoo:

Maybe first I should say why we brought the dynamic API so we can understand the motivation of the whole thing, right? So when React navigation was initially there, react navigation was from 2 3 1. Those versions, they had a static API. And the problem with that, it was very limited. You could not do a lot of things like if you have some advanced use cases, let's say you fetch a list of categories from the server, you want to show it in tabs. A lot of food ordering apps do that where they have a list of categories at tabs that you can swipe between. So those kind of ui, you could not really do that with the static API. And it was not just API, it was like the limitation of the whole design of how things are built. You could not even have a workaround to do that in the ACT navigation five, we wanted to support these advanced use cases.

Satyajit Sahoo:

So we took that, we rewrote it to a new dynamic API to make all of this possible. So it brought a lot of flexibility, but it also about problems. So one of the problem, biggest problem is with static API, all of the navigation tree is static. So we can easily travel all of the screens, we can see all of the screens at once, which makes it easy to say let's do deep links, TypeScript types, all of those things which are very easy to do with static conflict. I mean those are not the only things like in the future maybe we'll have data fetching or things like that. They need everything to be a static. So there is a lot of popularity with exporter or next js, right? They have a file system, API, and while the file system API is convenient, that's not the only reason.

Satyajit Sahoo:

By having a file system, a PA, what they can do, they can statically look at all of the screens in the app. They can statically define whatever data fetching methods there are, which makes it very easy to do advanced logic that is managed for you. So you do not have to implement everything by yourself. So in react navigation five or currently react navigation six, a lot of people had this problem of types because it was not static. Everything has to be defined separately and manually, which can be error prone and we cannot really guarantee it because react is runtime, the navigation tree will be fully run time. There is no build time guarantee that it is correct. So that is one of the problems we wanted to solve. And to be honest, that problem was not really solved with the old version of React navigation because I think back then type street was not as popular. Not everything was written with touch within mind. Now it's essential. I don't think I can code that If there is no rai, I cannot code. That's how it is,

Jamon Holmgren:

Right, exactly.

Satyajit Sahoo:

So yeah, it is very important to have rai. We wrote React navigation five with TypeScript. So yeah, that's something we wanted to really solve, but again, we did not want to lose the features that React navigation five gave us all of the dynamic stuff that gave us and another thing we had to consider that. So we have static A P and we have dynamic API. Now obviously I think it is easier for people to use the static API because then they will have easier deep links, easier types. But again, if somebody already has an app with some dynamic API or they want only one navigator to be dynamic, we want to support that. We want to make it possible to combine these two things. So that was another consideration. So we can combine dynamic and static API together and we can use it together because they are the same library in the end.

Satyajit Sahoo:

They're just different APIs at the same library. And it'll be very weird if they did not interact with each other. I think with the static API, we can handle a lot of things. We can handle type generation. I mean it doesn't give you the full possibility of what the manual typing can do, but it'll handle most of the types in that. Occasionally you might need to write your own type to say for example, you have very navigator specific operations that you want to do. In that case you might need to do your own type, but for most of the people, everything will be handled, which is great I think because for new people who are starting with negative, this is a challenging topic and handling all of that is really important. And then the other thing apart from type generation is deep link. So deep linking can be a lot of struggle. Yeah, it's

Jamon Holmgren:

Difficult.

Satyajit Sahoo:

Yeah, there is lot of factors to take in and again, it has to be manual with the navigation five, so have to have the same structure as the navigation tree, which can go out of date and it could be a problem. So that is another thing we wanted to take care of. Another thing we wanted to do is also automatic deep linking. Of course, I don't believe that every screen should be always deep link. I believe that people should have the ability to say, okay, I don't want this screen in the deep link and we don't want everything to be autogenerated because you might not like what is autogenerated. You might want to do your own thing. So that was another thing we wanted to handle, but we wanted to do it in such a way it provide provides you the flexibility. We handle autogeneration of the types, sorry, deep links for all of the screens. But you can go into that. You can say, okay, I don't want deep link for this screen, or I want the deep link for this screen to look different. Yeah, but in the end, a lot of the heavy parties automatically handled for you, which makes it very easy in the end.

Jamon Holmgren:

That makes a lot of sense. And those are kind of the biggest features that are coming in with this. Really what it sounds like you're doing is you're trying to preserve the developer experience and of having a lot of this stuff kind of handled for you, but with escape hatches. So you have these abilities to opt into, I want to handle this myself, I want to do things myself. I understand the trade-offs. I'm going to go this direction rather than sort of forcing them in one direction. And it's kind of funny because a lot of times when you're building a navigation library, here's a good example, authentication authentication's kind of a special case in some ways authentication flows and you often really, you do that stuff upfront, but then it doesn't really affect things after that too much. But it's still a special case. It's like a certain way where you're replacing the whole stack or maybe you have the ability to go look at certain screens, but you can't look at others and it's a whole thing. So I think it's very interesting in version seven how you've introduced the new, if I don't know what you call it, operator or whatever, that essentially allows you to add a conditional into routes that are connected to a react hook, which is very cool, like a react hook that returns a Boolean and that hook then controls whether that screen is mounted or not. So walk me through that a little bit, navigation flows and why you decided to go this direction with this sort of an API and what sort of the advantages of this are?

Satyajit Sahoo:

The main idea behind that is we don't want to lose functionality because just because we have a static API, what we want to do is make things simpler for people, but making things simpler should not mean that we lose what we could already do. So that is the main reason why we have this if condition, because authentication is a special case, but it's a very important case. Most apps have authentication unless it's, yeah, I think most apps that use do have authentication. So it is a very important case to handle. So that's why we came up with this idea. I mean I think it is a pretty cool way to do that. I haven't actually seen anybody do this where they take a hook as a option and unconditionally or based on the written type, they do things. But yeah, I think to answer your question, why we did that is to preserve the functionality you could already do and not have to learn a totally different way of doing things for authentication. If you go to the ation documentation now in the version seven documentation, we'll have static and dynamic A examples side by side, but most of the documentation stays the same. Of course. Sometimes things will be different because they're named different or the a, A looks a bit different, but most of the concepts needs to stay the same. That's the really main goal. We want the concepts to be the exact same. We don't want to have to learn a different way of doing things.

Jamon Holmgren:

I want to ask you about the implications beyond the API. Are there any performance implications? Is it faster? Is it about the same? Is it slower than version seven? Are there any performance implications?

Satyajit Sahoo:

I think it should be about the same, but there are some small optimizations we can make. I think I have made a small optimization, obviously I haven't measured that, but I think it should be exactly the same or tiny bit better, but do not expect anything.

Jamon Holmgren:

Totally. Yeah, I mean as long as it's pretty similar, I don't see there being an issue. I want to switch gears a little bit and talk about Expo router for a second because obviously Evan Bacon putting out the router, it's built on top of React navigation, which is cool. Do you think that the new static API might impact something like expo router? Have you talked with Evan about what he's doing over there? Is there any collaboration happening, that sort of thing?

Satyajit Sahoo:

Well, I have asked Evan to test out Ation seven, but they have a lot to do right now. I think Evan doesn't sleep and he is working all the time.

Jamon Holmgren:

I believe it.

Satyajit Sahoo:

Yeah, I have seen it. I mean I haven't seen it, but I have had meetings with him early in the morning, like how

Satyajit Sahoo:

Didn't sleep night. But yeah, I had talked to him about trying out ION seven because there have been a lot of changes apart from the API internally and we want to make sure that exporter doesn't break up because of the changes. So that's all we have for now. He hasn't given me any feedback yet, but in the end I think it should not really impact much. There are some fundamental differences on how Navigate works, for example, those will be impacted, but I think in the end the changes behave more like a web and more like Hower wants them to behave. So that should be good. Yeah,

Jamon Holmgren:

Yeah, totally. I mean obviously it's built on top of React navigation, expo router is, and since you're maintaining backwards compatibility, you are right, let me verify that. How backwards compatible is it?

Satyajit Sahoo:

There are some breaking changes. We change how Navigate works because I think the way Navigate worked before was not good. At least that's not how I would expect it to work. And I saw a lot of times that people did not expect it to work that way. So we changed how Navigate works and it is more like Web now. So previously if you navigate multiple times, it should stay on the same screen. So we changed that a bit. So if you're already on the screen, it'll stay on the screen. But if you're actually in a different screen and you navigate to another screen previously, what would happen if that screen was already in the stack? It would go back to previous screen.

Jamon Holmgren:

Oh, I see.

Satyajit Sahoo:

Yeah,

Jamon Holmgren:

Instead of pushing on a new one.

Satyajit Sahoo:

So now it wouldn't do that. It would push a new screen, which

Jamon Holmgren:

A new version of that screen or a new instance of that screen. Yeah,

Satyajit Sahoo:

I think it's more intuitive and the biggest thing is that's how it works on the web. If you're already on A URL, you can push the same UL again, it's going to stay there or click a link with the same UL, it's going to stay there, but it doesn't go back in the stack on the web. So we try to follow a similar approach so it's less confusing and more intuitive. And even with that, we have Navigate deprecated. So if you're upgrading to React navigation seven, you can just search replace all of the Navigate with Navigate Deprecated. That way your current code should stay working and you can move to the new Navigate behavior one by one without making everything and having to test everything at once. So yeah, I want to try to minimize the impact as much as I can. And the other changes are very, I would say small changes. There are not a lot of big changes that would cause issues for most people, mostly improvements. For example, one of the changes we made draw navigation, we removed the Reanimated implementation on the web. So now on the web when you withdraw is using CSS transitions, so that means a small performance. We are not loading a library, additional library on the web, so bundle size is smaller on the web. So yeah, I think most of the changes should not impact a lot of people or at least should have a positive impact.

Jamon Holmgren:

Totally makes sense. Yeah, that's awesome. And it sort of reflects in some ways the general shift toward a convergence between the web and mobile, at least within the React native ecosystem where it feels like we're learning from each other and we're trying to align more APIs and more user expectations and things like that. I think that's very exciting. Now this is kind of a little bit of a niche question. One of my engineers mentioned hitting some, we use MobX or in particular MobX State Tree to wrap screens and components with an observer higher order component. And one of my engineers mentioned hitting some issues with MobX observers in screens when trying an earlier alpha of version seven. I think this was actually pretty early on. Do you know if there have been any fixes or improvements in that area to support observer? Hi order

Satyajit Sahoo:

Components? I did not even hear about it. I have no idea and I cannot imagine why it would cause an issue because there is one thing in ION seven that we tried to be like do things the React way as much as possible. There are some hacks that is in the ION six version and we have refactored many things to be as reactive as possible. At least. I don't know there are any things that deviate from how React wants to do things. I cannot think why it would break. But if there is, I have seen some kind of issues with MOB and its users with React native Tvu for example, when I was mentioning that, because I think the reason it worked like that is because mob extracts the updates when you access a property. So maybe something related to that could be, if there is example, I am very curious to look at that.

Jamon Holmgren:

And the fix was pretty quick. He just simply had a wrapper screen and then a screen inside of it and that was fine. That was wrapped in Observer. But yeah, that's something we could probably provide to you. I don't know if it also affects, for example, legend State, which also uses an observer higher order component. MobX does have some potential issues with React compiler where Legend State does not have those same issues. It's just because of the API and how it works. So we have a little bit of thinking to do around MobX and MobX State Tree to see how we intend to kind of move into the new React compiler era. So we're kind of winding down to the end here. I do have a question beyond the static API and all cool stuff that you get there. I noticed you're bringing in some other features too. What other new features are you kind of excited about with version seven? I noticed that there's a new button component that you had talked about a while back. Tab bars can now be animated, there's a layout prop. Is there anything there that's really interesting to you?

Satyajit Sahoo:

Well, I mean the biggest things are of course the static API, automatic deep linking and types, but I think there are a lot of small new features. I think one of the biggest ones would be preloading screens. So in new version of React navigation, you can preload a screen before navigating to it. So let's say you have a stack and you might have a heavy screen or maybe you have some data fetching or something you need to do and it takes some time and you'll be going to that screen. So with navigation seven you can say navigation preload the screen and it'll render in the background. So it'll learn all of the effects of data fetching or what you have. And then when you navigate to it, it's going to just bring back that screen to the front so that way it should be fast, should be more responsive.

Satyajit Sahoo:

I think it's similar to how N Ps the screens on say hovering the link or they have some strategy to do it automatically. We don't have any automatic way to do it yet. But you could build on top of that. You could do it automatically yourself, but now you have this ability to do it. It's not supported in Native Stack right now, but we're talking to the native screens developers, we're talking how to implement that. So hopefully it'll also be Native Stack soon. Not sure if it'll be there at the release. Eventually it should be there. So we'll see. And of course there are other changes like the design of all of the UI elements. We are moving them to new metal design because when we wrote track navigation, five or seven, sorry, five or six, it had Metal design two, I think they have so many versions I am lost, but I think right now it's three SO or Metal U and they call it. So we are redesigning the components to match the new metal design. That means React Native screens is also going to have some cool features. I don't know if I'm allowed to say it

Jamon Holmgren:

Breaking news,

Satyajit Sahoo:

But React Native Screens is also adding a large title on Android. You have large title on iOS. So we'll also have it on Android, which will be pretty cool because I think a lot of people want that on Android. And there is also bottom sheet which React native screens is working. We already have models, but bottom sheet will be multiple levels, not only at the top, but you have break points and it'll be like a bottom sheet, but it's not Java Street based, it's native. So that's something also the reactive screens developers are working on. So I'm excited for that. But yeah, you can go to our documentation and look at all of the features. I think there are still some updates that are needed, but most of them should be up to date. And other than that, there is another thing I'm really excited about or probably most people are not, but I'm excited about it.

Satyajit Sahoo:

And it's not new feature, it's mostly about our documentation because we have improved our documentation a lot on how we structure things. And now we have the ability to embed playgrounds very easily. Right now there are no playgrounds. We have a code snippet, we generate a snack link, you click it and you go to snack. But we have the ability to embed a snack. We have the ability to do a lot more. And as part of that, what we also did, we added snack examples for a lot of more code snippets because previously how it worked for every code snippet that we had in the documentation, there will be another file that we would create. That file would have the full implementation of the code. So we have this code snippet in the documentation, separate code snippet in the file. So that would be used for snack.

Satyajit Sahoo:

And then since there are two different files, you have to remember if you edit this, you have to edit that. So yeah, not very maintainable and messy. And again, it's also not very easy work with say I'm writing the documentation, I'm in the document, I don't want to go to a separate files, write a different example. That takes me out of the flow of writing the documentation. So what we have done in the new documentation is set up in such a way that you can write it directly in the markdown, we'll extract that, we'll make a snack automatically. So yeah, that's excited about, I think that means we should have more examples that people can play with. We should have more interactive stuff and more dynamic stuff in the future.

Jamon Holmgren:

This is all super awesome. Satya, thank you so much for coming on the podcast as well as all of the amazing work that you're doing. I know that we appreciate it here at Infinite Red. When I asked internally about version seven, there's some people that are very excited about it that think it's a really good direction. You probably don't hear this feedback, so I want to let you know that. And of course, thank you from all of us. We do use it every day at Infinite Red, and I know many of our listeners use React Navigation and you and the rest of the team there at React Navigation are doing fantastic work. So where can people follow you online to follow your progress with version seven and anything in the future?

Satyajit Sahoo:

Thank you. Yeah, you can follow me on Twitter because I'm always there. Or you can follow me on GitHub I guess. But yeah, you can follow me as Satya 1 6 4 S-A-T-Y-A 1 6 4. That's my handle everywhere. GitHub, Twitter, so you can just follow me there.

Jamon Holmgren:

Perfect. Yeah, and I do recommend it. He posts some really cool sneak peeks of stuff and you, you'll get some really nice technical content. It's the best. Thank you so much. That's it for this episode. Of course, everybody, please do click that subscribe button, let us know on Twitter, of course you can follow React Native Radio, react native RDIO. I'm Jamon Holmgren. We'll see you all next time.

Jed Bartausky:

As always, thanks to our editor, Todd Werth, our assistant editor, Jed Bartausky, our marketing and episode release coordinator, Justin Huskey and our guest coordinator, Mazen Chami. Our producers and hosts are Jamon Holmgren, Robin Hines and Mazen Chami. Thanks to our sponsor, infinite Red. Check us out at infinite.red/radio. A special thanks to all of you listening today. Make sure to subscribe to React Native Radio on all the major podcasting platforms.