In this episode, we talk with Evan Bacon from Expo! Evan joins Robin, Mazen, and Jamon to discuss the newly released Expo Router, the first file-based router for mobile apps. Learn how you can build, maintain, and scale projects using Expo Router.
In this episode, we talk with Evan Bacon from Expo! Evan joins Robin, Mazen, and Jamon to discuss the newly released Expo Router, the first file-based router for mobile apps. Learn how you can build, maintain, and scale projects using Expo Router.
This episode brought to you by Infinite Red! Infinite Red is a premier React Native design and development agency located in the USA. With five years of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter), Infinite Red is the best choice for your next React Native app.
Helpful Links:
Connect With Us!
Todd Werth:
Welcome back to React Native Radio Podcast. Brought to you by trees who remind you that they can see what you're doing when no one else is looking. Episode 256, Expo Router with Evan Bacon.
Jamon Holmgren:
Is everyone here? Robin, are you here?
Robin Heinze:
I think so.
Jamon Holmgren:
Mazen, are you here?
Mazen Chami:
Where are we?
Jamon Holmgren:
You know what? I hear your voice and that's a good thing. Everybody's been sick, so I just had to verify for sure that we actually had us three hosts in person here on the podcast because it's just not been the case.
Robin Heinze:
It's a miracle. It really is.
Jamon Holmgren:
Are you sure that one of you isn't showing up sick or has someone sick?
Robin Heinze:
I am actually sick, but I'm here.
Mazen Chami:
Same. I'm sick also, but podcast over everything.
Robin Heinze:
Yeah.
Jamon Holmgren:
I'm not sick, but I feel like I should be just out of solidarity just so we could all power through together.
Robin Heinze:
Everyone's sick. Literally everyone except Jamon.
Jamon Holmgren:
Tis the season. It's actually been pretty rough here. I know in the Pacific Northwest hospitals are jammed. It's a little rough.
Robin Heinze:
It has been rough, but we power through. The podcast must go on.
Jamon Holmgren:
We are professionals here. It must. Yeah. I mean, people demanded. I actually had a DM this morning. "Where have the episodes been? I've been waiting." Not to put any pressure on the editors-
Robin Heinze:
No, not at all.
Jamon Holmgren:
To get some stuff out, but no, we've just been sick so it's taken time. Even our editor was sick. I don't know. One right after another. But we are here today. I'm Jamon Holmgren, your host. Friendly CTO of Infinite Red. I live in the beautiful Pacific Northwest with my wife and four kids. I play hockey. I drive my tractor whenever I get an excuse to, it's currently just sitting sort of parked at this moment, but that's okay. And I'm joined today by my healthy-ish co-hosts, Robin and Mazen. We also have an awesome guest who I'm hoping is also healthy, who I will introduce in just a bit. Robin Heinze is a senior software engineer at Infinite Red. She's located west of Portland, Oregon with her husband and two kids and has specialized in React Native for at least the past five years. It says past five years here, but I think that it continues.
Robin Heinze:
I'd say it's five and a half now.
Jamon Holmgren:
Is it five and a ... okay. Yeah.
Robin Heinze:
Got to have the half. It's really important.
Jamon Holmgren:
Yeah, exactly. Like, how old are you? I'm five and a half.
Robin Heinze:
I'm 32 and a half.
Jamon Holmgren:
Wow, you're young. I just turned 41 actually. Also joined by Mazen Chami. Mazen lives in Durham, North Carolina with his wife and baby boy. He's a former pro soccer player and coach and is a Senior React Native engineer also here at Infinite Red. Mazen, how are you feeling? You doing better? I mean, you had a rough month.
Mazen Chami:
Yeah, seen better days, but we're here and luckily seems like the entire family's turning a corner, so yeah.
Jamon Holmgren:
That's great. Yeah. I'm glad to hear that. Our guest today, I'm really excited to talk to him once again. We have chatted many, many times over the years. I don't know if you've ever been on our podcast though, Evan.
Robin Heinze:
We were just talking about that. I don't think he has. This is his debut episode.
Jamon Holmgren:
Yeah, that's awesome. So Evan Bacon, manager of Expo developer tools, author of Expo Prebuild and Config Plugins, Expo CLI, works on Expo Router, which we're going to be talking about in the next generation of over the air updates. First off, Evan, I got to ask, what's it like having a name that sounds like a celebrity's name?
Evan Bacon:
Yeah, it's excellent.
Robin Heinze:
Do you get called Kevin a lot?
Evan Bacon:
I don't get called Kevin. I do get that comparison a lot. I got it at the border the other day when I was trying to come back into the country.
Jamon Holmgren:
You're like, oh no, no. Nobody's ever told me that before.
Evan Bacon:
Yeah.
Jamon Holmgren:
It's just like how Spanish people like to say. "Do you know what your name means in Spanish? It means ham in Spanish." I'm like, "oh really? I'd never heard that."
Evan Bacon:
Yeah, Avo points that out every time I'm like, "I'm about to talk with Jamon." And she's like, "ah, ham and bacon."
Robin Heinze:
Ham and bacon.
Jamon Holmgren:
I know, right?
Robin Heinze:
That's epic.
Jamon Holmgren:
Well, we can commiserate both similar situations, but really happy to have you on Evan and I'm excited about our topic because I don't know, I feel like if there's one topic that will get me going more than state management, it's navigation, so this is a good topic for me.
Mazen Chami:
That's a fact.
Evan Bacon:
Yeah. State management, high bar. Yeah, thanks so much for having me on. I appreciate it.
Jamon Holmgren:
Awesome. Before we get started, this episode is sponsored by Chain React 2023. Chain React is returning in person this year. You should go buy tickets actually. They're actually open right now. The CFP also opened, so if you're listening to this within the window of time, go to chainreactconf.com and submit a talk and definitely buy some tickets. By the way, if you buy tickets and then your talk is accepted, we refund your ticket 'cause we pay for your admission. So totally cool to do both at the same time. We have a Slack channel where we see ticket sales coming in. I've seen a lot of really-
Robin Heinze:
I love that Slack channel.
Jamon Holmgren:
Familiar names.
Robin Heinze:
It's so fun.
Jamon Holmgren:
Yeah.
Robin Heinze:
So if you sign up, we will see your name in Slack and we will have a little party in your honor.
Jamon Holmgren:
Yeah, there's like emojis that get added to everybody who buys a ticket and we're like, whoa, hey, we know that person. So that's fun. All right, let's get into our topic for today. It is Expo Router and like I said, I'm really excited about this. There's a blog article out on Expo's blog. Evan, you actually wrote this back in September?
Evan Bacon:
Correct. Yeah, the RFC.
Jamon Holmgren:
Yeah, it's the RFC. So RFC File System-Based Native Routing with Expo and React Native. You wrote up a tweet around that I guess at the same time. You said, "Today, Expo's re-imagining native routing! Automatically create (dynamic) routes with files, zero boilerplate, automatic deep linking, nested layouts, built on React Navigation for easy adoption." And then you talked about there's a beta out and you have this really cool GIF kind of showing how it all works. So that's what we're going to be diving into. Can you give a really quick TLDR on what Expo Router is and how it works?
Evan Bacon:
I could, yeah. It's very similar to what you just said as those were-
Robin Heinze:
Jamon already did it.
Evan Bacon:
Those were my resources, yeah.
Jamon Holmgren:
I want you to restate it in your own voice.
Evan Bacon:
All right. Yeah, it's the first ever kind of file system-based router for native apps. File system-based routers are super common on web. They basically define how the web works. And navigation on native is really, really difficult, really tedious. There's a lot of opinions in my opinion that are missing. And Expo Router kind of brings those into the native development world. I guess those are things that I could say which are different from what you already said.
Jamon Holmgren:
So it's based on React Navigation. What would be familiar if you were coming from React Navigation and what would be the biggest thing to get used to?
Evan Bacon:
Yeah, so React Navigation is at least originally developed at Expo. So Expo Router is built on top of React Navigation and the decision there was a little bit tricky. We looked at a lot of different routing solutions. We actually looked at a lot of web first routing solutions because I didn't really want to ... had to re-implement all of the web routing. And then I quickly realized that actually the native navigation part, the view system is substantially harder than implementing a router from scratch. React Navigation just implements so many of these incredible things, the gestures, the feel of it, all the interactions that you would expect, and then Export Router kind of implements a more robust router on top of that for handling URLs.
So what should feel familiar is that it uses Stag Navigator and Tab Navigator. It's all the same options, screen options, navigation options. Basically at any point where something is missing from Expo Router or something just doesn't make sense to add Expo Router, you can drop down into React Navigation.
Robin Heinze:
That's nice.
Evan Bacon:
So by default maybe you move around with links, like link components and Ahrefs, but if that doesn't make sense to you or you don't like that, you can just grab the navigation object and do navigation dot push.
Robin Heinze:
It's basically some really nice syntactic sugar on top of ... it's more complex than syntactic sugar, but you're using React Navigation, but it's this layer on top that lets you navigate the way a web router would navigate.
Evan Bacon:
Correct, yeah. Some things which won't feel familiar are like Expo Router has certain opinions which can prevent you from doing things. So for example, the linking configuration, basically the entire ability to handle incoming URLs is completely automatic. And so with React Navigation, it is not automatic. It's kind of like loosely representative of your view system and your component tree. So there's a lot of room for error and you can't do that. So there's things like that which are not available. Certain mistakes can't be made, but depending on how you look at it, could be a feature, not a bug.
Robin Heinze:
As long as the error experience is decent when you screw up.
Evan Bacon:
Yeah, it's actually really nice about Expo Router. The whole feature is basically a bundler feature built on top of Metro. And because a normal React Native app just kind of has this single entry point, any error has to basically propagate up to that and there's really no use in that. So it just doesn't really try to propagate to the entry point. Whereas with Expo Router, every error comes from a particular route. It comes from a file, you can determine where it was thrown. So you can effectively divide up as your app scales, the error management stays the same, the ability to find the context of an error remains the same.
Robin Heinze:
See, that's good. I do error based development instead of test development.
Evan Bacon:
That's excellent.
Robin Heinze:
Yeah.
Evan Bacon:
Definitely.
Robin Heinze:
I don't read the docs. I just try stuff and I wait till it airs and then I fix it.
Evan Bacon:
Errors are an extremely important part of any development framework and if they're not right, then ... it's like the typing, right? If the typing is wrong, then the typing is wrong. You just lose out on that entire set of features.
Mazen Chami:
You mentioned this is being built on top of React Navigation and I know it's still in beta and all that. So bearing that in mind, what would it look like for people who want to either move away from React Navigation or adopt this package now and just kind of start using it in their apps? Because being that you mentioned the typing and built on top of React Navigation, everything seems like it's the same when it comes to props and all that. So can you just go into that a little bit?
Evan Bacon:
So in terms of the API, since it's still actively in beta, encourages you to use a lot of React Navigation. From that direction, it's quite easy to migrate because you can reuse a lot of things. Then in terms of the maturity, there's just not a lot of patterns established for more complex cases, which is effectively what defines it being in beta. And so that part makes it a bit tricky. You have to be a bit more creative about your solutions. But in general, I think when it becomes more robust, we are going to see just a lot more advanced patterns, which are far more URL driven, far more intrinsic of rehydration, and then I think it could potentially get as extreme as feeling like moving from maybe J. Corey to React. You basically just want to start from scratch because it's going to be better.
Robin Heinze:
Yeah.
Mazen Chami:
Yeah.
Robin Heinze:
It's worth the effort to make a big change.
Evan Bacon:
Right.
Jamon Holmgren:
I think the key piece that you mentioned there is being URL based, URL driven, because that was actually a pretty big ... if you were coming from web, not having a URL is a pretty big deal. Like, where am I in my application? Well, that's a hard thing. You know what screen is being shown, but what's behind it?
Robin Heinze:
It's really hard to answer that. You know where you're going back to, you know where you can go forward to, but-
Jamon Holmgren:
And then the state of your application is just so different. I think there's probably web developers listening to us who-
Robin Heinze:
It's like the blockchain.
Jamon Holmgren:
A little bit. Yeah.
Robin Heinze:
I know where I came from and I know where I'm going.
Jamon Holmgren:
Right. But the idea of being URL based has not been a thing. And I remember even just when we did native iOS and Android development, that was not really a thing either and you kind of had to almost patch over the top of it, some sort of a URL feel just to get deep linking and things like that. But it seems like that's such a key concept of what you're trying to achieve here.
Evan Bacon:
Yeah, I mean the URL part is effectively what a lot of potentially naysayers have said is just impossible to get right on native. And to some extent they're not wrong. If you were to compare a file system-based router on native to one on web, the native one just has to be everything web is plus a lot more because there's a lot of patterns which web can get away with not having that native simply can't like, shared and parallel routes that can be accessed at the same time for multiple tabs. On web you could ... like the Twitter website, which is, it sets the standard in many ways for how a mobile website should work. Like when you change-
Jamon Holmgren:
Ironically React Native web. Right?
Evan Bacon:
Yeah, yeah definitely. I mean I think there's a lot to that. But I think if you were to navigate downside of a tab and then you change tabs and you change back, it will just reset the ... it won't save that state. And these are things which are very critical that the web can get away with, but on native you just cannot get away with it, you need to preserve those. So you need to work those into the file system and I'm confident that it's completely possible and that you can achieve all these using a file system.
Jamon Holmgren:
That's pretty cool. Yeah.
Evan Bacon:
I think another thing there, which is actually interesting is that potentially it will be harder for web developers to migrate to Expo Router than it will be for React Navigation developers to migrate to Expo Router. 'Cause on web you have some expecta... you could just build it as is, as you would expect maybe if you're building a Remix or an Next JS website, but then you're going to realize it just doesn't feel very native and then you're going to have to dig in and figure out what are you doing wrong? Whereas a lot of native developers are going to be like, okay, I need multiple copies of this screen throughout my stack and they'll be looking for these things. So I think in that regard, there's a lot of room for improvement and just increasing the ability for people to understand these patterns. Right now, it's actually hard to even describe these patterns, let alone understand them.
Mazen Chami:
I feel like a lot of web React developers that I talk to don't necessarily find it easy at first to understand native navigation and even just React Navigation in general and just going to have to explain the whole stacking and all that kind of stuff that that's how it works. And they're like, okay, cool. Now where's my route? What ID, what are my params that are coming in? It's like, hold on, okay, we need to take a step back and all that. So there is a high bar of coming in I think to React Native and navigation is usually one of those for web developers. So kind of what you're saying, it's like, this is just another level on top of that to tackle eventually.
Evan Bacon:
And I think fundamentally it's so important that we get URLs in native. If you look at the statistics for how people use the internet in general, in the last 10 years it's gone from almost no one on mobile to over half is on mobile and almost completely on desktop to substantially less than half on desktop. And then if you look at how people consume ... how they spend time on their phone, the majority of it is in native apps. 90% of the time is in native apps.
Jamon Holmgren:
I think a lot of people would be surprised about that, about the fact that so many people spend so much time in native apps because there's this sort of narrative among certainly web developers that nobody wants to install a native app. And apparently they have not been a parent with a 14-year-old daughter who gets a notification every five seconds, Hey, I want to install this new app because ... I don't know how many apps she has.
Evan Bacon:
I mean, they're not wrong. People don't want to install apps, but they do want the experience that they are getting despite that.
Robin Heinze:
Companies they make ... a lot of times I experience this on things like Instagram and other social media where I'll use it on the web for reasons, so I like to use it on web 'cause there's less ads, but there's so many fewer features that they want you to use the native apps.
Jamon Holmgren:
Isn't the experience worse though? I have never had a good experience on the web-
Robin Heinze:
Oh, it is.
Jamon Holmgren:
Version of those things.
Robin Heinze:
That's a feature for me because it keeps me from being addicted to Instagram, but that's another conversation.
Jamon Holmgren:
Oh, I see. Okay.
Evan Bacon:
Ads is actually one of those features, you get more for native ads than you do for web ads because there's no ad block and you can reliably predict that people see it.
Robin Heinze:
Yeah, yeah. They just have a lot more control. So the companies are pushing you towards installing the native app in addition.
Evan Bacon:
Yeah. So there's just a lot more internet consumption happening this way and the way that developers are building things is not in line with the way that consumers are increasingly consuming things. And in web browsers we have so many incredible features which we just don't get on native. And if you look at the top of how native apps are built, they actually do implement a lot of the really good features, but then the majority of native apps do not. So URLs and deep linking, if I were to give you a URL to Instagram, you can open that and it'll take you right into the content you want to go on Instagram, they effectively have URL support and you can search for content inside of Twitter on Google. You can look up things, you find the tweets and you click on that, it'll take you into the native app.
These are important paradigms that on web you get by default and on native only the biggest companies in the world get them and even then it's very fragile. And they only implement it for a subset of the application like tweets or video. It's not for every page
Jamon Holmgren:
Yeah. Like, try to link to some internal setting screen or something. It just not going to happen.
Evan Bacon:
Right. I think this is really fundamental to how we use the internet and they just have to be there on native, so we-
Jamon Holmgren:
Have you ever tried to explain to someone who's nontechnical like your mom or your dad or something like that where you're like, Hey, you need to go into your Facebook settings and turn off this thing just for privacy or something?
Robin Heinze:
And you wish you could just send them a link to the right spot.
Jamon Holmgren:
Send them a link, right. You can't do it.
Robin Heinze:
But you have to be like, go to settings and then you have to look for this and then you have to look for this and-
Jamon Holmgren:
Oh wait, no, you're on Android, so it's different.
Evan Bacon:
Right. Yeah, or if they move the wire around.
Robin Heinze:
Totally.
Jamon Holmgren:
Oh, they do it constantly. Yeah.
Evan Bacon:
Yeah. URLs are kind of expected to be evergreen and you have redirects, so it's just a really important pattern. And the web really benefited from the fact that the only way you could build websites was by doing this, whereas on native, I mean things are effectively kind of like a canvas. There's no way to introspect the content of the pages, there's no way to link into the content of the pages. This is actually why I think a lot of these canvas based kind of cross-platform things do so well is because the important things are not there so it doesn't matter how you draw stuff to the screen.
Robin Heinze:
Everything's made up.
Evan Bacon:
Right. Exactly. But it shouldn't be, there's definitely rules around how people want to uniformly consume content, and so that is the overarching goal of Expo Router. Convenience is a huge side effect of this. It is not even close to the main goal, but if you don't build an app with URL in the DNA, then it just doesn't work or it's very fragile. You can't test deep links on native. I mean you can try, you can deep link and then if a screen doesn't appear and send some signal, then maybe you time out. It's a miserable experience. So every other way of building deep links on native is really just not even close. You can't rely on it to always work, whereas with Expo Router, you know the URLs work, there's no other way to do it. You have to figure out how to make what you want work around this mechanism.
Robin Heinze:
Yeah.
Jamon Holmgren:
Yeah. I like that, you build the rest of it around that and then it becomes ... yeah, because like we talked about, it's a layer on top. Universal links are usually just this layer on top, so you're not going to implement it for everything because it just doesn't make sense, doesn't make sense to implement deep links for every single thing.
Robin Heinze:
I mean, there's apps where it doesn't matter, but...
Jamon Holmgren:
Yeah.
Evan Bacon:
It does make sense, but it is not worth the effort. It's not worth the maintenance.
Jamon Holmgren:
Right, right, right. That's what I mean. Yeah.
Evan Bacon:
But if you got it for free, you certainly wouldn't turn it off.
Robin Heinze:
It could be a completely different world of apps if you got that for free, instead of having it be a whole big process and project to do deep links.
Evan Bacon:
Just once you set it up, there's all this maintenance that you kind of undertake. You don't want to change the structure of your app because you had to go through this whole process again. And so it effectively kind of handicaps you and yeah, that's just not the way that people should be building things.
Mazen Chami:
Totally. Yeah, I agree. I think mobile apps in general have ingrained in our heads that if you want to get to point X in the app, you have to start by opening the app and going through X, Y, Z to get there. Right?
Evan Bacon:
Correct. Yeah.
Mazen Chami:
But there are moments when sometimes I'll be on web or something and I'll say, oh, hey, you have the mobile app installed, click here. And I click it and it gets me to that point just with that one click deep linking or in the future, what we're talking about now with with URL based routing and all of a sudden I'm there with the pre-populated screen that instead of 20 clicks, took me just about one click to get to. That'll start changing the narrative and our mindset so that now we don't have to essentially think about opening our app from the beginning to get to say the product screen or the specific product screen when instead-
Robin Heinze:
We don't have to always leave this little trail of breadcrumbs.
Mazen Chami:
Exactly. Yeah, that's a better way of saying it. Were native apps train us to follow breadcrumbs to get to our point.
Evan Bacon:
As an indie developer, that just doesn't work. If you don't have URLs, no one's sharing your content. How are you going to be discovered? How are you going to be found? You don't maybe have this app icon that's comp... if the way that people use your app is that the app icon is compelling, it's like you have no chance. You have to be able to locate the content. You have to have people sharing the content inside of the app, which is actually where Expo Router pairs up really nicely with Expo Web. A lot of progress on Expo web kind of paused for a long time because the next natural step was to add files to based routing, bundle splitting, SSG, things like this. But if we only added them for web, then it diverges, and you might as well just use a web only framework.
So we had to add this for native in order to improve Expo web. But once you have that, then all these routes are effectively copies of what you see on Native. Very similar to just think Facebook or Instagram or Twitter and how these work. And then you can search for these any way that you can search content, you are now searching through the content of the application in real time live, which means that your app is now effectively it has SEO, click on it and then it takes you into the app. And if you click on it, you can download the app directly from the page if it's linked up to the website, meaning you never actually have to go to the app store and the app store is very incentivized to make your app hard to find so that you pay them to advertise.
And that's just not how things should be discovered. Discovery is a free concept on the internet. I mean we're pretty entitled to that, but it's totally, you just put content out there and you find it. And that's another really important thing that we're just missing in this kind of shift to this native ecosystem where we need things to be discoverable, linkable, and then also instantly accessible. Having to download an application is just not great. We want this kind of symbiotic application experience with Expo where the website and the native app work together. The website is effectively a feature of the native app and not this kind of competitor for the user's time. And so they need to be connected very closely. And when you open a link, if you don't have the app, it should take you to a website which closely resembles the app, and then you should be able to maybe download it. But even that's kind of slow. And so this is where things like App Clips come in, which is technology that no one implements 'cause it's so hard to utilize.
Robin Heinze:
I don't think I've ever seen an App Clip in the wild.
Evan Bacon:
If you go to the Apple Docs for App Clips, it says you need to have URLs which line up with your native app and your App Clip and your website all together, which is just impossible to do unless you built your app around URLs like Expo Router. And the reason for this is because if you open an App Clip and you already have the app installed, then Apple will just direct you into the native app and not the App Clip. So it has to effectively match everything that your native app would have done.
Robin Heinze:
Interesting.
Evan Bacon:
So we can get to a world where you can discover content and then if maybe you're on a website, just maybe you defensively code like, if AR is available, show this screen, and if it's not, then show this fallback. Then the user can open the App Clip instantly and then have access to effectively, it's like a browser patch at that point. It's more functionality to run your React code because that's really all this is, this is a React component which is just being utilized in different native applications, be it the browser, the App Clip or your native app.
Jamon Holmgren:
You had a tweet that Jack the former CEO of Twitter responded to recently about App Clips and about how essentially Expo's amazing ability to do, essentially what you're talking about was Nerfed by Apple because they wanted people to use App Clips, which nobody uses App Clips. That was very interesting, that whole conversation because Jack I think was complaining about how basically he was wanting what you were describing, he was wanting this idea that you could have the ability ... it's not all like a walled garden. You have native apps and websites working seamlessly together. Can you talk a little bit more about that interaction? 'Cause I think it's relevant here.
Evan Bacon:
Yeah, so this is something that we're calling the symbiotic app experience where when you build a cross-platform app, if you're kind of on the forefront and you're really utilizing code, then when you deploy, it really feels like these are competing with each other because they don't communicate. So you lose out on that context. If a user finds your website and then they want to go to the native app maybe to make a purchase or something, maybe they don't just, they probably don't feel comfortable or something like that in the website, they can't do that, they have to start from scratch. They have to go download the app. Even if you download the app and you redirect into it to the home screen, you still have to go find that content again and maybe the search works differently on native versus web. So these things, if they don't exist in a way that assists each other, then it really is you have built two competing products which are equally compelling.
And so I think what Jack was talking about was this idea of basically all these things that I'm describing here where it's like, when people talk about native versus web, there's clearly benefits to both and we need to combine both and we need to turn that into an operating system. I think that's where he was going with it. I'm not quite there yet. But first proving this theory, because all this is currently is a theory, although not really. The theory is basically, you know how Facebook, Twitter, and Instagram work, imagine that, but for everyone, and then imagine how decentralized things start to feel.
Jamon Holmgren:
I want to also cast light on another thing here that I think is important for our audience as React Native developers. We of course really appreciate everything that Meta and the React Native Core team within Meta does for React Native. They do an amazing job and they've been doing a very good job of reaching out to the community and things like that. But I want to say that Expo plays a really great role here because Meta's primary kind of objective is really a Brownfield app. They have some internal ... they have other apps that run React Native fully, which is great, but a lot of what they're trying to serve is more Brownfield. And they're not going to probably be replacing their navigation anytime soon within the main Facebook app. It's just not going to happen or Instagram for that matter.
But Expo's customers like us who are building stuff from the beginning using Expo, using React Native, we're having to solve these problems using React Native and using React Native solutions. So Expo, understanding our use case and having needs kind of aligned with that is I think really important for this community. And more and more as time is going on, I'm seeing Expo as being the future of React Native, not meta necessarily. Now Meta will have obviously a lot of sway in this.
Robin Heinze:
Meta is React Native.
Jamon Holmgren:
I've been saying this for years by the way, but the moment is arriving now. But I do think that's important because Expo's more aligned with what we're trying to do with most of our clients.
Evan Bacon:
Yeah, that's a great observation. I think it's important to ... Expo doesn't really compete with React Native. In many ways it kind of feels this way because there's issues that React Native maybe partially solves that Expo then potentially also attempts to solve. But as we start to get into more of this Expo Router territory, it starts to feel more like how a framework built on top of React starts to feel.
Jamon Holmgren:
Yeah, absolutely. Yeah.
Robin Heinze:
Yeah.
Evan Bacon:
Yeah. Where React Native is very important. This plays really heavily into what we've been telling React Native, especially the last few months as the most important things for them to solve are styles, especially in the core primitive view, image and text. Because these are the things that we just can't replace at Expo. If we attempted to, it would effectively be a fork of React Native. So I mean, yeah, we definitely want to work together on these things. Expo Router would not have been possible without very close collaboration with the Metro team at Meta, actually. That's in many ways the closest we've ever collaborated with Meta on any project. The largest external contributions to Metro because the entire feature is effectively what if we really push the Bundler really far.
And historically Metro has not been great for users. I'll just acknowledge that right now. A lot of that is because there is ... it's pretty great internally and if you were to try and propose something, that feature probably exists internally and they don't want to have two versions of it because they would potentially conflict, but then it's also very difficult for them to take that internal version and move it out. So you need people who work on the team who are really interested in doing that, taking the internal architecture and working with someone who doesn't work at Meta to help bring that out to the community. And that's actually what we've had with the new maintainer of Metro, Moti Zilberman. And since then they've actually built out a really great team and there's just a ton of stuff going into Metro. Because they have some great architecture in there. Originally because I'm working on Expo Router kind of in the background for many years now.
Originally I tried to build it on webpack because it was much easier to do the kind of configuration we need to do in the Bundler, but it just kind of came down to webpack being too slow. Metro is by no means superfast, but it would be easier to make Metro Fast than it would've been to make webpack fast because architecturally Metro is very quick. In fact, if you guys saw the new Bundler that Vercel put out Turbopack, it's a structurally very similar in the way that it handles caching and in reutilizing kind of cached chunks. So that plus the multi-platform really makes Metro a very fast bundler.
And we're going to keep pushing on this actually a lot more with Expo Router because I've had bundle splitting working for a very long time now, and I use it for my own projects, but it's very difficult to get that in a state that is good for developers to use. But with Expo Router it's like, okay, we'll just split on every boundary. So every route will be split and it'll actually be split in two ways, which is pretty interesting. The first way is in development, so no screen or any of its dependencies will be bundled until that screen has been requested, meaning that bundling is always as fast as it is when you start up. And then there's this kind of secondary bundle splitting where it bundles everything at once into one giant file and then it looks at the route boundaries and then it splits into multiple files based on that, which would effectively give you the ability to have an app with millions of screens, which could be deferred until the user requests them. Or maybe they're just placed offline. But all that requires very, very close collaboration with the Metro team.
Robin Heinze:
I want to talk a little bit about the problems with Expo Router that you brought up in the original RFC blog post. You talked about things like internal state not being easily represented by URLs running offline without a server. I know I noticed Fernando Rojo from-
Mazen Chami:
BeatGigs, yeah.
Robin Heinze:
He had a comment about infinite stack pushes. Can you just expand a little bit on what the biggest challenges are with Expo Router and what problems developers can expect to run into?
Evan Bacon:
Yeah, so I'll split that up. I think the first one is about state rehydration. So that one can be, I think tested by ... if you were to open Twitter and then you were to find a tweet by yourself on your feed or you were to search for a tweet on the search tab and then you go to your profile and then you click on the same tweet. Now if you were on web, that would be the same URL because you don't want to have search slash tweet ID and profile slash tweet ID you want slash tweet ID. And so you can do that with client side state, basically a giant JavaScript object representing what you've done, your history. But if you were to then refresh the page, what should it do? Where should that URL go to, which tab should it ... how do you rehydrate the state?
So the kind of reasonable defaults I was talking about, were effectively some assumptions about how to recreate that. A lot of that's actually based on I think the Twitter website. And then on top of that is exposing some sort of API which enables developers to tap into that opinion and then maybe change what happens when it rehydrates from a certain point. It doesn't have to be kind of a one size fits all. So that is actually something that is not currently supported in Expo Router. I'm working on that. Right now there's a draft PR open. Solved a bunch of problems last night, but there's still a bunch more.
And it feels really great because effectively the way it works is I think Fernando described as Infinite Stack where you want basically every tab to have access to every screen. It can push any URL, so it is effectively a stack, but then the first page of that stack is chosen as one of those screens. And so some of the issues I was solving last night where for instance, if you were deep inside of the search page and then you wanted to link to your profile, should it push your profile or should it do the nearest possible, which would be switching to the profile tab and things around that. And then there's some other considerations there.
And we're actually able to represent a lot of this by utilizing parts of the file system spec, which traditionally just weren't really utilized in other file system-based routers. So for instance, if you want to push a screen while staying in the same stack, you would maybe do something like dot slash whatever, which effectively says I want to do it relative to where I am currently. Whereas if you were to do just the absolute slash, then that would fall back on the resolution pattern, which would then determine effectively if you were to rehydrate the state.
Robin Heinze:
Yeah, this is a really critical problem. I mean, pretty much every app that we build has this exact scenario.
Evan Bacon:
Yeah, so it should feel hopefully good.
Robin Heinze:
We'll give it a try.
Evan Bacon:
But then, yeah, I think what's really important is that we make it so that ... this is the only place where I want it to be actually pretty configurable. Everywhere else, we try to keep it very minimal on adding new conventions because it's much easier to add a convention than it is to remove a convention. There's no linter, there's no type checker for file system paths and names, so got to be kind of right when you do that. But maybe we'll have some static kind of template files.
One thing which is an issue right now is that we export settings from maybe a layout route saying this is which file should be the initial route. So if you were to maybe deep link into a tweet, it knows to have a back button and it knows to be presented on top of the feed, but in doing that, you have to load the initial route to actually get that setting. So that would break assumptions about lazy loading. So it was really important that we kind of planned out every feature we wanted to add to Expo Router ahead of time, and then we divided it into five releases. So five major versions and the first major version will have shared routing, but it will also mostly not break bundle splitting, which is coming in the next two versions. So I think that was the first question. I don't know what was the other one?
Robin Heinze:
Oh no, that's totally fine. There was also some mention of running offline without a server.
Evan Bacon:
This is the part where maybe web developers will cringe a bit. And this is also one of those things where web can just get away with not having to implement this because it has to be online. And then if it doesn't work offline and you get a PWA, then they're just like, ah, don't use PWAs. Whereas on native, offline is a feature that is required. So we have two versions of the resolution algorithm, both written in TypeScript. One runs in runtime space, so client side and the other can be used in node space to make assumptions about the tooling. So the one that runs in runtime space effectively does all the interop of determining which routes should be used where, and then that turns into a giant JavaScript object and then that that's just local, and then it will be bundle split so that it's not always loaded into memory. And this effectively lets you work off ...
I mean, the web is basically based on a file system based router that is never offline, right? You ping a server, it gives you the file match in the URL. In native, in order to replicate that, it is a uncanny valley type replication that is not great for ... you wouldn't want to use this on web, you would want to use a totally different version while still maintaining the same developer facing API.
Robin Heinze:
Yeah, this isn't meant to replace the traditional routing that you use on the web. It's meant to make native routing appear and work as web routing does.
Evan Bacon:
Right. And then there's also ... so what we're going to have to eventually create is some kind of quas... like some half offline, half server type situation where certain routes work offline and certain routes are deferred to the server. And this is going to actually greatly benefit native, especially in App Clips where the bundle size has to be under 15 megabytes, but then it can also be downloaded only when you're online because it's downloaded instantly. So in cases like that, you would effectively want to defer as many routes as possible, even though it's a native app and effectively treat it like a browser where once you load the first page it's fetching that first page and returning it. And we can do that fairly easily with React suspense and having this system which works across native and web. So there's kind of room across the whole spectrum of this implementation to have things work offline, have things work semi offline, have things work totally online.
Jamon Holmgren:
Yeah, it's really a melding of two worlds. I love this collision though between native and web and seeing how you're solving these problems, but also what kind of experiences we can build with that. That's always been one of the strengths of React Native is that collision of communities.
Robin Heinze:
And I love that the motivation for this package is not purely technical. You have this vision of what the web and native app experience for a user should be like, and from a business perspective, as a business, how am I getting my product in front of users and that is it like that critical problem and how can this technology make that problem better? I love that that's baked in to your motivation for doing this, and it's not purely just like, well, let's see if we can do this cool technical problem. No, this is trying to transform the technical-
Jamon Holmgren:
Or just trying to maybe optimize what the paradigms that are already there. I've seen some navigation libraries that are more that way where they're ... I don't know, React Native Navigation is an example of this where just trying to optimize existing patterns where this seems to be approaching it from a much higher level.
Robin Heinze:
Yeah. You said you'd been working on this for a couple years, just chewing on it in the background.
Evan Bacon:
Well, yeah, I've been thinking about it for a couple years. Yeah. We do have this master plan of how we want app development to work. I've been kind of alluding to it.
Robin Heinze:
Do you want to offer any spoilers?
Evan Bacon:
Well, I mean, yeah, just basically everything I was describing where apps should be discoverable, instantly accessible and URL based. URLs just need to exist in native apps. You need to be able to search for the content. I mean, imagine shifting to a world where you have the internet, but there's no Google that's kind of what the world is in many ways shifting to, where many people are embracing native apps and native apps don't have this. And it's actually becoming a bit of a ... it's like, the groups that can afford to do this are really flourishing. All the biggest apps have URLs and searchability, and so they are really-
Robin Heinze:
But it takes an entire team of people to make it possible.
Evan Bacon:
Yeah. Whereas on the web, everyone has these really critical features by default. So it's a much more level playing field for content discovery and for accessibility.
Robin Heinze:
Absolutely.
Evan Bacon:
Yeah, we need to prevent that from happening to the internet and that's kind of what a lot of this builds towards. So there's a lot of elements to it, and Expo Router has been not easy to build at all, but it is an important part of this and so is many of the things that we work on, like the Metro integrations, the version CLI, all the way down to EAS build, we really want to solve a lot of that maybe composable runtime issue so that you can focus on the React part of React Native. And that's what a lot of the Expo Router stuff is enabling.
Mazen Chami:
Focusing on the React side of your app. I think that's important. A lot of apps really want you to do more than just that. When that's why we pull in some of these packages to help us to get to that endpoint.
Robin Heinze:
You alluded to how difficult it's been to build Expo Router, and then that ... I'm guessing here a little bit, but I'm wondering if that ties in a little bit to the last problem that you mentioned in the article, which is that native apps are built with compiled languages, and so you have to parse ... parsing the file structure in order to get the navigation is difficult to do quickly and responsibly. Can you talk a little bit more about that issue and how you technically solved it?
Evan Bacon:
Yeah, so I curtailed that one a bit in the article because it was getting a little ranty, as you can imagine.
Robin Heinze:
I'd noted. I sent that and I was like, there is more of a story behind that.
Evan Bacon:
Yeah. Yeah. Brent Navo helped me kind keep that one ... stay on track.
Jamon Holmgren:
Yeah, I would've loved to see an early version.
Evan Bacon:
It's really long. I mean effectively if you ... this is really important and if you look at even what I was saying earlier about the Apple Docs where it says you need to do and then effectively describes Expo Router, it's like you can't do that and you need a file system effectively in order to do this really well. I mean there's probably other ways to do it, I'll try not to be too cringe, but there's probably other ways to do this. But in Xcode, there really isn't a proper file system. There's like a file system representation. I've built an Xcode parser, so I'm aware of like, you can have files that show up in one location, but actually live in a totally different one.
Robin Heinze:
Right, And then you just said, set some config that says this file lives here, and then magically it's like, oh, we know where it is now.
Evan Bacon:
Yeah, exactly. So it would be hard to build it there. And then also you just need really good build tooling. Like I said, a lot of this is built on Metro that is our build tool chain, and I've really worked on reducing Expo CLI to the point where you are almost directly interacting with Metro when you do Expo start or Expo Export. And that communication is you add plugins and you modified the bundler and the bundler and the dev server handle how you assemble your application. And it was not always like this. I think if web developers are listening to this, they're probably like, yeah, obviously that's how it works. It was not like this for a very long time. And if you step out of Expo development and you look at other native development things are, they're compiled.
Swift, for instance, you don't import files, you maybe import targets. So it's hard to create assumptions about what code should be split up and loaded in different ways when you don't import things directly. And yeah, there's just a lot of things that everything has been building up to this and every part of the tool chain is very important for this to work. And if you were to take any part of it away, the dev server, the bundler, the features we added, the required context, then the stuff starts not ... all the way down to ESM imports. If you start to take those away, you lose lazy loading immediately. Everything just is bundled together and shipped all at once.
Robin Heinze:
Thank you for thinking about all this so that the rest of us don't have to.
Jamon Holmgren:
Absolutely.
Evan Bacon:
I do enjoy solving issues that can be solved in such a way where people don't ever have to think about it again because then it's like, haha, hopefully no one knows about this.
Robin Heinze:
I really apologize in advance for how all of this years' worth of work is going to then boil down to a bunch of people filing really angry issues on GitHub about little things that don't work.
Jamon Holmgren:
Such edge cases and just not understanding just how incredibly magical it is that-
Robin Heinze:
Not reading the docs-
Jamon Holmgren:
That it works at all.
Robin Heinze:
Right? That they just don't understand the magnitude of how amazing it is that this exists at all. So hopefully we can do our part to show people how much work went into this. Yeah.
Jamon Holmgren:
Educate people.
Evan Bacon:
Yeah. We also with Expo Router, this is something which is less important, but quite nice about Web is that things just kind of aggressively work. Even if you make a mistake, it still renders even partially, it will give you errors, it will tell you why it's not working. But React Navigation's a good analogy for this. You have to set up your screen, import the screen, link it to a navigator, then maybe set up the linking, and then you have to physically navigate to that screen in order to ensure that it worked. And if it doesn't, then there's a lot of dependencies that you have to look at to figure out what went wrong. So Expo Router tries to bring things a bit closer to how the web feels, where it's like maybe you had a typo in the file name and it's like you can still reach that route. It still works. And you're like, oh, there's a typo in the file. That's not what I wanted it to say.
And we want to keep ... I don't know if you guys have tried Expo Router, but if you have no files in the app directory, so there's no routes, but you are pointing to the app directory, then it will just have this kind of template route, which is like, get started, tap this button, touch the button, and then it creates an index like app slash index. So it's really hard to break.
Robin Heinze:
That's important.
Evan Bacon:
Yeah, just keeping people on track. I feel like a good DX leads to a good UX and just like-
Robin Heinze:
That's a quote.
Evan Bacon:
Yeah, I found people don't actually really know what DX stands for. So it's developer experience for anyone listening. Yeah.
Jamon Holmgren:
I do like that quote.
Evan Bacon:
Yes. I think, did you have a third question?
Robin Heinze:
No, I think you covered everything that was in that. That was really great.
Mazen Chami:
So this next part, we pulled a couple people internally at Infinite Red, and we have a couple questions here from some people at Infinite Red. Frank Calise asked, does this support the new architecture or does it depend on React Navigation supporting it?
Evan Bacon:
Yeah, that's a great question. So like I was saying, Expo Router tries to keep you focused really on the React side. And then everything that we've done with automation around EAS build and pre-build really cover the React Native side. So Expo Router, the fabric is kind of like a detail that you don't really have to worry about too much when you use Expo Router. That's more on the ... if you're a web developer, the browser side. And we already support Fabric JSI and the new architecture as of 47. But yeah, it would require upstream changes to React Navigation. Which is really nice that we are able to get it structured that way because right now React navigation team at Software Mansion is working on native shared element transitions, and once that's out, it will be immediately available in Expo Router and you can start utilizing that as is. So yeah, it's pretty agnostic to the underlying primitives.
Mazen Chami:
Cool. Another question Frank had was related to a project structure. For example, in Ignite we have ... and this kind of goes back to our whole dot slash stuff, so we have dot slash app and then components screens or themes within that, but using Expo Router, it interprets everything under the app directory as part of creating routes and layouts. Are there any ways to ignore specific directories? If we were to implement this and Ignite, would we be looking, moving our components, networking and all the other code into sibling directories of app?
Evan Bacon:
Yeah, this is a really interesting question. We refer to it as co-location, so co-locating components, because you have the structure where there are rules about everything in the structure, so how do you access components? And the most naive approach, which is just import outside of the app directory, obviously that works. And you can set up aliases if you want to do that too. But I think then there's two approaches out ... there's actually three, and I really do not like the third one, I'll just start with the third one. Some people have files which don't have a default export, and then that is not counted as a route, and so that they use that to co-locate. I do not do that because that will break lazy loading because all routes will be interpreted as routes until we load it, at which point we'll see that there's no default export.
Robin Heinze:
So don't do that.
Evan Bacon:
Yeah. The other is what Next 13 is doing where they have a lot of magic file names. So the directories are actually the segments, and then they have page.js, layout.js, loading.js template error, and I think I saw head as well. And so with that approach, you can add any file as long as it's not the magic name and it won't be picked up. But I'm not a huge fan of that approach because then if maybe you have a file which source alphabetically between those, then it gets hard to tell which ones are the magic ones and which ones aren't.
Jamon Holmgren:
You also have the problem where in your editor you have 15 page.js files open and things like that. It's sort of the index problem.
Evan Bacon:
Yeah, yeah, just pushes things around. It's hard to ... and then it squats certain names. So what if I have footer.js And then later next is like footer.js is a magic name. So yeah, that's one potential solution, but also some issues with it. And then I think the other which will potentially be utilized is there will probably just be some standardized folder name, I don't know, maybe the @ sign or something, and then you can just put that anywhere and then it'll ignore everything inside of it. I feel like the other ones will all be kind of considered anti-patterns in bad practice, but it would be nice to collectively decide on a ignored folder name.
Robin Heinze:
Yeah, we should try Jamon, you should definitely add Expo Router to Ignite.
Jamon Holmgren:
Yeah, that would be awesome. Maybe try it during a stream or something. Will it be configurable? Is like app a hard coded thing or can you say, I want app slash routes or something?
Evan Bacon:
It is technically configurable, but I-
Robin Heinze:
Doesn't recommend it.
Evan Bacon:
Well, it's one of those things where maybe in the future, I just haven't given it enough thought to think through all the potential issues, so I don't want to actively encourage it until that has happened.
Jamon Holmgren:
Right. I am looking at ... Ignite has been using the app folder since I think version, I want to say two or something like that, way back in the day. So there are a lot of React Native apps out there that use the app folder for-
Robin Heinze:
Everything.
Jamon Holmgren:
For holding everything.
Evan Bacon:
Yeah. It's unfortunate.
Robin Heinze:
We might just have to change the way we do it.
Jamon Holmgren:
Hey, I don't want to give up without a fight here, Robin. We got to have a little arm wrestling here with Evan first.
Evan Bacon:
It's fun. In the beta docs, I list every convention and it's a bit outdated now, but then the related conventions from similar web frameworks so that people could see the reasoning and that I looked very intensely at every single one of them and how they worked and app was the only thing that most of them had in common where it was like app is on Remix and it's going to be in all the next projects.
Jamon Holmgren:
I mean, that's the why we use it too. Clearly it is a convention. We just have to think about because there are a lot of expectations around what app means, and if you're changing that, there's a communication education aspect there.
Evan Bacon:
Yeah. Expo Router is fundamentally very, very different. And if it isn't currently, it will be and it is a step change improvement, but that comes with a lot of reeducation that needs to take place.
Robin Heinze:
Yeah, I mean it's like you said, at some point it becomes worth it to do the work required to change something this significant because you know it will be better in the end. So that I think may be what people start to discover as adoption increases.
Evan Bacon:
Yeah. And that actually reminds me of a really, this is a very niche. There's a lot of niche features of Expo Router, which is death by a thousand cuts except the opposite of that. And it's actually about error boundaries. So in React Native we have this error overlay and the error overlay taps into console dot error and console dot one, and then it shows regardless. But then React, when it catches an error inside of an error boundary, it will console error. So in React web development, if you have a hook, a hook is supposed to effectively just throw an error and then you're supposed to use a React error boundary to catch that error and turn it into props so that it never goes uncaught. It either is thrown and then the browser or the runtime is like, you didn't catch this or an error boundary catches it.
In React Native because we haven't really structurally cared about this. What we have is a lot of APIs which have hooks, which will return maybe an array where the first value is the resolved value and the second is the error. And then if you don't know about that or you don't handle it, then you have all these uncaught errors, which just leads to invisible problems. So all the way down to how error ... everything will just become more and more React focused and a lot more the way that the React team intended React to be used. And I think it's going to lead to a much better user experience. A lot of little things like that I think are going to make Expo Router feel very different and require a lot of education all the way down to third party libraries having to change how to think about hooks and hook return values.
Robin Heinze:
Yeah. I mean, we're going to be a significant part of that too, as a boilerplate library.
Jamon Holmgren:
Yeah, people look to us for patterns for sure.
Evan Bacon:
We're cut out for you.
Robin Heinze:
You've done a lot of the hard part. We get the easier part of that.
Jamon Holmgren:
I don't know if I would necessarily agree with that, Robin, because there's actually a fairly ... actually, I don't want to go into this one. We'll dive into that later, but there is actually ... I don't know, my mind's chewing right now with some of the things that we would have to do. It'd be quite ... I'm excited about this though.
Mazen Chami:
Okay. And the last question that we have is from Lizzie Limbo. She asked, "why file-based instead of something like config data to map files to routes similar to the rails."
Evan Bacon:
So I mean, the file system has to be there. You have to have it regardless. So already, you don't want to waste the user's input. And then the biggest advantage is that there can be so many static assumptions about ... we don't really do this too much in React Native, but in web they do this a lot. Maybe think about Next JS with get server side props where they look at the code and then they run it in a node environment and then they extract some content other than the React component. We don't do any of that in React Native, but it would be cool to do more of that. So file systems is the kind of easiest way to make these assumptions. If you have to evaluate all the config files, then you can't really make certain ... first one, easiest one is that a user can just look at the code, they don't even have to run it and they can kind of understand how it works.
The second is the runoff. What you can do with Node, just looking at that code without having to execute Metro and bundle a bunch of things. The node, you could do something as simple as evaluating a site map and then taking a simulator and launching all of the URLs and then taking a screenshot and then you just have automatic screenshots. And you can only do that if you have this system that interrupts with node really well and file systems are intrinsic at that. On the other side, you have the config files, which are better for things like types or automatic types, although they're not really automatic. It's effectively you are writing the types and there are routers, which I think are coming up, which are trying that and yeah, we'll see how they go.
Mazen Chami:
Cool. Thanks for those.
Jamon Holmgren:
How do we provide feedback to the RFC? I know that you have the blog article up there, but how do you prefer to get feedback?
Evan Bacon:
Yes, so github.com/expo/router, there's discussions, issues, poor requests. I'm basically looking at all of them right now. There's no structure around it because there's lots of different types of questions and proposals.
Jamon Holmgren:
Perfect.
Evan Bacon:
Even the way that people report errors or issues is very different. In React Navigation, it is a bit unreasonable to ask someone for the entire navigation structure because it's just so hard to set up. But with Expo Router it's like, okay, you can give me the entire navigation because it's just a couple of files and then you can set up a whole app basically in an instant and repro stuff. It's really nice.
Jamon Holmgren:
Awesome. So just to wrap this up, this has been amazing. What is sort of the future hold for Expo Router and when do you envision to be out of beta?
Evan Bacon:
Yeah, so racing towards V1 so that we can race towards V2 and three. Assuming I skip the holidays, we could get it done this year, but I probably won't do that this year.
Robin Heinze:
Don't skip the holidays. Please don't.
Jamon Holmgren:
Yeah. Not worth it.
Evan Bacon:
I don't know, we'll see.
Otherwise it will be done in Q1 of next year. And when I say done, I mean the first version, which is a stable API as far as that first version is concerned. Then when lazy loading comes out, some things might change some assumptions because we won't be loading things equally in order to filter. So yeah, probably Q1 and then the next versions are quick to follow. But then, yeah, it really gets good when other projects start to come out too, that build on top of it. So in an hour we're going to be showing the team a new R&D project that we have, which my team is working on, which builds on top of Expo Router to implement kind of more of like a ... I don't want to spoil the surprise, but it's more of a universal services type system built on Expo Router and so yeah.
Robin Heinze:
Well, we'll have to have you back on to talk about that when it becomes public.
Jamon Holmgren:
Yeah, absolutely. Very cool. Well, thanks so much, Evan. This has been absolutely fantastic. We didn't even talk too deeply about the API and things like that. There's a lot more to learn about this. Go read. We'll link to in the show notes. Go read the documentation, go read the RFC, go give your feedback. I know Evan's always very open if you ask him questions or give feedback, he always listens. He probably has a lot more context than you, but he'll take it into consideration.
If you'd like to nerd out more about React Native, of course you can check out my Twitch stream @rn.live. I'm both on Twitch and YouTube. You can also join our Slack community community.infinite.red. There's over 2000 React Native developers in there. There's also a new Twitter community. If you go to RNTwitter.infinite.red, it's a shortcut to go to the new Twitter community where we talk all about React Native. It's still hopping. People are in there tweeting about React Native and it's just React Native. If you go in there, that's all you're going to see is React Native content. Evan, how do people connect with you online?
Evan Bacon:
Yeah, so I'm @kevinbacon on Twitter and you can find me on GitHub if you... I don't know, type Expo and Bacon, not a lot of other stuff will come up. Yeah.
Jamon Holmgren:
Perfect. Well, yeah, definitely go connect with Evan online. You can find Robin @robin_heinze. You can find Mazen @mazenchami. You can find me @jamonholmgren. Today I was pissing off Swift developers, so that was fun. Not totally intentionally, but they were a little prickly.
Robin Heinze:
I'll grab the popcorn.
Jamon Holmgren:
You can see React Native Radio online also @ReactNativeRdio on Twitter. Thanks so much, Evan. Appreciate you joining us today. Hopefully we can have you on again. As always, thanks to our producer and editor, Todd Werth. Our assistant editor and episode release coordinator, Jed Bartausky. Our designer Justin Huskey and our guest coordinator, Derek Greenberg. Thanks to our sponsor, Chain React, chainreactconf.com Hopefully we can see you all there and talk about Expo Router in person. Special thanks to all of you listening today. Make sure to subscribe. Before we leave, I want to make sure we fit in a very important part of our episode. The most important part we would never forget to do this. This is absolutely critical. Robin, do you have a mom joke?
Robin Heinze:
I do. What award did the inventor of the knock knock joke win?
Jamon Holmgren:
I don't know.
Robin Heinze:
A No Bell prize?
Jamon Holmgren:
No Bell.
Robin Heinze:
No Bell
Jamon Holmgren:
Prize
Robin Heinze:
Because he knocked.
Jamon Holmgren:
Okay.
Mazen Chami:
That's a good one. I like that.
Jamon Holmgren:
Yeah. It's a joke.
Robin Heinze:
Jamon for the record said, "good one, Leon." When Leon posted that in Slack, so he thought it was a good one at the time.
Jamon Holmgren:
It aged like milk.
Robin Heinze:
Just not well. Okay.
Jamon Holmgren:
We'll see you all next time.