Fetch Once, Render Everywhere: React Server Components in Expo Router

When React Native was first announced nearly 10 years ago, it had a very simple premise, which was web the good parts. From this basic concept, React Native has grown to become the most impactful way to build client-side applications. If you fast-forward to now, React Native powers hundreds of the most-used apps in the app store trending list every single day. Really no signs of slowing down. So where do we go from here?

I'm Evan Bacon, an engineer and the creator of exporouter. It's the first file-based routing mechanism for building React apps that run on both web and native platforms from the same code base. It feels like magic. By simply creating files in the app directory, exporouter instantly creates robust navigation for both your native app and your website. It uses familiar web APIs like link and href to move between routes, and it's also a nested routing system, enabling you to organize routes into folders to establish shared UI like tab bars, headers, drawers, so on and so forth. And it's also a... It also has day-one support for the new React compiler, thanks to our collaboration with the meta team. This means you no longer need to write use memo or use callback in your apps, leading to a much better experience for both users and developers. We'll be installing compiler by default in the next version of Expo CLI, so you can flip it on and off. It's actually pretty sweet, because you can turn it off without having to restart the dev server. Really slick. There are many aspects to app development, and Expo provides universal solutions to most of them. But all of these solutions are primarily targeted at building client-side applications. And there's only so much that you can do with the client on its own. Things get really interesting when you bring in data fetching and server rendering.

From a data perspective, most native apps operate essentially like single-page websites. Which is old now data. This means slower performance and substantially less networking. Popular native apps such as Lyft and Netflix, Reddit, and many others use some form of server-driven UI in their applications. But it's very complicated to configure, and as a result, it's out of reach for most app developers.

They do this so they can A-B test functionality and render UI with a high degree of variation based on all sorts of criteria, such as user type, location, the currency you use, the temperature in your region, lots of different things. The approaches vary in many small ways, but they do share some common architecture, such as using JSON as a static UI representation. Think of this JSON as HTML, but for custom native runtimes. And we can see a pattern here from the amount of apps that use all these very similar systems. And that is that server-driven UI is an important system for building apps, but it's just not very accessible to indie developers. All these groups have these frameworks. They are not open source.

So it got me to thinking. What if we could make server-driven UI available to everyone? But also the most powerful version of it ever imagined. And that is the goal of ExpoRouter. Now, to do this, we're bringing React server components, the most cutting-edge approach to server rendering to all platforms, iOS, Android Web, and anything else, through ExpoRouter. This is a huge undertaking. This will require refinement in many different libraries across the universal ecosystem. Our official implementation of React server components for universal apps is currently in early development. But it's worth sharing, because the progress is really exciting. And frankly, it's pretty inspiring to see what apps are capable of when they use modern rendering techniques from the web.

Now, there's a lot to RSE, such as server actions, concurrent routing, flights, et cetera. But I figured it would be easier to just show you guys a demo of what's possible. So I've been really interested in AI, as has everyone. But it's historically been very hard to build high-powered AI native apps. And this is because streaming and server rendering are both critical aspects of working with an LLM. But with React server components and ExpoRouter, it's actually really, really easy to work with AI. So here I have a chat GPT-like app which pings OpenAI with a React server action and streams in native text from the server. So think of this as a chat GPT-style app, right? Everything that returns back from the server is server rendered, though. Or at least partially server rendered, because we also have client components.

So we can ask it something like, should native apps be server rendered? And then it will stream back something about how native apps are typically not server rendered, and how that's more of a web thing. Because this is all pretty new.

Now to create the server action, we have another file which defines useServer in a function. And this function will be extracted into the server bundle, so it never gets shipped to the client and turned into an endpoint on the client, which we can version and make platform-specific. And we can render native text here, React native text, inside of a recursive component which iterates the stream.

One really novel aspect of this server approach in these server actions, is that it's bundled multiple different times based on the platform, so that if the iOS device pings it, then it shows the iOS version of the server bundle, and if the Android version shows, Android version. And this is how it knows which text to use, you know, if it's for iOS or Android web.

Now when a client makes a request, an RFC payload is sent back with suspense to keep the stream open. It has the static representation of our root JSX loaded inside of it, a URL to the client code needed for this RFC to load, because we bundle-split the code, and it can be loaded and fetched dynamically, and then the currently rendered text element. As the stream progresses, more content will be rendered, and React will update the tree with the new visuals, so, if it said, you know, once, and then once upon a time, then And finally, the stream will complete and React will close the connection.

And this is just one part of a much larger puzzle, but it's super powerful, because it means we can use any arbitrary JavaScript, so long as the native bindings are already on our target client, so this is kind of like creating custom HTML live by using use client and use server directives everywhere. So you notice there is no native code here. That's just JSON, and it's new line delimited, so it streams in. It's pretty sweet. And this is just the basics. We can scale this concept up to any native UI.

So let's do something a bit more exciting. When React Native was first demoed, they showed a truly native movies app. So I thought it would be fun to pull movies into this prototype somehow. For inspiration, I looked at what the state-of-the-art best AI apps had to offer. In chat GPT-4, when you ask for movies, it renders a bulleted list of markdown after pinging bing. I checked with GPT-4-0, same deal. On Gemini, it does the same, but with some inline images and some live links. So it's basically just sending down markdown, and then the markdown is being formatted with a markdown formatter. That's their transport method.

And in Xplorerc, we can do a lot better. We can match any query to search for movies, ping a movie database, server an interactive native movie card, stream it down to the client with things like UI menus, any sort of new native view that comes down and is available on that device. We can then recurse back with more information. We have a server action which is fetching cast members and crew members from a movie. And then we can even like create calendar events where we have a card which then pings for the calendar permission and opens up the calendar prompt.

Truly magical. Thank you! It's going to get a little bit cooler, don't worry! Overall, a way better user experience, a lot less reading. But even more exciting than this cutting-edge user experience is the developer experience because it only took slightly more code than the text example. So here, we use a suspense boundary to show a skeleton loader on async component, fetches data and renders the movies, then streams them down to the client.

You notice this is, even though this is universal React codes, there is React Native in there, it's just React code. Like this is React code verbatim working on every device. It's very exciting. Now to make the cards interactive, we simply create a wrapper client component that has a bit of state inside of it. The JS logic used here will be split out of the main bundle and fetched conditionally when we render this card for the first time. So on native platforms that are using the Hermes engine, we split the bundle out in optimized bytecode format, meaning it starts up immediately and it's just memory mapped. You don't have to parse or anything. It's pretty sweet. It essentially means we are delivering the best strategies from the best web-only frameworks but running in a custom JavaScript environment that pushes the platform in your hand to its limits.

Because after we jump through all of the hoops required to make server rendering work, we aren't just rendering out to the DOM. No, instead, we get truly native views, as if the app were written with first-party tools. We have smooth scrolling, high-performance platform behaviors, it's progressively rendered, best practices, and truly limitless. Is it raining in here? Okay, perfect. I thought it was just me. And of course, the best part has to be, it runs like this everywhere. All platforms. So Expo supports iOS, Android, and web. It has Apple multi-platform support, some Macs, Vision Pros. I have this running on every computer in my house. It's actually pretty useful because, later, I'll show you it does Spotify stuff, and there's a Spotify app. Now our focus is on building the best possible experience, which means native on iOS and Android, but it also means that we need to leverage the ability that the web has to quickly access content, where you can send anyone in the world a link, they can open it, and then immediately see at least a preview of your full experience. So we do have web support in there as well. And then every link is fully linkable because it's a universal file-based router. So if you have the app installed and they send you a link, it will open the app to that exact location. Feels crazy. But I keep talking about how it feels and how it looks.

Let me just show you live, connected to my dev server on conference Wi-Fi. I think it'll be really sweet. So back here I've got the dev server running. I'm going to actually pump that font up a little bit. So you can just see we've got code streaming in here. I'll clean that up. And then over here, I've got a QuickTime preview of my app, my phone. It's got the iOS 18 beta too because I thought let's shake it up. That means we can also change the app icon to be green. Really important new features.

So we will open this up. I'm going to reload it so it's fresh right there on the server. You see it fetches all the different server actions in the background there. And this is the app. So we can say list new movies, just like we did in the video. I'll close this down over here. And then let's see. Keep moving this. Yeah, like that we have our native views. Could select one of them. And you'll notice in the background there, that was the server action fetching more data and then rendering more UI menu views in here. So it's a view that you wouldn't even think you could server render. We're server rendering it. We're doing it all. So Justice Owens or Justice Smith, we've got some more movies in here. Select one, create an event. It's pretty snappy, pretty fast. It is a dev server. But also I am emulating server timeouts in there as well. And then open a calendar event, you know, create it, whatever.

Oh, we've got a little text alignment fun down there. Okay, let's do something else. Let's say, you know, show me some pop songs. And then this will pull down a card which has Spotify in there. And this has login. So I can log out, log back in. I don't know why I just did that. What if it didn't log in?

Okay, we can log back in. We can see various musics here. I'm just going to long select it. It will play music, but I get the sense that that might not play over well with us playing on YouTube. What else can we do? We could say, you know, what's Charlie's phone number? Now this is going to render a card which sends down information which can then query my native contacts. So I don't have to send my contacts up to the LLM in order for it to filter. It's able to, you know, GDPR, it's able to send code down onto my device to do that filtering, which is pretty sweet.

No, we don't want to open that. So I got my Charlies here. I could select Charlie Cheever, send him a message. It'll say, you know, like, what do you want to send him? Explain how JSX works. Do that. Then maybe it'll, okay, well, it's really going for it. Okay, some markdown. We're formatting some markdown in there as well. Okay, cool. I'm just going to queue up, yes, send it, because I imagine it's going to be like, do you want me to say, okay, wow, it's really going. Yeah, sure, send it. All right, and now it will, you know, select this text. Let's see, we still got it running in the background here, right? Okay, good. Oh, okay, there it is. So now it's composed a message to Charlie. He's my boss.

He's a co-creator of Expo. I can just send that to him. And yeah, just like that, we're sending messages.

What else can we do? We could say, show me things to do around town. Let's just fix that one up. And now it's going to, I mean, look at all that data just fetched in the background. So it's fetching all of that data on the server action. We don't have to worry about optimizing it and having some, because this is the middleware, and then it sends down the minimal amount of JSX required, meaning we are optimizing our network requests.

And right here we have a client component for the map. But then this carousel is server rendered. So we're able to just smooth scroll through all of these locations in Amsterdam, right? It's pretty sweet. So maybe select one, say get the weather, because it knows, again, what we're talking about. I guess Amsterdam, okay? We can get some native interactions in there. We can say book an Uber to this location. Book an Uber, request an Uber, open me up into the Uber app. Let's not actually request it. It does say things like it's 28 euros, 25 cents. So you can say convert 28 euro to USD. Can't do the conversion in my head. Actually, that was pretty easy. I probably should have been able to do that. $31. But now, I don't have a currency conversion component built in, which is why it just sent me down text. If I ask it for a component, it will just write the component for me, render it in the server and stream down text, or at least I hope so. It is running a live developer server. So we could say create a component to convert currency. Now it's going to render in the background here. Or at least I hope so. I hope so. Let's see.

There it is. Pretty sweet. So right here we can see all of the text that it just created. We asked the GPT to render this component. It knows create a React Native component, we execute it, we stream it down. So now we have a currency converter.

So we could say, you know, what is 100 euros to USD? Immediately 112. So we are dynamically just generating. Basically my point here is you can do anything you want when you introduce server rendering to a native app. We could even say, you know, create a tic-tac-toe game component. I probably didn't need that component there. I think it figured it out. And then render this down.

So again, what's happening, like what we see here is we have this beautiful text view coming down. This streams. I have to make sure it adds use client so that we get interactive components. Oh, okay. Well, this is already done. It's pretty sweet that this always works. I can do... Let's see. Let's go next player O. Okay, it has the whole switching in there. Let's just try to win quickly. X. Winners. X. This is pretty sweet for me personally because when I did my first interview at a fang company, they asked me to implement a tic-tac-toe game in Swift. And here it just like, yeah, it just did it automatically. So, pretty cool.

Pretty sweet. If we were to switch back over here, I mean, this is Expo CLI. If we just hit the W key, it will open up in the browser. It did open up right in the browser but in this other window. So here we have it running in the browser. Same deal. Lists some movies. We have the movies running as before. I'm not going to do the whole demo over again. But you get the idea. I mean, it even runs in, I have it here on my desktop as well. We run it here on the desktop, you know, so I get the movie, lists some movies. Like, yeah, it's pretty sweet. I'm a big fan.

All right, let's switch back over to the keynote here. Now, that is what it looks like when we take the modern state of server rendering in AI and bring them universally to every single platform. Of course, the rain kicks up now. Seamlessly gliding between server and client in a fully typed file based framework. We only have to configure APIs for a single platform and that is the server. Making it easier than ever to build across platforms. In fact, that's why I was able to share so much. It's because these are just base primitives. All the functionality is running in the server. Whereas a traditional native app is usually running all that logic on the client. Making it even easier than ever before to actually make React Native seamless. All the waterfalls, parallel requests, they're handled for us as part of React server components. This isn't just any server rendering, we're using the best the web has to offer. The secrets are secured in the server, static client code is automatically removed from the bundle. Meaning you just drop some code in and if it can be removed at build time, it will be removed at build time. For the first time ever.

There's tons and tons of new benefits. Too many to go into. It just redefines what is possible with our mobile devices in our hands. And it just enables new types of apps to be built in record amounts of time. So, the app that you just saw is running Expo SDK 51, which means all the native code is actually out right now. This is just an Expo app built on top of that.

React 19, do new architecture, all that's out. The actual server renderer, first class support in Expo Router, still in progress. Work on it actively. Like I said, it requires me opening pull requests to every other library that you might use, if we move fast, have an early beta out by the end of this year. Consider this an RFC. Is server rendering something that you want to see on native apps? I believe so. I love using this. I love... I mean, it's just game changing, to be honest. And of course, I'm always looking for talented engineers to join my team. So, if you're interested in ushering in the future of app development, reach out to me on X. I'm Evan Bacon, and this has been Universal Server Components in Expo Router.

Thank you so much for your amazing talk. Now, I want to call out something. You were supposed to be here. I mean, you couldn't be here. But last year, we had the React Open Source Awards in 2023, and a certain tool called Expo Router actually won the Productivity Booster Award, and you were not here to collect it. So, can we give a yeah, they round of applause to Evan for Expo Router winning Productivity Booster Award in 2023? Wow. That's beautiful. Thank you. It's a yeah, they, and just in time. All right, we've got to jump into the questions, because when I say the Slido is going crazy, it's going crazy. I can see the list.

I can see the list. Oh, man. You have some good questions up there. There is a lot. So, I know we won't be able to get through all of them, so you can definitely catch him over at the Q&A.

Let's jump in with the first one. This is so exciting. This is amazing. But is generating the bundles server-side covered by app store policies? That's a fantastic question. Yeah. You know, so the thing about the RFC is that we aren't sending any native code down. And app stores, the policy is that you just can't change the content of your application, like the approved content, the approved behavior. Obviously, they can't prohibit the ability to make network requests, otherwise, like Facebook and Twitter wouldn't work. And apps today have OTA, they have web views, you can just change things dynamically. And if they change the behavior out from what was approved, it does get rejected. That's possible here. It's possible to use payments APIs for not legal stuff. But now you can just do it a lot easier and at a higher rate. Another thing is that what app stores will do is they... There's a lot of build time settings, which you can't change over the air. So this is going to be like accessing content or calendar permission. With these things, if you ship your app to the store, they'll go through and they'll see like, okay, can I access the prompt that says they want to use your contacts? And if you can't, then they can glean that you may be hiding functionality and they'll reject that binary. So there are policies in place, which this doesn't validate. But you do still have to use it responsibly. Like most APIs. Use them responsibly.

I totally agree. People are really excited about the demo. I love the demo. Will the source code be available? Can we own this and run it ourselves? Not right now, though.

But yeah, we're actively... So since I first revealed this at React Conf, I've been just splitting up the branch, and then opening it into the Expo repo. So you can see all the progress I'm making. GitHub slash Expo. It's in the apps directory. And yeah, we're just constantly merging it in. But we gotta do it slowly by slowly.

All right, so keep watching on the GitHub and on his Twitter. Yeah, I'll tweet it out for sure. And definitely, you will be able to get your hands on it.

The next question is actually about server components on mobile. And why do you need them when the bundle size and transfer don't really matter? Or is this only for React Native, like in the web? That's a good question. I was hoping my talk would have answered that question. Let's see. Server components on mobile with a bundle size... Well, so bundle size does actually matter a lot. The initial bundle size doesn't matter so much, because we have Hermes bytecode, which means we do all the parsing ahead of time, and then we memory map it instantly. But if you're splitting chunks out and you're loading them, there's still a network price that has to be paid. And you still have to wait. So it essentially works the same as the web. Same practice. And what's really important here is that things like bundle splitting policy and data fetching and rendering methods, these are not code that you want to be doing multiple times in a shared codebase. These are the parts that you really want shared. Things like UI can be more universal. So yeah, fantastic question, but it is very, very relevant on Native devices.

No, for sure, for sure. And this question is more about how you built the UI. Did AI generate the whole UI? I know there were times, for example, where you deliberately prompted generating or creating a component, for sure. What about the rest? Was that also created by it? Yeah. So half the fun here is you make your own components.

So things like the movies component was a pre-made component, and then at the end there where it generates and you can see the code above it, that is all AI generated. So that is not scripted, and I had no idea if it would actually execute or run. I have done this once before, so I was confident. Or if it didn't work, I could try to mitigate fixing it or make some joke about the rain. Yeah, so part of it was, but generated components, they are hard to get the styling to look really good and for this, I just wanted everything to look really nice. And then you saw there at the end, it was just like a button and then like an unstyled text box. So, yeah.

No, for sure. All right, we have got another question, which is especially with AI, you don't always know for sure what it is going to create. Yeah. So how do you know that the AI won't return code or a component or something that does against the app store policies or something fishy that you don't want to happen. Another great question. You guys are really on it today. So yeah, this could have been the singularity. Imagine that. We could have it generate anything and it starts streaming down code. Yeah, no, you have access to the code in the server before you run it, so you could run it in a containerized environment and see if it accesses outside the sandbox. Apple also has sandboxing for their code, which prevents you from just shipping native code over the air. So you can rely on lots of different layers of security. But also this is just a basic AI demo. The key takeaway is strings representing native code, meaning you can build any kind of app you want and you can build it better than any other app you've ever seen. Awesome. And I love this last question. I don't know if it's really a question, more so a statement that this is the Lord of the Ring style app. One app to rule them all. We have one amazing speaker who rules all of ExpoRouter. Can we give it up for Evan Bacon?