Bringing React Server Components to React Native

Hello everyone, hello Berlin. It's really nice to be here today. I'm really excited and also a little bit stressed because it's my first talk before the big stage. But today I've got a really interesting topic to present, React server components. But I would like to expand this topic to React Native part. And does it make sense to have RST on mobile? And what possibly should we do to upstream them to the production apps?

But first, a few words about me. My name is Szumon Rybczak and I'm 17 years old, React native developer at Callstack. On a daily basis, I work in a technology team where I support our R&D and open source initiatives. I'm also maintaining React Native Community CLI and I'm the youngest ever React Native contributor. You can find me on Twitter or on GitHub under Szumon Rybczak handle. I'm trying to post there very often stuff that you are cooking at Callstack.

So in software development, there is this principle that you can make something that is good, something that is fast, and something that is cheap. But you can only pick two. So you can make something that is good, something that is fast, but not relatively cheap to make. Or either you can make something that is cheap, something that is fast, but not really good. Or lastly, you can make something that is good, something that is cheap to make, but not fast. That's how Dona Bramov started a talk presenting an idea of React Server Components. Data fetching with React Server Components is a new idea in the ecosystem. And maybe React Server Components will solve our problems that we are encouraging when developing apps. And we have a bunch of problems, but the two ones that come with networking is big initial bundle size and sending unnecessary data over the network.

This video was published already three years ago, so a lot of things changed in the meantime. Dona and Laura were presenting the idea. Right now, we have production-ready implementation, for example, with Next.js. At Meta, they solved the problem of sending unnecessary data with Relay and GraphQL. Relay is a tool for receiving the GraphQL data for React. But, you know, it's not an easy task to implement GraphQL in a huge backend code basis. And with that, the entry barrier is really high. But the core team wanted a solution that would be easy enough to implement and would just work within the React model. So, how does React Server Components work? So right now, when developing React app, when the user hits the domain, the bundle is downloaded and executed on the client. The bundle is evaluated and that's where the magic happens.

But with RSC model, we are adding a new layer. We are adding a new server layer. So, this is the most important moment. We are executing React Components on the server. And then, we are streaming by chunks to the client. And by streaming, we are only streaming parts that will be displayed. So, we are not streaming unnecessary data, unnecessary props, or parts of the components.

Thanks to this, that we are executing on the server, we can access files on the server, we can access database, or we can make some smart move with cache to speed up our request. And it's all thanks to this format that is, as I said, streamed from a server. It looks like a JSON, but it's not. It's React Server Components specific format that is consumed on the client side. It contains things that should be displayed reference to the components, et cetera.

So, how does React Native fit to this whole image? And how even we can implement a server part inside React Native? So, everyone is talking about React Server Components in context of web, because that's where we have production ready implementation. But actually, in fact, server components were initially founded at Meta because of the promise they were showing when using server driven technologies on Native. And that's a nice plot twist. A lot of people think about RSC only in web context, but maybe they make some sense on mobile. But what architecture and what cost would it take to implement it?

So, React is on the repo, and two packages that are most important for us today are React Client and React Server. They contain logic for React Server Components, but only unified logic. So, the same logic will be applied for any bundler and any renderer. The custom logic is implemented through the config files. So, as we can see here, for example, for TurboPack, we have one config file, and for Webpack, we have another. And that's where we can possibly add a config file for React Native renderer and for Metro, which is a default bundler for React Native.

The main argument for React Server Components, as I mentioned, is reducing initial bundle size. So, the first chunk of the application will be shown really, really fast. But in mobile, we don't care that much about bundle size. We are downloading up once from the app store, and then app just exists there. Every time user visits the app, bundle is just there. And thanks to Hermes, the JavaScript engine designed for React Native purposes, the startup time for the application is pretty much the same for the application that has bundled 10 megabytes or 100. There are various apps, but I strongly believe that there's a space for RST on mobile. There are online first app and there are offline first app.

And, of course, for offline first app, RST wouldn't make sense. But I believe that there will be apps that will have one or will be strongly benefiting from having RST.

So, what are actually the benefits? Let's say that we are working on an app and majority of the apps has a tab bar. And we have Christmas around the corner and our client wants to add a new button, a new special Christmas button. And in web, it's just a matter of coding and deploying. It's just like easy process. But in mobile world, it's a little bit harder.

So, how does the standard flow for publishing mobile apps look in mobile? So, for first, we need to, of course, create a button. Then we need to build a binary app. After that, we need to submit the app to the app store. And then we need to wait a few days for the approval. And this process can be painful, especially when you have some critical bug on the production and you need to wait a few days, even weeks for the app publishment.

But thanks to React Native Architecture, we have over the year updates. So, React Native Architecture production app is containing the native part and the bundle part so that we can remotely replace the bundle. So, how does the flow look like with OTA? So, we are creating the button. Then we are bundling the code. And then we are uploading the bundle to the server. And thanks to Expo or Repack, next time user will visit the application, new bundle will be downloaded. And that's cool.

But, you know, here we need to replace the whole bundle. And sometimes the bundle downloading bundle from remote server can take a while. And that's not the best experience. But with React components we can iterate on the higher level. We can iterate faster. So, the matter of publishing changes in mobile apps with RSC will look like this. Of course, we need to create a button. And then we only need to bundle the one component. We don't need to bundle the whole bundle for application. Just one component. And then with some solution on the next user entry to the application, the bundle only for this small button will be downloaded.

Not for the whole application. Another great example are federated super apps. This concept sounds a little bit complicated. But I will try to explain it. Super apps are this kind of apps that can be split into smaller chunks. We can think of a few examples. For example, Facebook app. It contains a bunch of modules. Marketplace, dating module, game module, a lot. And here we have some example apps placed to the smaller chunks. And we can see shawl. That is an app container. And booking and shopping modules. These modules are living on a server. We can access them on demand. So, for example, we can hide them under some button. And when a user clicks it, thanks to module federation, we are downloading bundles from the server. And that's great. But when the bundle, the remote bundle is big or even small, but user has low internet connection, it can take a while to download it. But with React components, we can speed up the evaluation of the remote chunks so that time to interact and first chunk, first component to interact will be downloaded fast and quickly.

If you want to learn more about this concept, go check out the talk from our head of technology, Mike Pioschkowa. Mike is presenting this concept and how this can speed up the development, especially inside big teams.

So, to sum up, what are the main benefits for React Native server components? So, for first, we are not sending unnecessary data over the network. Just things that will be displayed. They're capable. We can, as I presented with this example, we can iterate faster by feature flags and rollout. And also, thanks to React architecture, they're well designed. They're working with the client components and with suspense mechanism. And that's just the beginning. We don't have any implementation. There are no information about this concept. And hopefully, next year, we'll have some production implementation, maybe experimental implementation. But it's great to start the discussion and see how we can benefit from having RST on mobile.

And I would like to present an example how we can fit React server components inside some example app. There's this cool app called Blue Sky. And this is a new social media platform. And by the way, the codebase is open source. The app is written in React Native with Expo. And they are shipping one codebase to three platforms. So, that's really great. And a lot of people say that with RST on mobile, we'll lose native UX feeling of the application. I don't agree with this take. For me, properly implemented React server components inside mobile app will just speed up our development process and will help us. The feeling of the application before applying React server components and after will be the same.

So, how we can fit React server components here? As we can see here, on the screen, we have some major components. So, we have a header. We have some feed view. Or we have some feed view, list view, whatever else in every social media app. And we have our top navigator with some tabs to navigate for the application. And of course, when dealing with networking inside mobile apps and web apps, we need to care about two states.

So, when a user has a low internet connection, we need to present some loading view, activity indicator, to not screen to be blank. And also, we need to care about errors. So, when users don't have internet connection. And to have the native feeling of the application, we need to bundle this header, loading view, error boundary, and top navigator to the initial bundle. Because users must be user must navigate through the application immediately after clicking app icon. It must be we cannot wait for the remote chunks to resolve. It's users must be allowed to just go through the app.

And one component that we can migrate here to the make it as a server components is, of course, a feed view, a list view that is making a lot of database calls is fetching posts, avatars, and all kind of information. And by doing this as a server components, we can benefit a lot. We are not streaming unnecessary data. And for example, if you want to add a new type of post or remove some kind of post or make some design changes, we can just do it and deploy it without Apple review. And I strongly believe that the application before and after applying React components, the experience of it stays the same. But the things that we can benefit. So, we can iterate faster and request just our we have GraphQL out of the box, we can say.

And yeah. That will be it. Thank you. All right. So, we have our first question coming in. Firstly, thank you so much for the talk. I think it was really interesting. So, the first question we have in is, when do you think this might end up being the wrong approach when building with React Native? So, when our app is offline first. And then React components doesn't apply for this use case. And also, if next year or in the future, we'll have some production implementations for RSC, we need to worry about caching those components to make everything and the experience stays the same, stays native. That's the best experience. Yeah. This next question that came in was actually going to be the one I asked next. So, thank you so much for asking it. Do you think Apple or Google might just end up rejecting apps where it effectively could bypass a review process and push new bundles straight to the users? Yeah. So, that's a tricky one.

And of course, Apple in their apps are low. They have described it. So, we need to be very careful. We can't ship major features, major changes to our application that can hurt Apple. So, we can ship only some minor or some changes that Apple wouldn't like. Yeah. I think this is going to be the interesting one, how this particular I mean, this is all hypothetical right at this point. Both in terms of implementation and actually being accepted into App Stores. I think this is going to be- And the first one thing that I would like to mention is that we are already doing this. We are doing OTA updates already. So, we are remotely replacing the bundle. So, and Apple likes that. If we are careful and we are not shipping bad things to the application, Apple is okay with that. And yeah, that's cool. Yeah. Awesome.

And again, I look forward to seeing how that shakes out in particular. Is CoreStack working on a solution for React Server components? So, as I mentioned, I'm working in the R&D team. And as part of my job, I'm doing the research. And for a few last months, I was doing research about React Server components in mobile. And we'll see. We have Repack. That is a library with which you can use Repack inside React Native apps. But yeah. Stay tuned. And maybe next year we'll release something. Ooh. It's teasers.

Okay. This is a question. Now, I'm going to be completely candid here where I don't understand terminology myself. I don't know what Metro is. Do you know what Metro is? Yes. Wonderful. Great. That means something. So, the question is, do you not think that the approach with Repack is circumventing React Native by replacing Metro? Seems like a massive tradeoff. Could I ask you to give us a quick primer on what Metro is as well? So, Metro is a default bundler for React Native, and it's maintained by Meta. And Repack is a solution that we are maintaining at CoreStack, with which you can try Repack inside React Native apps. And as I understand this question correctly, do you think that... I don't think so. Repack has a bunch of great features that Metro doesn't have. So, for example, module federation and others concepts. Metro is a great solution, and often people ask whether you should use Metro or Repack. It depends on the case. And if you want to build a super app, or maybe you want to add React Server components, we'll see.

But I don't think so. Cool. Thank you.

This next question is one I was also wondering about. So, how do React Server components solve the single bundle restrictions that we face with React Native apps with over-the-air updates? Currently, both Expo updates and Code Push only support a single bundle. How would you do partial? Yeah, so that is a tough one to implement. I tried implementing React Server components, and it's hard. There is a bunch of work that needs to be done to properly implement React Server components, and one of them is to have multiple bundles that will just work with mobile apps. And I think to React Server components' success on mobile, we need to have a really good developer experience. And the matter of adding React Server components to the application would be just to add the useServer, useClient directive inside component. And everything needs to be done on the framework side. So, you would still ship with the current tooling. And it could be that the current tooling is not the tooling by the time this actually lands. I think that's kind of what you're implying. But at the moment, should that not change, there is almost a deficiency might be a strong word, but there would be this caveat that you are going to have to ship a full new bundle using current tooling, is that right? Yes. Yeah, cool. Hopefully, that changes because I think that really impacts the viability of this approach.

I'm going to slightly rephrase this question because I do understand what it's trying to say. But to slightly rephrase it, is it just the individual components you would advocate become React Server components, or would it be that basically the entire app is rendered within React Server components? So, as I mentioned, in a talk, we need to be very careful. And with React Server components, without React Server components, and after adding React Server components to the application, the native experience needs to be the same. So, there must be always client components, such as a tab or navigators, or loading states, or error boundaries. We cannot allow to just show a blank screen, because then we are losing the point of the native application. So, no, the whole app, for me, wouldn't ever be a server, rendered on the server, because then we are losing the native feeling of the application. Yeah. And like you say, the feeling, I think there is a user expectation, right? When you open an app, it acts and feels a certain way, even while data's loading. We understand these patterns that we look for, that something's happening in the background. Also, I think that would be a surefire way to just have an app rejected from an app store, because I think these states are tested against during the submission process. I was also wondering about this one. God, I love these questions. They're right in my brain today.

How would you orchestrate different app versions with different server component versions? And yeah, this also needs to, for me, this also needs to be done on the framework side. So, we have Expo that has, yes, if Evan Bacon's listening to this, I hope that they will ship some great solution, and it needs to be done by the framework. So, yeah, we need to have some simple way for managing this. I don't know if that will be a dashboard for deployment or some CLI tool. I don't know, but it will need to be done on the framework part.

But there's something else here as well, which is just from an expectation standpoint, and this might be something that gets developed over the course of the next few months as this becomes, again, a viable solution with an implementation. At what point are you actually asking users to update an app? There's so many parts of that. There's understanding there's a new version, there's consenting to there being a new version, there's the severity of changes that are taking place. Because in theory, you could do a lot of this. Like you said, you could do a lot of this over the air. And I think there's almost like a standard that needs to be landed upon about in which cases it is an app update version, and at what points we can just push small updates to users.

There was another... I thought I saw the question which was around feature flagging, and maybe not. Maybe I imagined a question, but we have some more in the meantime.

Would the React server component be held be only held in memory or persisted on the actual device itself? And what would happen on sudden loss of network connection? Yeah. So, when shipping React server components to mobile, we need to keep in mind that we have a disk and then there we can probably cache some things. So, it will depend on the case. And if there will be suddenly lost network, it also needs to be properly covered by the framework. So, the proper state, proper error should be displayed. That is on the client. So, we have it and we can display it. And yeah.

But what... Sorry, I'm not sure that quite sat with me. So, are these components then stored... I suppose the bundle is... The bundle is stored on the device, but if that bundle needs updating at all, you know, and you lose connection during that, you kind of lose the ability to show these components. Yes. But we have the full box components that needs to be a client component because we are losing native UX filling of the application. I think that's kind of the undercurrent across a lot of your talk is definitely not all of this should be React server components, but the parts that actually benefit from the properties of server components should be. Otherwise, it should be native. Yes.

Cool. We have time for a couple more questions, but do feel free to keep them coming. Just as a reminder, we have a speaker's Q&A straight after this by the speaker's Q&A area, which is near the entrance here in the venue. And online, you can get to that using the timeline at the bottom. Are you collaborating with Meta on this project? And if not, is there a risk of diverging between how Facebook uses React Native versus projects like this? So, I can't share the details, but we are working on this. And that's what I can say right now. And the second part, if not, is there not a risk of diverging away from the way Facebook uses React Native compared to the community? Well, that seems to not be the case based on your indicated can't really talk about the answer. So, I mean, I think the answer there is, if I may, feels pretty clean cut. Yes, there is a risk of diverging, but that risk is being mitigated through some form of ongoing work that will be spoken about in the future.

This one's interesting. I think you kind of implied this at points in your talk, but when do you expect React server components will be usable? I hope next year we'll have some experimental solutions. And in a few years, I would like to have a production implementation. I think we are at the moment, I think, idea. And, yeah, I won't show a demo. We're also working on this. So, I hope that we can collaborate and ship some great stuff. Awesome.

We have time for one more really quick question. Is there any significant differences when locally testing using React server components with React Native? I don't know. I didn't test it. We'll see. I love that as actually a real nice place to leave this. We'll see. But I really appreciate the kind of look into the future that you gave us today.