Bringing React Server Components to React Native

Rate this content

React Server Components are new topic in community, bunch of frameworks are implementing them, people are discussing around this topic. But what if we could use React Server Components in React Native? And bring all optimisation features that RSC allows to mobile apps? In this talk I would present what we are able to do with RSC in React Native!

29 min
08 Dec, 2023

AI Generated Video Summary

React Server Components (RSC) offer a more accessible approach within the React model, addressing challenges like big initial bundle size and unnecessary data over the network. RSC can benefit React Native development by adding a new server layer and enabling faster requests. They also allow for faster publishing of changes in mobile apps and can be integrated into federated super apps. However, implementing RSC in mobile apps requires careful consideration of offline-first apps, caching, and Apple's review process.

1. Introduction to React Server Components

Short description:

Hello everyone, hello Berlin. I'm really excited to present React server components and discuss their relevance in React Native development. Let's explore the challenges of networking in app development and how React Server Components can address them. Dona Bramov introduced this idea, aiming to solve problems like big initial bundle size and sending unnecessary data over the network. With the production-ready implementation of Next.js and solutions like Relay and GraphQL, React Server Components offer a more accessible approach within the React model.

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.

2. React Server Components and React Native

Short description:

With React Server Components (RSC), we add a new server layer and stream only the necessary parts to the client. This format, specific to RSC, allows access to server resources and enables faster requests. React Native can also benefit from RSC, as they were initially developed for server-driven technologies on Native. The logic for RSC is contained in the React Client and React Server packages, with custom logic implemented through config files. While mobile apps may not prioritize bundle size, RSC can still be valuable, especially for online and offline-first apps.

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.

3. Benefits of React Server Components in Mobile Apps

Short description:

For offline first apps, React Server Components (RSC) may not be relevant. However, there are apps that can strongly benefit from RSC. The standard flow for publishing mobile apps involves creating a button, building a binary app, submitting it to the app store, and waiting for approval. This process can be time-consuming and frustrating, especially when critical bugs need to be fixed. With React Native Architecture, we have over-the-air (OTA) updates, allowing us to remotely replace the bundle. Instead of replacing the entire bundle, RSC allows us to iterate on specific components, resulting in faster publishing of changes in mobile apps.

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.

4. Federated Super Apps and React Components

Short description:

Federated super apps, like Facebook, can be split into smaller chunks. These smaller modules, such as the marketplace, dating, and game modules, can be accessed on demand from a server. By using React components, we can speed up the evaluation of remote chunks, allowing the first component to be downloaded quickly.

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.

5. Benefits of React Native Server Components

Short description:

If you want to learn more about this concept, go check out the talk from our head of technology, Mike Pioschkowa. So, to sum up, the main benefits of React Native server components are not sending unnecessary data over the network, faster iteration with feature flags and rollout, and the well-designed integration with client components and suspense mechanism. Let's explore how React server components can be integrated into the Blue Sky app, a new open-source social media platform written in React Native with Expo. Despite concerns about losing the native UX feeling, properly implemented React server components can actually speed up development without affecting the application's overall experience.

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.


React Native App Challenges and Server Components

Short description:

When users have a low internet connection, we need to present loading views and handle errors. To achieve a native feeling, we bundle essential components to the initial bundle. Migrating the feed view to server components allows faster iteration and deployment without Apple review. However, offline-first apps and the need for caching in future implementations may not be suitable. The question of whether Apple or Google will reject apps bypassing the review process is a tricky one.

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.

Apple's Restrictions and OTA Updates

Short description:

Apple's restrictions on major feature changes in applications require us to be cautious. However, minor changes and OTA updates, which involve remotely replacing the bundle, are acceptable to Apple. This is an interesting area to explore, considering the hypothetical nature of implementing React Server components and their acceptance into App Stores.

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.

CoreStack's Solution for React Server Components

Short description:

Is CoreStack working on a solution for React Server components? I've been doing research on React Server components in mobile and we have Repack, a library for using Repack in React Native apps. Repack has features that Metro doesn't have, such as module federation. Whether to use Metro or Repack depends on the case, especially if you want to build a super app or add React Server components.

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.

React Server Components and Bundle Restrictions

Short description:

But how do React Server components solve the single bundle restrictions in React Native apps with over-the-air updates? Implementing React Server components is tough and requires multiple bundles for mobile apps. The success of React Server components on mobile relies on a good developer experience. The current tooling may require shipping a full new bundle, which impacts the viability of this approach. React Server components should not replace the entire app, as the native experience should remain the same. Client components are necessary to maintain the native feeling and user expectations. Rendering the whole app on the server could lead to app rejection from app stores.

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.

Orchestrating App Versions and Updates

Short description:

How would you orchestrate different app versions with different server component versions? It needs to be done on the framework side, and there should be a simple way for managing this. The expectation of when to ask users to update an app and the severity of changes need to be considered. There should be a standard for determining when it is an app update version and when small updates can be pushed to users.

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.

React Server Components and Device Storage

Short description:

There was a question about whether React server components are held in memory or persisted on the device. When shipping React server components to mobile, caching can be done on the device's disk. In case of sudden loss of network connection, the framework should handle it by displaying the proper state and error on the client. The bundle is stored on the device, but if it needs updating and the connection is lost, the ability to show the components is lost. However, some components still need to be client components to maintain the native user experience. The talk emphasizes that not all parts should be React server components, only the ones that benefit from their properties. There is time for a couple more questions, and the speaker's Q&A session will follow. The speaker is collaborating with Meta on this project, although details cannot be shared. There is a risk of diverging from how Facebook uses React Native, but ongoing work is being done to mitigate it.

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.

Future of React Server Components

Short description:

When do you expect React server components to be usable? Next year, we hope to have experimental solutions, and in a few years, a production implementation. We're working on it and hope to collaborate. Any significant differences when locally testing React server components with React Native? I don't know, I haven't tested it. We'll see. Thank you for the insightful look into 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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2023React Advanced Conference 2023
29 min
Raising the Bar: Our Journey Making React Native a Preferred Choice
At Microsoft, we're committed to providing our teams with the best tools and technologies to build high-quality mobile applications. React Native has long been a preferred choice for its high performance and great user experience, but getting stakeholders on board can be a challenge. In this talk, we will share our journey of making React Native a preferred choice for stakeholders who prioritize ease of integration and developer experience. We'll discuss the specific strategies we used to achieve our goal and the results we achieved.
React Finland 2021React Finland 2021
27 min
Opensource Documentation—Tales from React and React Native
Documentation is often your community's first point of contact with your project and their daily companion at work. So why is documentation the last thing that gets done, and how can we do it better? This talk shares how important documentation is for React and React Native and how you can invest in or contribute to making your favourite project's docs to build a thriving community
React Advanced Conference 2021React Advanced Conference 2021
21 min
Building Cross-Platform Component Libraries for Web and Native with React
Building products for multiple platforms such as web and mobile often requires separate code-based despite most of the components being identical in look and feel. Is there a way where we could use shared React component library on different platforms and save time? In this presentation I'll demonstrate one way to build truly cross-platform component library with a unique approach of using React & React Native in combination.

Workshops on related topic

React Advanced Conference 2022React Advanced Conference 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
React Summit Remote Edition 2021React Summit Remote Edition 2021
60 min
How to Build an Interactive “Wheel of Fortune” Animation with React Native
- Intro - Cleo & our mission- What we want to build, how it fits into our product & purpose, run through designs- Getting started with environment set up & “hello world”- Intro to React Native Animation- Step 1: Spinning the wheel on a button press- Step 2: Dragging the wheel to give it velocity- Step 3: Adding friction to the wheel to slow it down- Step 4 (stretch): Adding haptics for an immersive feel
React Advanced Conference 2023React Advanced Conference 2023
159 min
Effective Detox Testing
So you’ve gotten Detox set up to test your React Native application. Good work! But you aren’t done yet: there are still a lot of questions you need to answer. How many tests do you write? When and where do you run them? How do you ensure there is test data available? What do you do about parts of your app that use mobile APIs that are difficult to automate? You could sink a lot of effort into these things—is the payoff worth it?
In this three-hour workshop we’ll address these questions by discussing how to integrate Detox into your development workflow. You’ll walk away with the skills and information you need to make Detox testing a natural and productive part of day-to-day development.
Table of contents:
- Deciding what to test with Detox vs React Native Testing Library vs manual testing- Setting up a fake API layer for testing- Getting Detox running on CI on GitHub Actions for free- Deciding how much of your app to test with Detox: a sliding scale- Fitting Detox into you local development workflow
- Familiarity with building applications with React Native- Basic experience with Detox- Machine setup: a working React Native CLI development environment including either Xcode or Android Studio
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.
React Advanced Conference 2022React Advanced Conference 2022
131 min
Introduction to React Native Testing Library
Are you satisfied with your test suites? If you said no, you’re not alone—most developers aren’t. And testing in React Native is harder than on most platforms. How can you write JavaScript tests when the JS and native code are so intertwined? And what in the world are you supposed to do about that persistent act() warning? Faced with these challenges, some teams are never able to make any progress testing their React Native app, and others end up with tests that don’t seem to help and only take extra time to maintain.
But it doesn’t have to be this way. React Native Testing Library (RNTL) is a great library for component testing, and with the right mental model you can use it to implement tests that are low-cost and high-value. In this three-hour workshop you’ll learn the tools, techniques, and principles you need to implement tests that will help you ship your React Native app with confidence. You’ll walk away with a clear vision for the goal of your component tests and with techniques that will help you address any obstacle that gets in the way of that will know:- The different kinds React Native tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting text, image, and native code elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RNTL tests and how to handle them- Options for handling native functions and components in your JavaScript tests
Prerequisites:- Familiarity with building applications with React Native- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Native Testing Library- Machine setup: Node 16.x or 18.x, Yarn, be able to successfully create and run a new Expo app following the instructions on