Do you ever get a feeling that time flies even faster these days? We sure do, and we bet September will come sooner than we think, so it’s time for a big announcement: React Native EU is back for a 100% in-person edition!

This year, we’re meeting on September 7–8 at Wrocław Congress Center in Poland, just like we did in the old days. The date might deem distant now, but before you know it, spring and summer will pass, so why not save your spot now at a discount price? There are 8 blind birds tickets left, so don’t think too long.

Some of you might not be familiar with or haven’t had a chance to attend React Native EU yet, though. So before we shed more light on the 2023 edition, let us explain why it’s a go-to event for React Native developers and how it evolved over the years.

What does React Native EU stand for?

Our React Native conference is the biggest community-driven event of this kind in Europe. Every September, we give top software development experts the floor to discuss hot topics in the React Native world, from recent tech trends to case studies. The best part is that as the participant, you get to not only listen to but also network with the speakers — and there’s no better way to learn than through interaction.

Among the things that set React Native EU apart are:

• Full focus on React Native. You won’t find there web, backend, or general-purpose talks. But if you’re looking for expert experience-based React Native insights, you’ve come to the right place.
• Expert speakers. Attending our conference, you get to meet and learn from the biggest names in the React Native community. Every year, we invite speakers from Meta, Microsoft, Stripe, Shopify, and other companies that live and breathe this technology.

• Practical tech content. Our speakers solve all sorts of complex problems with React Native at work, and they’re here to share lessons learned with you. Don’t take our word for it, and check out talks from previous editions.
• Opportunity to meet Core Contributors. Among our speakers, you’ll find the creators and maintainers of important libraries and projects. The presence of Core Contributors makes React Native EU a perfect place to learn about the latest development and most promising trends.
• Networking with like-minded attendees. By attending our React Native conference, you become a part of the community. You get to create it and develop meaningful relationships with people of similar interests from all over the world.

• The atmosphere and entertainment. At React Native EU, we work hard and play hard, so you can expect a grand reception and afterparty, local food and drinks, not to mention tourist attractions offered by Wrocław. We can guarantee you won’t get bored, and you’ll make some great memories of the #RNEUvibe.

Not that you know what to expect, how about taking a sentimental journey through the conference’s history?

A glimpse into React Native EU’s history

React Native EU conference was born out of engagement in React Native community, love for Open Source, and the desire to shape the framework’s future direction. To quote Mike Grabowski, Callstack’s cofounder:

There are lots of tricky things with React Native, partially because of iOS and Android ecosystems. There are lots of unanswered questions hanging around, or just people struggling to find answers for problems that may seem trivial to us. This conference is the place they can visit, get answers to questions and go home start writing their next cool startup.

The birth and growth of React Native EU

The first three editions of our React Native conference took place on-site in Wrocław, Poland. Back then, meeting in person was to be expected; but soon, the event landscape was about to change.

React Native EU grew quickly; in 2019, it gathered a record number of 360 attendees. It also quickly proved to deliver top quality in all regards. On the one hand, there was top-notch tech expertise shared by Facebook, Callstack, AutoZone, Expo, and Microsoft experts; on the other, the unparalleled experience shaped by the historic venue, the entertainment (including the legendary karaokes), and other amenities.

2019 also featured the first edition of the Core Contributor Summit as organized by Callstack. The event aims at bringing React Native contributors and having them join forces on pushing for the improvement of the technology.

Although the event isn’t a part of React Native EU program, it happens right before the conference. The biggest perk of such timing is that Core Contributors who participate in the summit share knowledge at our conference, allowing attendees to meet and learn from them. This way, developers taking part in RNEU can get inspired, learn from, and simply hang out with the people behind the technology they’re using on a daily basis.

Moving online: React Native EU in 2020 and 2021

2020 was a year like no other for obvious reasons. As the pandemic hit, the world shifted to online, and so did our conference. This way, we could give React Native enthusiasts an opportunity to learn and network with fellow developers regardless of travel restrictions. The location changed, but our core values remained the same. As always, the 2020 and 2021 virtual editions were focused on the community, core contributors, and high-quality practical tech insights.

The biggest advantage of going online was undoubtedly the unprecedented scale of the event. As the distance was no longer an issue, we welcomed thousands of attendees from all around the globe, from the USA, UK, and France to Turkey and Brazil. In 2021, the number of guests rose to eight thousand, which was pretty impressive for both Callstack as organizers and the attendees, who got to meet even more like-minded individuals!

Even though our attendees could not high-five each other in person, they had plenty of networking opportunities thanks to a dedicated conference Discord channel. That’s where speakers hang out and heated Q&A debates took place. To give back to this part of the community that didn’t make it to the 2020 edition, we published the most interesting questions and answers on our blog.

One foot online and one foot in Wrocław: hybrid RNEU 2022

2022 marked yet another turn in React Native EU history. As the world was slowly getting over the pandemic, we decided to hold a hybrid event: we invited the public to participate online, welcomed most speakers and Callstackers in person, and brought the Core Contributor Summit back to Wrocław. This reminded us of the best part of attending conferences as we used to know them: having a chance to hang out and have fun together.

Here’s how Łukasz Chludziński, the host of React Native Show Podcast, remembers last year’s conference:

2022 edition was my first time as a full-time host, and being there in person felt awesome. Even though it was a hybrid event, you could feel that those who joined us were hungry for talking, meeting, and learning. The energy was great, and I can’t wait to feel it this year when everybody’s once again in Wrocław.

Moving back to Wrocław: React Native EU 2023

This year, our React Native conference returns to its roots: a fully on-site edition taking place on September 7–8 in Wrocław. Tickets are already on sale, and you can buy them on React Native EU website at a hefty discount.

The big reveals are yet to come, but here’s what you expect for sure from React Native EU 2023:

• React Native Superstars speakers, discussing real-life case studies and recent development in technology. We’ll let you know about the lineup in spring, but trust us; you should be already excited.
• High-tech content only, laser-focused on various aspects of React Native, from performance and UX to testing and native aspects.
• Networking as we used to know it before the pandemic: in-person, with plenty of opportunities to get to know the attendees as React Native development experts and simply cool people to hang out with.
• Wrocław as the ultimate meeting place. Our venue will be once again the historical building of Centennial Hall, in the close vicinity of the famous Pergola, Szczytnicki Park, and Japanese Garden. And after the talks, you’re free to explore the vibrant city of Wrocław and its attractions.
• The unique #RNEUvibe. What do we mean by that? The after party, karaoke, chill-out zone, local food and drinks… It’s impossible to put into words, but once you experience it, you’ll want to go back year by year.

Most of all, the on-site edition is an opportunity for us to contribute to the community revival after three years of primarily offline meetings. We aim to give you all a chance to mingle and strengthen relationships right at the center of Europe — and we can’t wait for that to happen!

Call for papers is opening soon, and we’re waiting for you to discuss React Native topics dear to your heart. If you’re excited about sharing high-tech insights with fellow developers, subscribe to our conference newsletter and be the first to know about the CFP opening.

Save your spot for React Native EU 2023

Are you as excited about sharing React Native knowledge and learning from industry thought-leaders as we are? If so, buy your ticket now and save your spot for React Native EU 2023! We can’t wait to welcome you to Wrocław ❤️️

This article was originally published at callstack.com on March 1, 2023.

React Native EU 2023 and a Glimpse Into Conference History was originally published in Callstack Engineers on Medium, where people are continuing the conversation by highlighting and responding to this story.

The following article is part of The Ultimate Guide to React Native Optimization. Including valuable insights from React Native Core Team, it explains the benefits of experimenting with the New Architecture of React Native early on.

Why is this important?

It might be that your app is using an old architecture without the concurrent features of React 18. Or perhaps it’s better to say “current” architecture since it’s still mostly used by production apps. Either way, if you went for New Architecture, you could be leveraging the capabilities of the new rendering system inside your app — and this could greatly benefit your product and improve business results. In this blog post, we’re going to explain what New Architecture is and how it can improve your React Native project.

In other blog posts based on The Ultimate Guide to React Native Optimization, we touch on the following performance-related topics:

• Optimizing your Android application’s size with Gradle Settings
• Optimizing your Android app startup time with Hermes
• Automating your dependency management with `Autolinking`
• Debugging faster and better with Flipper
• Why Is It Essential to Always Run The Latest Version of React Native?

Check them out! Now let’s jump into the main topic.

Old vs. New Architecture

Both new and old architecture are based on the communication between JavaScript and the native side. Currently, this communication is handled by the bridge. Let’s go over its limitations to understand better the problems that the New Architecture is trying to solve:

• It is asynchronous: the JavaScript side submits data to a bridge and waits for the data to be processed by the native side.
• It’s single-threaded, so it’s important not to overload the JS thread and execute animations on the UI thread.
• It adds additional overhead when it comes to the serialization of data from JSON objects.

The bridge is still working fine for most use cases. However, when we start to send a lot of data over the bridge, it may become a bottleneck for our app. This issue can be seen when rendering a lot of components in a long list. When the user scrolls fast, there will be a blank space caused by the communication between the JS and native sides being asynchronous. Essentially, we are having a “traffic jam” on our bridge with objects waiting to be serialized. The same issue with the bridge being “overloaded” can be seen in native modules sending a lot of data back and forth.

This bottleneck, together with providing a type-safe way of communicating between native and JS, are the main things that the new architecture is trying to solve. However, not everything about new architecture is as good as it may seem. We will also get into the drawbacks that it brings.

What is New Architecture?

Starting from React Native 0.68, developers can leverage new capabilities of the framework. The New Architecture relies on a series of tools, which are key components to the new experience.

Two most important ones are Fabric and TurboModules. The first one is a new rendering system, and the second one is a new way of writing native modules. We will get into details later in this section.

Codegen and JSI are two new tools improving the developer experience. They are essential to understand how the new architecture works. Codegen drastically improves DX by generating a lot of native boilerplate code and ensuring type safety. And JSI, a C++ API for interacting with any JS engine.

Note: Prior to React Native v0.71+ it’s possible but way harder to deploy the New Architecture in an app. So that’s the version we are suggesting for you to upgrade.

Codegen

A code generation tool that makes JS a source of truth by automating the compatibility between JS and the native side. It allows writing statically typed JS (called JS Spec), which is then used to generate the interface files needed by Fabric native components and TurboModules. Spec consists of a set of types written in TypeScript or Flow that defines all the APIs provided by the native module.

Codegen ensures type-safety and compile-time type safety, which means smaller code and faster execution as both realms can trust each other around validating the data every time. To find out more about it, refer to the docs.

JSI

JSI is the foundation of the New Architecture, a C++ API for interacting with any JS engine. In contrast to the bridge, which was asynchronous, JSI is synchronous, which allows for invoking native functions faster. It lets JavaScript hold references to C++ host objects and invoke methods directly on them. This removes the major overhead of asynchronous communication between JS and native by serializing objects using the bridge.

Fabric

Fabric is React Native’s new concurrent rendering system, a conceptual evolution of the legacy render system. The core principle is to unify more render logic in C++ to better leverage interoperability between platforms. Host Components like View, Text, etc. are now lazily initialized, resulting in faster startups. Fabric allows us to take advantage of the features introduced in React 18.

TurboModules

This is a new way of writing native modules that also leverages the power of JSI, allowing for synchronous and an order of magnitude faster data transfer from native to JS and vice versa.

It is a rewrite of the communication layer between JavaScript and platform native modules like Bluetooth, Biometrics, etc. It also allows for writing native code for both platforms using C++ and introduces the lazy loading of modules to speed up your app startup time.

Bridgeless mode

For the time being, React Native is not removing the bridge completely; it’s still there, allowing developers to gradually adopt new architecture and JSI. However, usage of the bridge needs to be explicitly stated (by importing it), so not yet migrated modules won’t work.

Meta is planning to soon allow apps to run in completely bridge-less mode, which will result in faster app startup due to removing the overhead of loading the bridge every time the app starts.

How to turn on New Architecture

To turn on the New Architecture in your app, you need to update your app to at least React Native 0.68; however, we recommend upgrading to at least React Native 0.71+ because a lot of improvements have been added.

To migrate your app to the New Architecture, follow these steps:

1. Upgrade your app to at least React Native 0.71+, you can use https://react-native-community.github.io/upgrade-helper/
2. Check all third-party libraries that your app depends on; the important thing is that all of them need to be migrated! This might be a long-time blocker for a lot of apps out there. Components that are not yet compatible will show a red box — Unimplemented component: <ComponentName> — and you will likely notice them. In that case, please let the library maintainers know about it, as this will speed up the adoption.
3. [Android] Set newArchEnabled=true in gradle.properties.
4. [iOS] Run RCT_NEW_ARCH_ENABLED=1 pod install inside the iOS folder.

Benefits of moving React Native app to New Architecture

Now that you know how New Architecture works, let’s go over its benefits.

Performance

Due to the synchronous nature of the new architecture, while communicating with the native side, there will be some performance improvements. The app’s startup time will be significantly reduced as every native module will be lazily-loaded. Once the bridgeless mode is available, it will also remove the overhead of loading the bridge at startup. However, not every scenario proves this; in some of the benchmarks, architecture performance is worse.

Meta’s goal was not to make new architecture X times faster than the old one. Apart from removing major bottlenecks, they wanted to create a new solid foundation, allowing for new capabilities that could not be developed using previous architecture. Migration of the Facebook app took over a year, and they haven’t noticed any significant performance improvements or regressions that are perceivable by the end user. However, this doesn’t mean that performance improvements won’t come in the future. Now that they reworked internals, they have a great foundation to build upon.

Let’s go over some performance benchmarks by Alexandre Moureaux from BAM. Here is a link to the source: https://github.com/reactwg/react-native-new-architecture/discussions/85

Benchmark of rendering 10K views

In this case, new architecture proves more efficient than the old one. Using on average less CPU but more RAM.

Benchmark of rendering 2K Text components

The old architecture is faster in this scenario because of heavier UI thread consumption.

The official response from the React Native team is that their internal benchmarks while rolling out the New Architecture to users were neutral across all React Native surfaces in the Facebook app on both Android and iOS. As stated by Samuel Susla in this discussion thread, “In the last years, we conducted dozens of tests in production on millions of devices to assure performance was neutral.”

So in most use cases, you can expect a neutral performance impact without any performance regressions. And keep in mind that the New Architecture is getting better every single day, with many developers contributing to the repository, so the results may be totally different by the time you are reading this.

Future readiness

New Architecture allows your app to leverage Concurrent React features. This improves UI responsiveness, provides Suspense for data fetching to handle complex UI loading schemes, and ensures your app is ready for any further React innovations built on top of its new concurrent engine introduced in React 18.

Let’s see how we can leverage React18’s startTransition API to prioritize between two state updates. In our example, a button click can be considered an urgent update, whereas the NonUrgentUI can be considered a non-urgent update. To tell React about a non-urgent update, we can wrap the setState in the startTransition API. This allows React to prepare a new UI and show the old UI until a new one is prepared.

In our example, we wrapped setNonUrgentValue in start-Transition and told React that nonUrgentValue is a transition and not so urgent, it may take some time. We’ve also added a conditional backgroundColor. When you run this example, you will see that once you click on the button, the view will retain its old UI, e.g., if we start at value 1, the UI will be green.

Once you click on the button, the Value text UI will be updated, but the UI for the container will remain green until the transition is completed, and the color will change to red due to the new UI being rendered. That’s the magic of React’s concurrent rendering.

To understand it better, assume that wrapping an update in startTransition renders it in a different universe. We don’t see that universe directly, but we can get a signal from it using the isPending variable returned from the useTransition hook. Once the new UI is ready, both universes merge together to show the final UI.

import React from "react";
import { Button, StyleSheet, Text, View } from "react-native";
const dummyData = Array(10000).fill(1);
const NonUrgentUI = ({ value, isPending }) => {
  const backgroundStyle = {
    backgroundColor: value % 2 === 0 ? "red" : "green",
  };
  return (
    <View>
      <Text>Non urgent update value: {isPending ? "PENDING" : value}</Text>
      <View style={[styles.container, backgroundStyle]}>
        {dummyData.map((_, index) => (
          <View key={index} style={styles.item} />
        ))}
      </View>
    </View>
  );
};
const ConcurrentStartTransition = () => {
  const [value, setValue] = React.useState(1);
  const [nonUrgentValue, setNonUrgentValue] = React.useState(1);
  const [isPending, startTransition] = React.useTransition();
  const handleClick = () => {
    const newValue = value + 1;
    setValue(newValue);
    startTransition(() => {
      setNonUrgentValue(newValue);
    });
  };
  return (
    <View>
      <Button onPress={handleClick} title="Increment value" />
      <Text>Value: {value}</Text>
      <NonUrgentUI value={nonUrgentValue} isPending={isPending} />
    </View>
  );
};
export default ConcurrentStartTransition;
const styles = StyleSheet.create({
  container: {
    flexDirection: "row",
    flexWrap: "wrap",
  },
  item: {
    width: 10,
    height: 10,
  },
});

Show the final UI.tsx hosted with ❤ by GitHub

To understand it better, let’s visualize the code snippet we just went through. The image below shows a comparison of when we use startTransition and when we don’t. Looking at the image, we see that React flushes the urgent update right off, which happens due to calling setValue without wrapping it in startTransition.

Next, we see that React shows the old UI (viewed in green) for the UI that depends on the nonurgent updates, which means the updates that are wrapped in startTransition. We also see a Pending text displayed; this is a way for React18 to tell us that the new UI depending on this state is not yet ready. Once it’s ready, React flushes it and we don’t see the Pending text anymore, and the view color changes to red.

On the other hand, if we don’t use startTransition, React tries to handle both updates as urgent and flushes once both are ready. This certainly has a few downsides, such as the app trying to render some heavy UI all at once, which may cause jarring effects for the users. With React18, we can handle this by delaying the updates that are not urgent.

There are some other noticeable features in React18 that you might want to check out by playing with the linked sandboxes from React’s official website. See useDeferredValue and startTransition with Suspense.

Maintenance & Support

The React Native core team is committed to offer support for the 3 latest versions of React Native (you can check the support policy here) and the React core team plans new features built on the concurrent rendering engine. It’s important to not stay behind, as the cost of paying the tech debt, will get higher in time. It’s worth calling out that React Native is no different to any other software project in this regard. Not updating dependencies may not only cause your team to spend more time on this task when it’s unavoidable. It can also expose your app to security vulnerabilities already patched in the upstream.

The React Native team has dedicated capacity to help the community solve their app and library problems regarding new architecture adoption in close cooperation. Although it’s not stable yet, it’s worth considering starting to plan your migration early on, so you can identify the problems and blockers that your app may be facing. 2023 is the best time to try it, evaluate, ask for support, and give feedback.

You can get a head start with fine support from the React Native core engineers in solving your app’s build and runtime issues preventing you from migration. Once the new architecture gets stable and turned on by default, the core team will surely focus on the further development of React Native, and hence the migration support time will be reduced.

Need help with performance? Give us a shout!

If you’re struggling with improving your app performance, get in touch with us. Our React Native development company is an official Meta partner and community leader. We’ve delivered high-quality solutions for dozens of international clients, from startups to enterprises, and created some cool Open Source projects like Re.Pack or Reassure. Now’s the time we help your business grow.

This article was originally published at callstack.com on February 14, 2023.

Experiment With the New Architecture of React Native was originally published in Callstack Engineers on Medium, where people are continuing the conversation by highlighting and responding to this story.

The following article is part of The Ultimate Guide to React Native Optimization and explains how you can optimize your React Native app’s performance using different bundlers, like Re.Pack, `react-native-esbuild,` and `rnx-kit.`

Why is this important?

React Native application’s logic is mostly located in the JavaScript code, which runs in the JavaScript engine (JavaScriptCore or Hermes). But before loading JavaScript code into the app, it should be bundled, usually into a single JS file or sometimes to multiple files. React Native provides a built-in tool for JavaScript code bundling called Metro. Sometimes, though, the final bundle becomes too large — and that’s where performance issues begin.

In other blog posts based on The Ultimate Guide to React Native Optimization, we touch on the following topics related to improving performance through understanding the React Native implementation details:

• Picking the right external libraries for your app
• Optimizing battery drain with mobile-dedicated libraries
• Finding the balance between native and JavaScript
• Animating at 60FPS
• Improving React Native performance with high-order components

Be sure to check them out later. Now, let’s move on to the topic of optimizing your React Native app’s JavaScript bundle.

Using alternative bundlers to optimize performance

Metro takes in an entry file and various options and gives you back a single JavaScript file that includes all your code and its dependencies, also known as a JavaScript bundle. According to official docs, Metro speeds up builds using a local cache of transformed modules out-of-the-box.

Metro trades configurability for performance, whereas other bundles like Webpack are the other way around. So when your project needs custom loaders, use symlinks or the proven Webpack configuration for bundling JavaScript code and splitting app logic.

There are a few alternative bundlers that could be used in React Native apps and provide more configuration features. In this article, we’ll take a closer look at Re.Pack, `react-native-esbuild,` and `rnx-kit` and consider their benefits and limitations.

Re.Pack

Re.Pack is a Webpack-based toolkit to build your React Native application with full support of the Webpack ecosystem of loaders, plugins, and support for various features like symlinks, aliases, code splitting, etc. It is the successor to Haul, which served a similar purpose but balanced a different set of tradeoffs and developer experience. By the way, we’re proud to say that Re.Pack it brought to you by our React Native development company — and we put in every effort to make it as valuable and developer-friendly as possible.

Benefits of using Re-Pack in your React Native project

The ecosystem part of Webpack is crucial for many developers, since it’s the most popular bundler on the web, making the community behind loaders and plugins its key advantage. Thanks to that pluggability, it provides ways to improve the build process and Webpack’s overall performance. At least for the parts that are not connected to the internal module graph building and processing. Such parts would be, e.g., JavaScript and TypeScript transpilation or code minification. You can replace Babel transpiler and Terser minifier with faster alternatives like ESBuild thanks to the esbuild-loader or swc with swc-loader.

Another Webpack feature that helps our apps achieve better performance is reducing the amount of code in the final bundle with tree shaking. Tree shaking is a dead code elimination technique done by analyzing the import and export statements in the source code and determining which code is actually used by the application. Webpack will remove unused code from the final bundle, resulting in a smaller and more efficient application. The code that’s eligible for tree shaking needs to be written in ECMAScript modules (import and export statements) and mark itself as side-effect free through `package.json sideEffects: false` clause.

The very first issue on Metro bundler’s GitHub is about symlink support. It remains open today, as there are various reasons Metro is blocked from introducing this functionality with the desired DX. There are ways to mitigate that particular shortcoming, but they require extra configuration. Webpack, on the other hand, as virtually any other bundler, and doesn’t have this issue. Re.Pack uses the Webpack bundler under the hood, so it provides symlinks functionality out-of-the-box, which could be invaluable from the developer experience point of view of some workflows like monorepos.

Re.Pack also offers the ability to use asynchronous chunks to split your bundle into multiple files and load them on-demand, which can improve initial loading times if you’re using the JavaScriptCore engine. However, it won’t provide that much value when used with Hermes, which leverages the memory mapping technique for dynamic reading only the necessary parts of the bundle’s bytecode directly from the RAM. But there’s a twist to that! Webpack doesn’t really care whether you load the dynamic chunk from the filesystem or remote. Hence, it allows for dynamic loading code that’s never been there in the app bundle in the first place, directly from a remote server or a CDN. Now, this can help you with reducing not only the initial load time, but also the precious app size.

On top of that, Webpack 5 introduced support for the concept of Module Federation. It’s a functionality that allows code-splitting and sharing the split code parts (or chunks) between independent applications.

It also helps distributed and independent teams to ship large applications faster. Giving them the freedom to choose any UI framework they like and deploy independently while still sharing the same build infrastructure. Re.Pack 3 supports this functionality out-of-the-box.

Where Metro works out better than Re.Pack

All these configurations and flexibility affect the build process. The build speed is a little bit longer than the default Metro bundler due to customization options. Also, the Fast Refresh functionality is limited compared to the Metro bundler. The Hot Module Replacement and React Refresh features require the full application to be reloaded with Webpack and Re.Pack, but they are supported by Metro.

If you don’t need the huge customization that the Webpack ecosystem offers or don’t plan to split your app code, then you may as well keep the default Metro bundler.

react-native-esbuild

The next bundler that can help you optimize your React Native app’s performance is react-native-esbuild, which comes with speed, tree shaking, compatibility, and configurability. Let’s take a closer look at this tool.

Why it’s worth considering react-native-esbuild for your React Native project

One of the main benefits of react-native-esbuild is fast builds. It uses the ESBuild bundler under the hood, which greatly improves bundling performance even without caching. It also provides some features like tree shaking and is much more configurable compared to the Metro bundler.

ESBuild has its own ecosystem with plugins, custom transformers, and env variables. This loader is enabled by default for `.ts,` `.tsx,` `.mts,` and `.cts` files, which means ESBuild has built-in support for parsing TypeScript syntax and discarding the type annotations. However, ESBuild does not do any type checking, so you will still need to run type check in parallel with ESBuild to check types. This is not something ESBuild does itself.

The drawbacks of react-native-esbuild

Unfortunately, `react-native-esbuild` has some tradeoffs, so it is very important to select the right bundler by paying attention to them as well. It doesn’t support Hermes, which could be a crucial point for some projects. And it does not have Fast Refresh or Hot Module Replacement, but this library supports live reload instead.

rnx-kit

Last but not least, we’d like to discuss Microsoft’s rnx-kit. It’s an interesting extension to Metro. `rnx-kit` is a package with a huge variety of scalable React Native development tools. It also has a custom bundler that works on top of the Metro bundler, enhancing it.

The pros of enhancing Metro with rnx-kit

As you already know, Metro does not support symlinks. `rnx-kit` provides the ability to fully work with symlinks. One more benefit compared to Metro is the tree shaking functionality out-of-the-box.

Metro supports TypeScript source files, but it only transpiles them to JavaScript. Metro does not do any type-checking. `rnx-kit` solves this problem. Through the configuration, you can enable type-checking. Warnings and errors from TypeScript appear on the console.

Also, `rnx-kit` provides duplicate dependencies and cyclic dependencies detection out-of-the-box. This could be very useful in reducing the size of the bundle, which leads to better performance and prevents cyclic dependencies issues.

Ship less JavaScript to users and save devs’ time when bundling

The choice of a bundle tool depends on the specific case. It is impossible to select only one bundler for all the apps. If you need customization options provided by the Webpack ecosystem or plan to split your app code, then we would suggest using Re.Pack for its widely customizable configuration, a huge amount of loaders, plugins maintained by the community, and a lot of features like symlinks, aliases, etc. compared to other bundle tools.

If the Webpack ecosystem feels overhead, then it is better to stay with the default Metro bundler or try to use other bundler options like `react-native-esbuild` and `rnx-kit,` which also provides some benefits like decreased build time, using esbuild under the hood, symlinks, and typescript support out-of-the-box. But be careful and always pay attention to the tradeoffs that come with a new bundling system.‍

If you need help with performance, stability, user experience, or other complex issues, contact us! As React Native Core Contributors and active Open Source contributors, we will be happy to help.

This article was originally published at callstack.com on February 13, 2023.

Optimize Your React Native App’s JavaScript Bundle was originally published in Callstack Engineers on Medium, where people are continuing the conversation by highlighting and responding to this story.

The following article is a part of The Ultimate Guide to React Native Optimization and describes React Native profiling on iOS and Android.

Why is this important?

With users becoming more sensitive to delays, even a 0.1 sec of improvement can increase your conversion rate by 10.1%. That’s why profiling has become one of the main steps in our development life cycle. Using the right profiling tools allows for spotting the source of performance problems and makes it easier to find a solution that actually makes a difference — and satisfied users mean better business results.

In other blog posts based on The Ultimate Guide to React Native Optimization, we touch on the following stability-related topics:

• The role of Continuous Integration (CI) in improving React Native apps
• Over-The-Air (OTA) updates
• Shipping Fast with Continuous Deployment
• Making your app consistently fast with DMAIC and Reassure

Check them out later, and now let’s jump into the ins and outs of React Native profiling with native tools for iOS and Android.

Profiling iOS

Profiling is essential to understanding the runtime performance of the app through analysis that measures the memory or time complexity, frequency, and duration of function calls, etc. Getting all this information helps you to track down and provide proper solutions to keep your app healthy and your users engaged.

Xcode provides some basic tools to do the first report. You can monitor the CPU, Memory, and Network.

CPU Monitor measures the amount of work done. Memory Monitor is for observing the use of the app. All iOS devices use SSD for permanent storage, accessing this data is slower compared to RAM. Disk Monitor is for understanding your app’s disk-writing performance. Network Monitor analyzes your iOS app’s TCP/IP and UDP/IP connections. You can tap on each of them to find more information.

It also provides an extra monitor that isn’t shown by default but can help you inspect your UI — it’s the View Hierarchy. When the app is running, and you are on the screen you want to inspect, click on Debug View Hierarchy.

This will show your current UI in a 2D/3D model and the view tree.

This will help you to detect overlappings (you can’t see a component) or if you want to flatten your component tree. Even though RN does a view flattening, it sometimes can’t do it with all of them, so here we can do some optimization focusing on specific items.

Let’s say we have a TODO list app, and when the Add button is pressed, it adds the new item to the list. However, it takes a couple of seconds to show up on the list because there is some logic before the item is added. Let’s go to our dev toolbox and pick up our first instrument, so we can confirm and measure the delay.

Profiling and debugging React Native app with iOS Instruments

Instruments is a debugging and profiling tool that comes prepackaged with Xcode and is literally a box of tools, each serving a different purpose. You choose from a list of templates, and you choose any of them depending on your goal: improving performance or battery life or fixing a memory problem.

We are going to use Time Profiler. Let’s dive into it. With Xcode open, we go to Open Developer Tool -> Instruments. Then, scroll down to find the Time Profiler tool.

It will open a new window. To start profiling your app, click on the drop-down menu and select your device and the app.

When the app opens, start using it normally, or in this case, add a new TODO item.

After playing around and adding the new TODO item, we can see there is a big blue rectangle, which means there is something that is taking a lot of time to finish. Let’s take a look at the threads.

You can expand by pressing option+click over the chevron, which will expand to display useful information. At least for now, it is showing the memory address, but we will need to find another way to find where the problem is.

Combining with a tool specific for JS Context tracking

Let’s use Flipper and pair it with a monitor called Hermes Debugger (RN). With the app open and running, we go to Flipper, select the running app if not selected already, and go to Hermes Debugger (RN) -> Profiler

We click start, so the profiler begins. We do the same flow and actions as before when profiling with Time Profiler. When we stop, we will see all the data collected.

By default, the data will be sorted bottom-up with the heavy tasks at the top. We can see that a function called doFib is taking ~14 sec to complete, it is a good start, let’s go into that function and see what we can do. The fixes will vary depending on your code.

After applying a possible fix, we first check Time Profiler again. We click on the record button and start using the app; in our case, let’s add a new TODO item.

As we can see, the fix we applied did work, we aren’t seeing the big blue rectangle like before. This is a good sign. Let’s continue with our profiling path to check how it looks in Flipper.

Start profiling the app one more time using Hermes Debugger (RN) -> Profiler.

We don’t see the doFib function anymore, only other expected RN tasks.

Profiling Android

In the event of any performance issues, we mostly use React Profiler to troubleshoot and resolve our problems. Since most of the performance problems originate from the JS realm, we don’t usually need to do anything beyond that. But sometimes, we’ll encounter a bug or performance issue that comes directly from the Android runtime. In such a case, we’ll need a fine profiling tool to help us gather the following metrics from the device:

• CPU
• memory
• network
• battery usage

Based on that data, we can check whether our app consumes more energy than usual or, in some cases, uses more CPU power than it should. It is useful especially to check the executed code on lower-end (LE) Android devices. Some algorithms can run faster on some devices, and the end user will not spot any glitches, but we have to remember some customers can use LE devices, and the algorithm or function can be too heavy for their phones. High-end devices will handle it because their hardware is powerful.

Profiling your React Native app with Android Profiler in Android Studio

Android Studio is the IDE developed by JetBrains. It is officially supported by Google and the official IDE, which can be used to develop any Android app. It is very powerful and contains lots of functionalities in one place. One of those tools is Android Profiler, which, as the name suggests, comes in handy if you’re in need of React Native profiling on Android.

If you have not installed Android Studio yet, you can install it using this link.

To open the Profiler, choose View > Tool Windows > Profiler from the Android Studio menu bar:

Or click Profile in the toolbar.

Before you start profiling the app, please remember:

• Run the app on an actual Android device that is affected, preferably a lower-end phone or emulator if you don’t have one. If your app has runtime monitoring set up, use a model that is either the most used by users or the one that’s affected by a particular issue.
• Turn off development mode. You must be sure that the app uses a JS bundle instead of the metro server, which provides that bundle. To turn it off, please share your device, click on Settings and find JS Dev Mode:

After that, go to the Profiler tab and add a new profiler session:

Wait for the session to attach to your app and start performing actions that could cause some performance issues, like swiping, scrolling, navigating, etc. Once you’re done, you should see some metrics like these:

Each greenfield React Native app has only one Android Activity. If your app has more than one, it’s most likely a brownfield one. Read more about the brownfield approach here. In the above example, we don’t see anything interesting. Everything works fine without any glitches. Let’s check each metric:

• The CPU metric is strictly correlated to energy consumption because the CPU needs more energy to do some computations.
• The memory metric is not changing while using the app, which is expected. Memory usage can grow, e.g., when opening new screens, and drop when the garbage collector (GC) releases free memory, e.g., when navigating out of a screen. When memory increases unexpectedly and keeps on growing, it may indicate a memory leak, which we want to avoid, as it can crash the app with out-of-memory (OOM) errors.
• The network section has been moved to a separate tool called the Network Tab. In most cases, this metric is not needed, because it is mostly related to the backend infrastructure. If you would like to profile a network connection, you can find more information here.
• The energy section gives hints on when our app’s energy usage is low, medium, or high, impacting the daily experience of using the app.

Use Android Profiler in action

In the previous example, we could see some relations between each metric:

To see a more detailed view, we have to double-click on the tab. Now we can see more details. When the user started to do some touch action (swiping in the above example), we could see more CPU work. Each app will have its own signature of CPU spikes and lows. It’s important to build an intuition about it, by interacting with it and pairing certain activities, like touch events, with the increased usage. In other words, some spikes are expected, because the work needs to be done. The problem starts when CPU usage is very high for extended periods or in unexpected places.

Let’s imagine you would like to pick the best list or scroll view component for your React Native app, which has the best performance on a lower-end device. You noticed the current solutions could be revamped or improved, and you started working on this. In your experiment, you would like to check how your solution works for LE devices using the above-described solution. When you double-clicked on CPU, you could spot the below data:

Here you can see the mqt_js thread is used almost all the time and does some heavy computation because your computations are done on the JS side. You can start thinking about how to improve it. There are multiple options to check:

• Replace the bridge with JSI in terms of communication — do tests if JSI is faster than the bridge.
• Move some part of the code to the native side — on the native side you have more control over threads execution and can schedule some work to not block the JS or UI thread.
• Use a different native component — replace the native scroll view with your custom solution.
• Use shadow nodes — do some expensive calculation with C++ and pass it to the native side.

You can try out all of those solutions and compare the effect between each other. The profiler will provide you with a metric, and based on that, you can decide which approach fits best to your particular problem.

There’s more info about the Android Profiler here.

System Tracing with Android Studio CPU Profiler

Using the Android Studio CPU Profiler, we can also make a system tracing. We can check when the appropriate function has been called. We can triage all threads and see which function is the costliest, which affects the UX. To enable system tracing, click on the CPU section and select System Trace Recording.

After some interaction, you should be able to see all the threads with details:

You can also save your data by clicking the Save Button:

And use the data in a different tool, e.g., Perfetto:

You’ll also want to check the official Android Profiling guide by the React Native core team. They use different tools, but the outcome will be the same. The guide provides case studies and how to spot an issue on different threads:

• UI thread
• JS thread
• Native module thread
• Render Thread (only Android)

You can find more about threading models in the New Architecture blog post.

Flipper performance plugin for Android

We already know Flipper can be quite handy in hunting performance issues. One of the most interesting plugins to help us out on Android is android-performance-profiler. It can be used as a standalone tool or on a CI. It can generate beautiful reports, so this tool can be used to do some sophisticated experiments.

Here is a picture of an example experiment:

Comparison of the new vs. old architecture of React Native by Almouro. Source.

You can also automate your experiments with e2e tests and generate reports locally or on a CI. Those reports can be used to compare solutions with each other.

Profiling improves your app understanding

70% of users will leave your app if the response to a given action takes too long. And once they do, they aren’t likely to return ever again, which can seriously harm your business. For that reason alone, profiling your React Native application with native tools for iOS and Android may turn out a game changer — for both your organization and your user base.

In this article, we’ve shown how to profile your app with tools like Instruments, Flipper, and Hermes Debugger for iOS, and Android Profiler and Flipper for Android. If you need help with tracking down and solving your performance issues, drop our React Native development company a line — our senior devs will surely know how to help.

This article was originally published at callstack.com on February 15, 2023.

Profiling React Native Apps With iOS and Android Tools was originally published in Callstack Engineers on Medium, where people are continuing the conversation by highlighting and responding to this story.

The following article is part of The Ultimate Guide to React Native Optimization and explains how the DMAIC process and tools like Reassure can help keep your app performant over time.

Why is this important?

You want your React Native app to perform well and fast at all times to keep the user experience optimal. That’s impossible unless you make performance regression monitoring a part of your app development and maintenance process. In this article, we explain how the DMAIC process can help your React Native team consistently improve app performance. We also look at the tools you can use to ensure your app remains performant as it grows, mainly Reassure.

In other blog posts based on The Ultimate Guide to React Native Optimization, we touch on the following stability-related topics:

• Continuous Integration (CI) in improving React Native apps
• Over-The-Air (OTA) updates
• Shipping Fast with Continuous Deployment
• Running tests for key pieces of your app
• Profiling React Native apps with iOS and Android tools

Why should you keep improving app performance?

Customers have very little patience for slow apps. According to the Unbounce report, nearly 70% of consumers admit that page speed influences their willingness to buy. Good examples here are Walmart and Amazon — both of these companies noticed an increase in revenue by up to 1% for every 100 milliseconds of load time improvement.

Performance has a noticeable impact on your business goals, yet it’s often the case that after fixing one performance issue, the app sooner or later gets slow again. As such a scenario can take a toll on your organization, you need to not only fix performance issues, but also make sure they don’t happen again.

Use DMAIC process to consistently improve React Native app performance

You want your React Native app to perform well and fast at all times, but how do you achieve this goal? From the technical perspective, it boils down to avoiding guesswork and making data-informed decisions. We should also remember that improving performance is a process; it’s impossible to fix everything at once, but small steps can provide big results.

Developing an app is a process, and so is performance improvement. Most important, though, every process can be optimized. In the case of improving React Native app performance and performance regression monitoring, one of the most effective ways of doing so is following the DMAIC methodology. It’s a very data-driven and well-structured approach comprising the following steps: Define, Measure, Analyze, Improve, and Control. Let’s see how we can apply each phase in our apps.

Define

In this phase of the DMAIC process, we should focus on defining the problem, what we want to achieve, opportunities for improvement, etc. Listening to the customers’ expectations and feedback in this phase is essential, as it helps better understand their needs, preferences, and problems.

Next, it is very important to measure it somehow. Let’s say the customer wants a fast checkout. After analyzing the components, we know that we need a swift checkout process, a short wait time, and smooth animations and transitions to achieve this. All of these points can be decomposed into measurable CTQs (Critical-to-Quality). For example, a short wait time can be decomposed into a quick server response and a low number of server errors. Another handy tool is analyzing common user paths. With good tracking, we can understand what parts of the app are mostly used by the users.

Choosing priorities and defining the order in which we will optimize things should conclude this phase. Any tools and techniques for prioritizing will definitely help here. If you want to improve app performance efficiently, setting measurable goals and putting them in the project scope should be your go-to’s at this stage.

Measure

Since we already know our direction, it’s time to assess the starting point. It’s all about collecting as much data as possible to get the actual picture of the problem. We need to ensure the measurement process is precise. Creating a data collection plan and engaging the development team to build the metrics is really helpful. Then, it’s time to do some profiling.

When profiling in React Native, the main question is whether to do this on JavaScript or the native side. It heavily depends on the app’s architecture, but most of the time, it’s a mix of both. One of the most popular tools is React Profiler, which allows us to wrap a component to measure the render time and the number of renders. It’s very helpful because many performance issues come from unnecessary rerenders.

Discover how to use it here:

import React, { Profiler } from "react";
import { View } from "react-native";

const Component = () => (
  <Profiler id="Component" onRender={(...args) => console.log(args)}>
    <View />
  </Profiler>
);

export default Component;

Using React Profiler API.tsx hosted with ❤ by GitHub

It will output the data:

{
  id: "Component",
  phase: "mount",
  actualDuration: 1.3352311453,
  baseDuration: 0.95232323318,
  ...
}

Output of the React Profiler API.tsx hosted with ❤ by GitHub

The second tool is a library created by Shopify called React Native Performance. It allows you to place some markers in the code and measure the execution time. There is also a pretty nice Flipper plugin that helps to visualize the output:

Speaking of Flipper, it has some more plugins that help us to measure the app performance and speed up the development process. We can use React Native Performance Monitor Plugin for a Lighthouse-like experience or React Native Performance Lists Profiler Plugin.

On the native side, the most common method is using Native IDEs: Xcode and Android Studio. There are plenty of useful insights which can be analyzed and lead to some conclusions and results.

The most important aspect of the measure phase is measurement variation. Due to different environments, we have to be very careful when profiling. Even if the app is run on the same device, some external factors might affect performance measurements. That’s why we should base all the measurements on release builds.

Analyze

This phase of the DMAIC process aims to find the root cause of our problem. It’s a good idea to start with a list of things that could potentially cause the issue. A little brainstorming with a team can be helpful here.

One of the most popular tools to define a problem is called a cause and effect diagram. It looks like a fish, and we should draw it from right to left. We start from the head that contains the problem statement (we should already have it based on the define phase). Then, we identify all the potential major causes of the problem and assign them to the fish bones. Next, we assign all the possible causes to each major cause. Since there are many things that can impact app performance, it’s important to narrow our list down. Try to outline and focus on the most important factors.

Finally, it’s time to test the hypothesis. For example, if the main problem is low FPS, and the potential major cause is related to list rendering, we can think of some improvements in the area of images in the list items. We need to design a test that will help us accept or reject the hypothesis — it will probably be some kind of proof of concept. Next, we interpret the results and assess whether it improves our React Native app performance or not. Then, we make a final decision.

Improve

Now that we know our goal and how we want to achieve it, it’s time to actually improve your app performance. Before starting, it’s a good idea to hold another brainstorming session and identify potential solutions. Depending on the root cause, there might be a lot of them. Based on the last example with images on the list item, we can think about implementing proper image caching and reducing unnecessary renders.

After outlining the solutions, it’s time to pick the best one. Sometimes the solution that gives the best effects might be extremely costly, e.g., when it involves architectural changes. Once you implement the solution, don’t forget to test it properly!

Control

The last step in the DMAIC process is the control phase. We need to make sure that everything works well now. As you know by now, app performance will degrade if it is not under control. People tend to blame devices, technology, or even users for it, but it’s not that simple. So what do we need to do to keep the performance of our React Native app on a high level?

We need to make sure that we have a control plan. We can use some of our work from the previous phases to make it. We should point out focal points, some measurement characteristics, acceptable ranges for indicators, and testing frequency. Additionally, it is a good practice to write down some procedures and what to do if we spot issues.

Performance regression monitoring as a part of the development process

The most important aspect of the control phase is monitoring regressions. Until recently, it was quite difficult to do that effectively in React Native, but now we have plenty of options to improve our monitoring.

One way to keep track of the performance improvements we introduce in our apps is through real-time monitoring tools like Firebase Performance Monitoring or Sentry Performance Monitoring.

Another way to implement performance regression monitoring is through automated testing, which we’d like to explore in greater detail. Profiling, measuring, and running on various devices is a manual and time-consuming job that developers avoid doing. However, it gets too easy to unintentionally introduce performance regressions that would only get caught during QA, or worse, by your users. Thankfully, we can write automated performance regression tests in JavaScript for React and React Native with Reassure.

Reassure allows you to automate React Native app performance regression testing on CI or a local machine. Just like you write your integration and unit tests that automatically verify that your app is still working correctly, you can write performance tests that verify that your app is still performant. You can think about it as a React performance testing library. In fact, Reassure is designed to reuse as much of your React Native Testing Library tests and setup as possible as it’s designed by its maintainers and creators.

It works by measuring certain characteristics — render duration and render count — of the testing scenario you provide and comparing that to the stable version measured beforehand. It repeats the scenario multiple times to reduce the impact of random variations in render times caused by the runtime environment. Then it applies a statistical analysis to figure out whether the code changes are statistically significant or not. As a result, it generates a human-readable report summarizing the results and displays it on CI or as a comment to your pull request.

The simplest test you can write would look something like this:

import React from "react";
import { View } from "react-native";
import { measurePerformance } from "reassure";

const Component = () => {
  return <View />;
};

test("mounts Component", async () => {
  await measurePerformance(<Component />);
});

Testing rented times of Component during mounting.tsx hosted with ❤ by GitHub

This test will measure the render times of Component during mounting and the resulting sync effects. Let’s take a look at a more complex example, though. Here we have a component that has a counter and a slow list component:

import React from "react";
import { Pressable, Text, View } from "react-native";
import { SlowList } from "./SlowList";

const AsyncComponent = () => {
  const [count, setCount] = React.useState(0);

  const handlePress = () => {
    setTimeout(() => setCount((c) => c + 1), 10);
  };

  return (
    <View>
      <Pressable accessibilityRole="button" onPress={handlePress}>
        <Text>Action</Text>
      </Pressable>

      <Text>Count: {count}</Text>

      <SlowList count={200} />
    </View>
  );
};

Component with a counter & slow list component.tsx hosted with ❤ by GitHub

And the performance test looks as follows:

import React from "react";
import { screen, fireEvent } from "@testing-library/react-native";
import { measurePerformance } from "reassure";
import { AsyncComponent } from "../AsyncComponent";
test("AsyncComponent", async () => {
  const scenario = async () => {
    const button = screen.getByText("Action");

    fireEvent.press(button);
    await screen.findByText("Count: 1");

    fireEvent.press(button);
    await screen.findByText("Count: 2");

    fireEvent.press(button);
    fireEvent.press(button);
    fireEvent.press(button);
    await screen.findByText("Count: 5");
  };

  await measurePerformance(<AsyncComponent />, { scenario });
});

Test for component with counter & slow list components.tsx hosted with ❤ by GitHub

When run through its CLI, Reassure will generate a performance comparison report. It’s important to note that to get a diff of measurements, we need to run it twice. The first time with a `— — baseline flag`, which collects the measurements under the `.reassure/ directory`.

After running this command, we can start optimizing our code and see how it affects the performance of our component. Normally, we would keep the baseline measurement and wait for performance regressions to be caught and reported by Reassure. In this case, we’ll skip that step and jump straight into optimizing because we just noticed a nice possibility to do so. And since we have our baseline measurement for reference, we can actually verify our assumptions and whether the improvement was objective or only subjective.

The possibility we noticed is that the `<SlowList/>` component can be memoized, as it doesn’t depend on any external variables. We can leverage `useMemo` for that case:

const slowList = useMemo(() => <SlowList count={200} />, []);

Slowlist memoized.tsx hosted with ❤ by GitHub

Once we’re done, we can run Reassure a second time. Now without the ` — — baseline flag`.

Now that Reassure has two test runs to compare — the current and the baseline — it can prepare a performance comparison report. As you can notice, thanks to applying memoization to the `SlowList` component rendered by `AsyncComponent`, the render duration went from 78.4 ms to 26.3 ms, which is roughly a 66% performance improvement.

Test results are assigned to certain categories:

• Significant Changes To Render Duration shows a test scenario where the change is statistically significant and should be looked into as it marks a potential performance loss/improvement.
• Meaningless Changes To Render Duration shows test scenarios where the change is not statistically significant.
• Changes To Render Count shows test scenarios where the render count did change.
• Added Scenarios shows test scenarios that do not exist in the baseline measurements.
• Removed Scenarios shows test scenarios that do not exist in the current measurements.

When connected with Danger JS, Reassure can output this report as a GitHub comment, which helps catch the regressions during code review.

You can discover more use cases and examples in the docs.

DMAIC process and performance regression monitoring help make your React Native app consistently fast

When working on an app, regardless of its size, it’s essential to have a clear path for reaching our goals. The main benefit of using DMAIC methodology when optimizing React Native applications is a structured and direct approach. Without it, verifying what works (and why) may be difficult. Sometimes our experience and intuition are just enough. But that’s not always the case.

Making a process like this a part of React Native development allows us to focus on problem-solving and constantly increase productivity. Thanks to the DMAIC approach, performance optimization becomes a part of your normal development workflow. It brings your React Native app closer to being performant by default and allows spotting performance issues even before they hit your users.

No software is flawless. Bugs and performance issues will happen even if you’re the most experienced developer on the team. But we can take action to mitigate those risks by using automated tools like Sentry, Firebase, or Reassure. Use them in your project to enjoy the additional confidence they bring to your projects and the improved UX they deliver to your users.

If you’re looking for a tech partner who can improve the performance of your application in a well-thought-out process, contact us.

This article was originally published at callstack.com on February 8, 2023.

Consistently Improve App Performance With DMAIC and Reassure was originally published in Callstack Engineers on Medium, where people are continuing the conversation by highlighting and responding to this story.

by Luke Walczak

React Native Paper 5.0 is out! We have been working on the new version of React Native Paper for some time, and finally, the team can present the results of their work.

What’s new in React Native Paper 5.0?

Before reading the article, take a look at React Native Paper demo I prepared, where I show how the new version of the library works.

React Native Paper 5.0 is all about adopting the new Material Design 3, aka Material You, into the library. The new design system generation was released in October 2021 after intense work and effort to make Material You follow a more expressive approach to design.

Version 5.0 brings support for the following Material Design iteration branded as Material You (in fact, Material Design v3 or, in short, MD3) into the `react-native-paper library`. We refined all components according to the official design kit on Figma and adjusted in terms of visuals by changes in colors, typography, and animations.

‍Does it mean that v4 won’t be supported anymore?

Technically that’s true — there will be no more releases of v4. Practically, it’s false since Paper version 5.0 supports Material Design generations 2 and 3. Users can keep their existing design with the latest Paper release.

You can think about React Native Paper v5 as an extended and modified (mainly in terms of theming and typography related to Material You) v4.

Introducing Material You (MD3) into `react-native-paper` doesn’t mean dropping previous Material Design (MD2)! On the contrary, both of them will be supported, but not simultaneously.

‍How to establish which version the app should follow?

To specify which design system components should follow in the app, there is a newly created property in the theme called version, which can accept only one of two values:

• 3 — (default) new Material You (MD3),
• 2 — previous Material Design (MD2).

theme: {
 /* … */
 version: 3 | 2
}

react.native.paper.tsx hosted with ❤ by GitHub

Helpers

We meet the needs of library users and help them configure the theme in a smooth and hassle-free way. That’s why we have created new helper functions and adapted existing ones that will help in this process.

adaptNavigationTheme

From React Native Paper 5.0 theme colors structure follows the Material Design 3 colors system, which differs significantly from the previous Paper’s theme and React Navigation theme.

However, to simplify adapting React Navigation theme colors and to use the ones from React Native Paper, we created the `adaptNavigationTheme` helper.

The function accepts navigation-compliant themes in both modes and returns their equivalents adjusted to Material Design 3. The adapted theme can then be passed to `NavigationContainer` so React Navigation’s UI elements match React Native Paper color scheme.

configureFonts

In the latest version, we based the fonts in the theme on the `variant` keys, e.g., `displayLarge` or `bodyMedium`. Each variant defines appropriate text styles for type role and size and can be applied by props into `text` component throughout the whole library.

To make it easier to make theme font changes in terms of modifying individual variants or adding entirely new ones, we adjusted the existing utility called `configureFonts`.

As of today, the function accepts the config object with font modification appropriate to the Material Design version, where the output is an adjusted theme font object.

createDynamicThemeColors (currently not in the library)

Within Paper documentation in the `Theming` section, you can find the tool for generating two color schemes, `lightScheme` and `darkScheme`, based on the provided source color.

Created schemes follow the Material Design 3 color system and cover colors structure from the Paper theme.

Copied color schemes from the generated JSON can be then used by passing them to the colors in the theme object.

New versions means new components

The new version of the React Native Paper comes with new components:

• `SegmentedButtons`
• `Tooltip`
• `Drawer.CollapsedItem`

Let’s take a closer look at each component!

SegmentedButtons

`SegmentedButtons` is a new component introduced in the latest version. However, it can be understood as a refined version of `ToggleButton`.

It allows you to:

• select options,
• switch views, or
• sort elements.

It’s intended to support single and multi-select variants and provide many customization options.

Tooltip

Tooltip is a component displayed upon tapping and holding a screen element or component used to present an informative text label identifying an element, such as a description of its function.

It is one of the components that were missing in the library also in the previous version and, about which there were often questions, so it was high time to introduce it for both Material Design systems!

Drawer.CollapsedItem (Navigation Rail)

`Drawer.CollapsedItem` is a newly created side navigation component that can be used within Drawer, representing a destination in the form of an action item with an icon and optionally label.

React Native Paper 4.0 vs React Native Paper 5.0

Now that we know what’s new in the React Native Paper 5.0, let’s take a closer look at the differences between React Native Paper 4.0 and 5.0.

BottomNavigation (Navigation Bar)

In the latest version, Bottom Navigation is taller and doesn’t have a shadow. Active states are represented with filled icons and a contrasting pill-shaped active indicator, while inactive states are represented with outlined icons.

Appbar (Top App Bar)

According to the Material You, there are now four types of top app bar:

• `center-aligned`
• `small`
• `medium`
• `large`

Each of them has larger default text and height. Similarly to `BottomNavigation` there is no drop shadow by default.

Button

From the perspective of visual changes `Button` received fully rounded corners, taller height and inner text is sentence case. Button is one of the several components which received new variants or modes — three new types were introduced: `elevated`, `filled` and `filled-tonal`.

In terms of naming, we were looking for some compromise, between being consistent with the codebase and MD that’s why:

• since the `filled` type replaced what was previously known as a `contained` button, we decided to stick to that naming, and filled is still named `contained`,
• accordingly, `filled-tonal` received the name `contained-tonal`.

Migration guide

To ease the transition to the new version, we prepared a migration guide to React Native Paper 5.0, covering all of the breaking changes.

Summary

React Native Paper 5.0 offers new versions of new components such as segmented buttons, tooltip, and drawer collapsed item, as well as helpers to make the developers’ experience smoother and more enjoyable. Test it for yourself! And if you have any questions about the library, reach out to us via the official Twitter page for React Native Paper.

This article was originally published at callstack.com on December 6, 2022.

React Native Paper 5.0 — What’s New? was originally published in Callstack Engineers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

This article is a bird’s-eye view of migrating a React Native library to the New Architecture. At first, I wanted to go into the details. However, due to the pace of changes and ever-evolving new patterns, I decided to walk you through the migration steps with the helpful resources I found.

I had the pleasure of working on migrating react-native-slider and also the Android part of react-native-pager-view.

What’s the New Architecture?

If you are following things that happen in the React Native world, I’m sure you heard about the New Architecture, including Fabric and Turbo Modules.

If you are new to the “New Architecture” world, check out Lorenzo’s at React Native Wrocław Meetup this year.

There is also a podcast episode on the New Architecture in which Łukasz Chludziński talks with Nicola Corti, a member of the React Native core team.

What’s Fabric?

Fabric is React Native’s new concurrent rendering system, a conceptual evolution of the legacy render system. It allows for all the features React 18+ brings to the table. Fabric is one of the 4 pillars of the New Architecture that React Native core team is working on since 2018.

Thanks to Fabric, instead of using the bridge which communicated with serialised JSON messages, we can communicate using JSI (second pillar), which is a C++ API for interacting with any JS engine. Ultimately JSI is going to replace the bridge (it’s the “bridgeless” project) but for now they live side by side, which is good because it can speed up your migration when you stumble upon some edge case which is not supported yet.

The third pillar is Turbo Modules. It’s an interface on top of JSI, that leverages Codegen (the last pillar) to generate C++ code from our TypeScript or Flow spec.

If you want to try out the new Architecture in your app make sure to follow this guide.

Steps to migrate a library

1. Writing TypeScript spec for Codegen
2. Migrating deprecated JavaScript APIs
3. Extending react-native-codegen generated interfaces on native platforms (Android / iOS)
4. Done ✅

This may seem like a lot of work but with the documentation getting better and more developers getting involved in the process, it becomes easier every day. It is also worth noting that the first two steps can be done even before migrating to the New Architecture — when preparing your library for migration.

Using an official migration guide for library creators

There is an official migration guide that you can follow: React Native New Architecture Libraries. It has examples creating simple Fabric component and also a Turbo Module. There is also another guide for migrating your whole app for the New Architecture.

These examples really help to get you going with the migration. However, most of the time you will end up browsing the source code of other libraries (at least I did). So another helpful resource is a list of already migrated libraries.

Creating a library from scratch

If you want to create a new library or just scaffold a New Architecture setup for your existing library, you can use react-native-builder-bob which recently received a lot of new features!

Here is a screenshot of scaffolding a new library with create-react-native-library. As you can see, there are new options for Turbo Modules.

We have used it to scaffold the New Architecture inside react-native-pager-view which was way faster than creating all the necessary setup by hand. Fabric support will be added soon, but it may be already there as you are reading the article 😄. So go ahead and give Bob a try!

1. Writing TypeScript spec

Now let’s start with the migration part. The goal of this step is to write a specification of your module which is a set of types written in Flow or TypeScript that defines all the APIs provided by the native module. Using a spec allows CodeGen (code generation tool for React Native) to generate native code for each platform during build time. To find more about it, refer to the docs.

Here is how the generated files look like for Android.

It sounds so good in theory. In reality, however, not everything is working as expected (yet!). Let’s go over a few issues I’ve stumbled upon.

Unsupported props between platforms

As for now CodeGen doesn’t support platform specific specs, so keep in mind that you need to define types for every platform in your spec file. If you have any props that’s not supported on iOS it’s not a problem because you can skip it inside updateProps method:

- (void)updateProps:(const Props::Shared &)props oldProps:(const Props::Shared &)oldProps
{
 const auto &oldScreenProps = *std::static_pointer_cast<const RNCSliderProps>(_props);
 const auto &newScreenProps = *std::static_pointer_cast<const RNCSliderProps>(props);

if (oldScreenProps.step != newScreenProps.step) {
 slider.step = newScreenProps.step;
 }

// Handle only supported props here
}

snippet 1.javascript hosted with ❤ by GitHub

snippet source code

However, Android handles props a little bit differently. It generates setters for all of the props which need to be overwritten.

The best way to tackle this problem is to override those setters with empty functions like here:

// iOS only prop
@Override
public void setVertical(ReactSlider view, boolean value) {}

snippet 2.javascript hosted with ❤ by GitHub

Union types

Typescript union types are not yet supported by Codegen, but we can get around this limitation by using a Codegen helper type named WithDefault<>.

Here is what this “hack” looks like in react-native-pager-view

overScrollMode?: WithDefault<’auto’ | ‘always’ | ‘never’, ‘auto’>;

snippet 3.javascript hosted with ❤ by GitHub

If you ever get stuck, you can go through these resources:

• react-native source code (features a lot of fabric components)
• Working Group for the New Architecture — features a list of already migrated libraries.

It’s also worth mentioning that Meta is working on making Codegen support more advanced.

2. Migrating deprecated APIs

Both projects I’ve worked on haven’t used any of the deprecated APIs. However, one of the most used ones is setNativeProps. It fundamentally breaks the model of the New Architecture leading to skipping all the rendering steps and desynchronising UI between React Native and what’s shown to the user. You can read more about it on github.

If you happen to use one of the APIs from this list though, it should be pretty straightforward to just replace them. You can find helpful resources in the Working Group discussion on the New Architecture.

3. Implementing Codegen generated interfaces on native platforms (Android / iOS)

This step is probably the most time consuming and it depends on the complexity of your library.

Android part is easier since we are having two source sets (newarch / oldarch) which get loaded accordingly to a newArchEnabled flag in build.gradle and then a one SharedImpl file which you can share between implementations.

However, iOS is based on creating a new .mm files which are implementing Codegen generated protocols. Depending on what’s your library doing you may need to create separate implementations for new / old arch or share code between them.

Using Swift

Both of the libraries I’ve worked on haven’t used Swift. But, unfortunately, it’s not officially supported at the moment. The official Meta team statement is that they are “looking into it.” Codegen generates native ObjC++ files (.mm) which are tricky to reference from Swift files.

There is a great twitter thread from Mateusz Mędrek on his experiences.

Mateusz Mędrek on Twitter: "That #reactnative #Fabric & #TurboModules migration was a big pain, especially that I had Kotlin and Swift code to migrate, so it's a big relief to have it done. And there is lots of completely undocumented stuff I wish I knew that would made it a lot easier to migrate pic.twitter.com/CSChN7GJcT / Twitter"

That #reactnative #Fabric & #TurboModules migration was a big pain, especially that I had Kotlin and Swift code to migrate, so it's a big relief to have it done.

Using Kotlin

When we were migrating react-native-pager-view I had lots of build issues which resulted from using Kotlin. Due to mixing Java with Kotlin, Codegen created files which were not included. So we have added a temporary workaround which may be useful in case you are also using Kotlin in your library. Check it out here:

Custom component state with C++

In some use cases Codegen isn’t enough — it’s a good starting point but It wasn’t designed to cover all the edge cases. So if your native component would like to update its frames in a synchronous way, you will need to add custom C++ state.

I haven’t added custom shadow nodes to react-native-slider in C++ yet (it’s scary but it’s on my to do list 😄). We have lots of great developers working on improving the New Architecture here at Callstack. My colleague Piotr Trocki together with Nicola Corti created a sample repository which will help you set this up. Right know the guide only covers Fabric, yet there is already an open issue to support Turbo Modules.

If you are afraid of C++ you can make use of the good old bridge as it’s still being initialized. But keep in mind that one day there will be bridgeless mode added.

Build times

While I was working on migration of react-native-slider we were using react-native 0.69 which had a major flaw in terms of build times. When it was time to create a fresh build without any cache, I could go and make myself a coffee ☕️ and then go for a walk. It took around 15–20 minutes. The good thing is that the community have added an — active-arch-only flag which will decrease your build times even 3x. And the core team is actively working on bringing the build times down by leveraging prebuilt artifacts outside of NPM.

Oskar Kwaśniewski on Twitter: "In the latest nightly version of React Native there is a huge boost in build speed using new arch on Android 🚀🏎️Combined with the `--active-arch-only` flag we went from around 9 minutes to ONLY 3 minutes 👀🔥Try it out yourself with: `yarn android --active-arch-only` pic.twitter.com/ZhgpAHSbeC / Twitter"

In the latest nightly version of React Native there is a huge boost in build speed using new arch on Android 🚀🏎️Combined with the `--active-arch-only` flag we went from around 9 minutes to ONLY 3 minutes 👀🔥Try it out yourself with: `yarn android --active-arch-only` pic.twitter.com/ZhgpAHSbeC

Also keep in mind that you will need a pretty good machine to play around with new architecture. I saw few comments to my tweet indicating that building app (using new architecture) took them around 30 minutes. Of course once the build is cached it will be faster.

4. Now it’s time to release a migrated library

Every migrated library brings us closer and closer to finally enable the New Architecture in the production apps. Meta is using Fabric in their Facebook app since last year, but most of us are probably still blocked by the libraries that don’t have support for the New Architecture yet. If you want to track the status of migration for libraries, there is a dedicated discussion page. And if you are working on migrating your library, also add it there so it will be listed in the React Native Directory as a library that supports the New Architecture.

Try React Native Slider with Fabric

1. Create a new app using React Native CLI: npx react-native init NewArchApp
2. Add a React Native slider yarn add react-native-slider
3. [iOS] Run RCT_NEW_ARCH_ENABLED=1 pod install inside ios folder
4. [Android] Set newArchEnabled=true in gradle.properties

In the New Architecture mode, components that are not yet compatible will show a red box: Unimplemented component: <ComponentName>, and you will likely notice them. In that case, please let the library maintainers know about it.

Here is an example of not yet fabric ready LottieAnimationView:

Summary

Even though the React Native New Architecture is out there for a good while now, it’s still a challenge to do migrations, especially Fabric. The React Native core team put a good amount of work into making this effort easier. There’s a lot new documentation and up-to-date repositories on how to migrate both libraries and apps. And it’s still not enough. We keep finding the gaps in the official docs and often need to dive into the source code and commit history to figure out the rationale behind some API decisions.

Nicola Corti from the core team frequently mentions at conferences and podcasts that now it is the best time for apps to migrate. That’s because now they have a dedicated capacity to help the community solve their app and library problems in a close cooperation. They can’t promise whether they’ll have this capacity in a year from now.

At Callstack, together with my fellow developers, we often took this opportunity to reach out directly to the core team members, be it around the New Architecture’s autolinking, or migrating Slider, PagerView and Bob. And they are always utterly helpful, even though not available on-demand.

Although this may not be the best time for your app to adopt the New Architecture, I strongly encourage you to try. Turn on the build flag, check which components and modules are missing support. Post your problems and findings in a github discussion group. The New Architecture is the biggest thing that has happened to React Native since its inception. Get involved 🙂

This article was originally published at callstack.com on November 3, 2022.

Migrating a React Native Library to the New Architecture was originally published in Callstack Engineers on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is Stripe Identity?

There’s no easier way to verify identities than Stripe Identity. It lets you programmatically confirm the identity of users around the globe by scanning an image of an official form of ID, so you can prevent attacks from fraudsters while minimizing friction for legitimate payments.

Stripe Identity is an open source React Native wrapper for the native Stripe SDKs. The idea is to compare your Face ID with images of you and your IDs by means of biometric technology.

With the Stripe Identity React Native SDK, you can confidently verify the authenticity of ID documents from over 33 countries in your React Native application.

How to use the Stripe Identity React Native SDK

To verify your user’s identity, you need to have a document upload sheet displayed in your application. There are few steps to do that. First of all, you have to install Stripe Identity React Native SDK.

The next step is to set up a server to create a VerificationSession, which is the programmatic representation of the verification. For security reasons, the VerificationSession API is not directly accessible from the mobile client. Instead, your server provides the SDK with an ephemeral key — a short-lived API key with restricted access to the VerificationSession API.

You can think of an ephemeral key as a session authorizing the SDK to retrieve and update a specific VerificationSession object for the duration of the session. After successfully creating a VerificationSession and ephemeral key, send the VerificationSession id and ephemeral key secret to the client to show the document upload sheet.

The third step is to show the “document upload” sheet to the user. With Stripe Identity React Native, you can do this in two ways — via a hook called useStripeIdentity, or a method called presentIdentityVerificationSheet. That depends on whether you want to use it in functional or class-based components.

You can find example code in the repository or integration guide.

Getting started with the useStripeIdentity hook

The easiest way to use the SDK is to import the useStripeIdentity hook directly in a functional component. You should pass the necessary information you fetched from your server directly to the hook.

import React from "react";
import { View, Button, Text, Image } from "react-native";
import { useStripeIdentity } from "@stripe/stripe-identity-react-native";

// brand logo that needs to be passed to Stripe Identity hook
import logo from "./assets/{{YOUR_BRAND_LOGO}}.png";

// simplified example of fetch function for Stripe Identity
// it can be replaced with more robust implementation that handles error handling, analytics, etc.
// other fetching libraries like Axios can be used as a replacement for native fetch()
const fetchVerificationSessionParams = async () => {
 try {
   const data = await fetch(
     `${YOUR_SERVER_BASE_URL}/create-verification-session`,
     {
       method: "POST",
       headers: {
         "Content-Type": "application/json"
       }
     }
   );
   const json = await data.json();
   return json;
 } catch (e) {
   return {};
 }
 };

// options needed to make correct request to Stripe Identity
const fetchOptions = async () => {
 const response = await fetchVerificationSessionParams();
 return {
   sessionId: response.id,
   ephemeralKeySecret: response.ephemeral_key_secret,
   brandLogo: Image.resolveAssetSource(logo)
 };
};

function VerifyScreen() {
 // hook provided by Stripe Identity SDK allows API consumers to get important states and values without too much work from their side.
 const { status, present, loading } = useStripeIdentity(fetchOptions);

return (
   <View>
     <Button title="Verify" disabled={loading} onPress={present} />
     <Text>Status: {status}</Text>
   </View>
 );
}

code snippet 1.javascript hosted with ❤ by GitHub

The hook returns 3 fields: status (FlowCompleted, FlowCanceled, FlowFailed), loading boolean, or error, and a method: present. Use the present method to display a document verification sheet. Clicking the verify button will open a native modal view.

Using the Stripe Identity SDK without hooks

If you use class-based components or prefer to implement the SDK without using hooks in your RN application, you can import an async method called presentIdentityVerificationSheet and prepare your own implementation. You will pass the same parameters as with functional components.

This method returns a status and an optional error.

import React from "react";
import { View, Button, Text } from "react-native";
import { presentIdentityVerificationSheet } from "@stripe/stripe-identity-react-native";

const fetchVerificationSessionParams = async () => {
 //  same implementation as in function component
};

const fetchOptions = async () => {
 //  same implementation as in function component
};

class VerifyScreen extends React.Component {
 constructor(props) {
   super(props);
   this.state = { loading: false, status: undefined, error: undefined };
 }

present = async () => {
   // without provided hooks implementation user has to manage error and loading states manually
   this.setState({ loading: true });
   const options = await fetchOptions();
   this.setState({ loading: false });
   const { status, error } = await presentIdentityVerificationSheet(options);
   this.setState({ status, error });
 };

render() {
   return (
     <View>
       <View>
         {this.state.loading ? (
           <View>
             <Text>Loading...</Text>
           </View>
         ) : (
           <Button title="Verify Identity" onPress={this.present} />
         )}
       </View>
       <Text>Status: {this.state.status}</Text>
     </View>
   );
 }
}

code snippet 2.javascript hosted with ❤ by GitHub

Verifying results

Based on the status (FlowCompleted, FlowCancelled, FlowFails), you’ll need to handle these outcomes in your application. Please refer to the official documentation to read more about setting up a webhook flow.

Error handling

When implementing such a critical feature for your app, it is important to correctly implement error handling and provide users with clear information about the source of the issue and how they should proceed. If the error is on their side, your application should tell the user what to do to fix the problem. If the problem is due to code or server issues, there should be a clear message saying it.

Stripe Identity SDK provides a number of statuses and messages that can be used to create robust error handling implementation in your application.

Both useStripeIdentity and presentIdentityVerificationSheet provide you with information about the errors.

TypeScript support

Stripe Identity React Native SDK provides TypeScript support — it’s actually written in TypeScript. If you use it in your RN project, you can also use the types that SDK provided — StripeError and IdentityVerificationSheetStatus. Both can be useful while using the method presentIdentityVerificationSheet.

Stripe Identity features

Stripe Identity SDK offers a number of features that allow you to quickly introduce identity verification in your app. It ensures a secure and law-compliant implementation that should cover most of you and your users’ needs.

Simplified security

It’s simple for you to securely collect your user’s personally identifiable information (PII) such as identity document images. Sensitive PII data is sent directly to Stripe Identity instead of passing through your server. More information in the integration security guide.

Automatic document capture

We automatically capture images of the front and back of government-issued photo ID to ensure a clear and readable image.

Prebuilt UI

We provide IdentityVerificationSheet, a prebuilt UI that combines all the steps required to collect ID documents, selfies, and ID numbers into a single sheet that displays on top of your app.

Automated verification

Stripe Identity’s automated verification technology looks for patterns to help determine if an ID document is real or fake and uses distinctive physiological characteristics of faces to match your users’ selfies to photos on their ID document.

Collected identity information is checked against a global set of databases to confirm that it exists. Learn more about the verification checks supported by Stripe Identity, accessing verification results, or integration guide on handling verification outcomes.

Summary

Stripe Identity was born to make the ID verification process faster and more efficient. Thanks to the technology used, online businesses can easily confirm their users’ identities. It’s a great convenience and, most importantly, a viable safety measure that should be widely adopted.

This article was originally published at callstack.com on October 28, 2022.

Stripe Identity: ID Authentication Made Simple was originally published in Callstack Engineers on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is a monorepo?

A monorepo is a single repository that holds a multitude of projects with all their code and assets. While the projects can be related, they can be used independently by different teams.

Working with monorepos is very useful, especially when developing big and complex applications like super apps. Monorepos enable sharing the logic between a web app and a mobile app, for example.

In this article, we’re going to set up a basic structure for a monorepo in React Native.

Why use monorepo in React Native?

Thanks to react-native-web we can share every component so there’s no need to duplicate the code many times. This means easier dependency management, shorter CI times, and better collaboration between teams since the code can be shared.

The main advantage though is the possibility of sharing packages between React and React Native. Most of the time we decide to share only business logic, but thanks to React Native Web, we can also share some of the UI components.

Setting up Yarn workspaces

While setting up a monorepo, we have two options: we can either hoist the packages to the root level or prevent them from hoisting. Yarn workspaces have an option named nohoist which allows us to specify packages that aren’t hoisted. It depends on your use case but most of the time it’s better to hoist packages to the root level.

Alternatively, you can use npm workspaces, it should work the same.

Why it’s better to avoid using nohoist

Preventing packages from hoisting takes back the main advantage of monorepos which is sharing `node_modules` between repositories. When nohoist option is turned on, most of the time packages are duplicated inside the root level `node_modules` and inside the project level `node_modules`. Downloading packages multiple times can lead to longer CI/CD runs and higher costs.

Rearranging the project structure

In order to set up yarn workspaces, we need to restructure our project to suit the structure below. Projects need to be divided into separate folders and we should have root level `package.json`.

your-project packages web // <- React app mobile // <- React Native app shared // <- Shared (includes files shared between mobile/web)

plain1.txt hosted with ❤ by GitHub

Next, you should create a package.json file in the root directory of our project with this command: `$ yarn init -y`

It should look like this:

{ “private”: “true”, “name”: “example-app”, “version”: “1.0.0”, “workspaces”: [ “packages/*” ]}

codesnippet1.json hosted with ❤ by GitHub

Note that private: true is required because workspaces are not meant to be published.

In the workspaces section, we define a work tree. We can pass there an array of glob patterns that should be used to locate the workspaces. So in the example above, every folder inside packages is defined as a workspace.

Creating a React Native project

Use command below to create a React Native project inside the `packages` folder:

$ npx react-native init ExampleApp — directory mobile — template react-native-template-typescript

plain2.txt hosted with ❤ by GitHub

In order for our app to work in a monorepo structure, we need to make sure that config files are pointing to the root level `node_modules` due to package hoisting.

iOS setup

1. Change paths at the top of your Podfile

- require_relative ‘../node_modules/react-native/scripts/react_native_pods’- require_relative ‘../node_modules/@react-native-community/cli-platform-ios/native_modules’+ require_relative ‘../../../node_modules/react-native/scripts/react_native_pods’+ require_relative ‘../../../node_modules/@react-native-community/cli-platform-ios/native_modules’ target ‘ExampleApp’ do…

path1.diff hosted with ❤ by GitHub

1. Regenerate Pods, by entering the command below in the packages/mobile folder:

$ cd ios && pod install

plain3.txt hosted with ❤ by GitHub

1. Next open Xcode and inside Project settings > Build Phases open “Bundle React Native code and images”

Change the path of the script:

set -e

- WITH_ENVIRONMENT="../../node_modules/react-native/scripts/xcode/with-environment.sh"
- REACT_NATIVE_XCODE="../../node_modules/react-native/scripts/react-native-xcode.sh"
+ WITH_ENVIRONMENT="../../../node_modules/react-native/scripts/xcode/with-environment.sh"
+ REACT_NATIVE_XCODE="../../../node_modules/react-native/scripts/react-native-xcode.sh"

/bin/sh -c "$WITH_ENVIRONMENT $REACT_NATIVE_XCODE" path2.diff hosted with ❤ by GitHub

path2.diff hosted with ❤ by GitHub

It should look like this:

Android setup

React Native ≥ 0.71

Uncomment the line with reactNativeDir and point it to root node_modules

// packages/mobile/android/app/build.gradle

react { 
+  hermesCommand = "../../node_modules/react-native/sdks/hermesc/%OS-BIN%/hermesc"
}

android 1.diff hosted with ❤ by GitHub

In top-level build.gradle add this:

allprojects {
    project.pluginManager.withPlugin("com.facebook.react") {
        react {
            reactNativeDir = rootProject.file("../../../node_modules/react-native/")
            codegenDir = rootProject.file("../../../node_modules/react-native-codegen/")
        }
    }
}

android 2.shell hosted with ❤ by GitHub

and inside: packages/mobile/android/settings.gradle

+ apply from: file("../../../node_modules/@react-native-community/cli-platform-android/native_modules.gradle"); applyNativeModulesSettingsGradle(settings)
+ includeBuild('../../../node_modules/react-native-gradle-plugin')

android 3.diff hosted with ❤ by GitHub

‍
React Native ≤ 0.71

1. Fix paths inside `packages/mobile/android/build.gradle`

Change url of the React Native Android binaries, and Android JSC in the `allprojects` section:

allprojects { repositories { maven { // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm- url(https://medium.com/node_modules/react-native/android%E2%80%9D)+ url(https://medium.com/node_modules/react-native/android%E2%80%9D) } maven { // Android JSC is installed from npm- url(https://medium.com/node_modules/jsc-android/dist%E2%80%9D)+ url(https://medium.com/node_modules/jsc-android/dist%E2%80%9D) } … }}

code snippet2.diff hosted with ❤ by GitHub

2. Fix `packages/mobile/android/settings.gradle`

Here we also need to change paths to the root `node_modules` folder.

rootProject.name = 'example-app'
- apply from: file("../node_modules/@react-native-community/cli-platform-android/native_modules.gradle"); applyNativeModulesSettingsGradle(settings)
- includeBuild('../node_modules/react-native-gradle-plugin')
+ apply from: file("../../../node_modules/@react-native-community/cli-platform-android/native_modules.gradle"); applyNativeModulesSettingsGradle(settings)
+ includeBuild('../../../node_modules/react-native-gradle-plugin')
include ':app'
if (settings.hasProperty("newArchEnabled") && settings.newArchEnabled == "true") {
    include(":ReactAndroid")
-   project(":ReactAndroid").projectDir = file('../node_modules/react-native/ReactAndroid')
+   project(":ReactAndroid").projectDir = file('../../../node_modules/react-native/ReactAndroid')
    include(":ReactAndroid:hermes-engine")
-   project(":ReactAndroid:hermes-engine").projectDir = file('../node_modules/react-native/ReactAndroid/hermes-engine')
+   project(":ReactAndroid:hermes-engine").projectDir = file('../../../node_modules/react-native/ReactAndroid/hermes-engine')
}

path3.diff hosted with ❤ by GitHub

3. Next go to `packages/mobile/android/app/build.gradle`

Inside the `project.ext.react` we need to add property `cliPath` so it will override the default location of the cli.

project.ext.react = [+ cliPath: “../../../../node_modules/react-native/cli.js”,]

plain4.txt hosted with ❤ by GitHub

In the same file, change this line: `apply from: “../../node_modules/react-native/react.gradle”` to point to root level `node_modules` as well.

- apply from: “../../node_modules/react-native/react.gradle”+ apply from: “../../../../node_modules/react-native/react.gradle”

path4.diff hosted with ❤ by GitHub

And also change: `inside packages/mobile/android/app/build.gradle`

- apply from: file(“../../node_modules/@react-native-community/cli-platform-android/native_modules.gradle”); applyNativeModulesAppBuildGradle(project)+ apply from: file(“../../../../node_modules/@react-native-community/cli-platform-android/native_modules.gradle”); applyNativeModulesAppBuildGradle(project)

path5.diff hosted with ❤ by GitHub

If you are using or planning to use the new architecture, we also need to change a few lines in the `isNewArchitectureEnabled()` if statement**.**

if (isNewArchitectureEnabled()) {
            // We configure the NDK build only if you decide to opt-in for the New Architecture.
            externalNativeBuild {
                ndkBuild {
                    arguments "APP_PLATFORM=android-21",
                        "APP_STL=c++_shared",
                        "NDK_TOOLCHAIN_VERSION=clang",
                        "GENERATED_SRC_DIR=$buildDir/generated/source",
                        "PROJECT_BUILD_DIR=$buildDir",
-                       "REACT_ANDROID_DIR=$rootDir/../node_modules/react-native/ReactAndroid",
-                       "REACT_ANDROID_BUILD_DIR=$rootDir/../node_modules/react-native/ReactAndroid/build",
-                       "NODE_MODULES_DIR=$rootDir/../node_modules"
+                       "REACT_ANDROID_DIR=../../node_modules/react-native/ReactAndroid",
+                       "REACT_ANDROID_BUILD_DIR=../../node_modules/react-native/ReactAndroid/build",
+                       "NODE_MODULES_DIR=../../node_modules"
                    cFlags "-Wall", "-Werror", "-fexceptions", "-frtti", "-DWITH_INSPECTOR=1"
                    cppFlags "-std=c++17"
                    // Make sure this target name is the same you specify inside the
                    // src/main/jni/Android.mk file for the `LOCAL_MODULE` variable.
                    targets "okwasniewskionboarding_appmodules"
                }
            }

code snippet3.diff hosted with ❤ by GitHub

Configure Metro

We’re almost done with setting up the project. The last thing in the React Native app is to add `watchFolders` so metro knows where the linked `node_modules` are. The shared modules are symlinked by yarn, and since metro doesn’t follow symlinks we need to explicitly say where the linked `node_modules` are.

const path = require(“path”); // packages/mobile/metro.config.jsmodule.exports = { watchFolders: [ path.resolve(__dirname, ‘../../node_modules’) ],};

code snippet4.javascript hosted with ❤ by GitHub

Setting up a shared package

To keep it simple, we’re going to share only one function across React Native and React.

Inside the `packages/shared`, create a new `package.json` file with the command:

$ yarn init -y

code snippet5.javascript hosted with ❤ by GitHub

The shared library is in typescript, so we need to set up a build step with the typescript compiler (tsc).

The build step uses `rimraf` which is a small utility for node that allows us to remove a folder, and then build the app with tsc.

`postinstall` indicates that our shared dependency will build automatically after installing.

{ “name”: “@example-app/shared”, “version”: “1.0.0”, “main”: “dist/index.js”, “scripts”: { “build”: “rimraf dist && tsc”, “postinstall”: “yarn build”, “watch”: “tsc — watch” }, “dependencies”: { “react-native”: “0.69.1”, “react”: “18.0.0” }, “devDependencies”: { “rimraf”: “³.0.2”, “typescript”: “⁴.4.4” }, “keywords”: [], “author”: “”, “license”: “ISC”}

code snippet6.json hosted with ❤ by GitHub

Note: The package name is really important, because it will indicate from where we will import our module.

It’s also important to add all packages and keep the exact same version used in a shared project and target projects.

Next we need to configure `tsconfig.json` where we can define our build settings.

Here is an example config file:

// packages/shared/tsconfig.json
{
    "compilerOptions": {
      "target": "es6",
      "lib": ["dom", "dom.iterable", "esnext"],
      "skipLibCheck": true,
      "esModuleInterop": true,
      "allowSyntheticDefaultImports": true,
      "strict": true,
      "forceConsistentCasingInFileNames": true,
      "module": "commonjs",
      "outDir": "dist", // <- Directory of generated output
      "moduleResolution": "node",
      "resolveJsonModule": true,
      "experimentalDecorators": true,
      "strictPropertyInitialization": false,
      "declaration": true,
      "jsx": "react"
    },
  }

code snippet7.json hosted with ❤ by GitHub

Next, let’s create an `index.ts` file inside the `packages/shared` folder.

export const add = (a: number, b: number) => { return a + b;}

code snippet8.javascript hosted with ❤ by GitHub

Run this command to build the package:

$ yarn build

code snippet9.javascript hosted with ❤ by GitHub

Next, we need to add this package as a dependency in our react native project. So inside `packages/mobile/package.json` add `@example-app/shared` as a dependency.

Note that the version of the package must match the version specified inside packages/shared/package.json. Previously we defined that @example-app/shared version is 1.0.0.

// packages/mobile/package.json

"dependencies": {
    "@example-app/shared": "1.0.0",
    ...
  },

code snippet10.json hosted with ❤ by GitHub

And also inside the metro.config.js

// packages/mobile/metro.config.js

module.exports = {
  watchFolders: [
    path.resolve(__dirname, '../../node_modules'),
+   path.resolve(__dirname, '../../node_modules/@example-app/shared'),
  ],
};

code snippet11.javascript hosted with ❤ by GitHub

Now, run this command in the root directory, so yarn will set up symlinks for your shared package.

$ yarn

code snippet12.javascript hosted with ❤ by GitHub

Right now we should be able to import the add function inside React Native app.

import React from 'react';
import {Text, TouchableOpacity, View} from 'react-native';
import {add} from '@example-app/shared';

const App = () => {
  return (
    <View>
      <TouchableOpacity
        accessibilityRole="button"
        onPress={() => {
          console.log(add(1, 2));
        }}>
        <Text>Run Add function</Text>
      </TouchableOpacity>
    </View>
  );
};

export default App;

code snippet13.javascript hosted with ❤ by GitHub

Setting up a React project

In order to set up a React project, execute the command below inside `packages/web`:

$ npx create-react-app . ExampleApp — template typescript

code snippet14.javascript hosted with ❤ by GitHub

Add `@example-app/shared` dependency:

// packages/web/package.json”dependencies”: { “@example-app/shared”: “1.0.0”, … },

code snippet15.json hosted with ❤ by GitHub

And we can import and use the shared package:

import React from 'react';
import {add} from '@example-app/shared';

const App = () => {
  return (
    <div>
      <button onClick={() => console.log(add(1,2))}>Run add function</button>
    </div>
  );
};

export default App;

code snippet16.javascript hosted with ❤ by GitHub

Sharing UI components with React Native Web

In order to share UI components, we need React Native Web which provides a compatibility layer between React DOM and React Native.

Installation steps

Install react-native-web:

$ yarn add react-native-web

code snippet17.txt hosted with ❤ by GitHub

Install `babel-plugin-react-native-web`

$ yarn add -D babel-plugin-react-native-web

code snippet18.txt hosted with ❤ by GitHub

Modify shared package to export React Native component

First inside `packages/shared`, create a new file called `TestComponent.tsx`

import { Text, View } from "react-native";
import React from "react";

const TestComponent = () => {
  return (
    <View>
      <Text>TestComponent</Text>
    </View>
  );
};

export default TestComponent;

code snippet 19.javascript hosted with ❤ by GitHub

Next export it from the `index.ts file`:

export const add = (a: number, b: number) => {
 return a + b;
}

export { default as TestComponent } from './TestComponent.tsx'code snippet20.javascript hosted with ❤ by GitHub

Rebuild the shared package inside `packages/shared` folder:

$ yarn build

code snippet21.txt hosted with ❤ by GitHub

And now we should be able to use TestComponent inside a React app.

import React from 'react';
import {add, TestComponent} from '@example-app/shared';

const App = () => {
  return (
    <div>
      <button onPress={() => console.log(add(1,2))}>Run add function</button>
   <TestComponent/> // <- React Native component inside React app! 
    </div>
  );
};

export default App;

code snippet22.javascript hosted with ❤ by GitHub

To sum up

Setting up a monorepo can be tricky, but it pays off in the long run! You can easily share all of your code and assets between React and React Native.

Using a monorepo is growing in popularity — there is even an open proposal to migrate react-native repository to monorepo. Find out more about React Native monorepo on github.

This article was originally published at callstack.com on October 11, 2022.

Setting up React Native Monorepo with Yarn Workspaces was originally published in Callstack Engineers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mock Service Worker is an API mocking tool that lets you mock by intercepting requests on the network level. You can reuse the same mock definition for testing, development, and debugging.

MSW is delightful to adopt. Plus, it makes testing components with network requests a pleasure.

In this article, I’d like to share some best practices for working with MSW for basic and more advanced problems.

When to use a Mock Service Worker?

Has this ever happened to you?

You’ve finally gotten the green light to spend some writing tests!

This sprint is calm, but you remembered all too clearly that disastrous release a few weeks ago. The entire team had to drop everything and fix bugs.

Your repo has around 20% test coverage, and everyone agrees that it’s too little, but there’s never enough time to write tests. You write your features, get an LGTM on the PR, and move on.

But this release will be different!

You have a dedicated task, a couple of story points, and a jug of coffee to get this done right. You know the feature you’re about to test very well; you wrote most of it. You set out to mock the component and pass some props.

The tests fail.

No worries, that was only the first try, my friend! You re-check what needs testing, add some missing mocks, and maybe throw a jest.spyOn in there. You’re so proud of your accomplishment!

yarn test — another fail.

You dig deeper and realize your component depends on a network request returning some data.

Ok, don’t panic.

Let’s see how other tests in the codebase manage this. You find tests mocking axios, other ones’ mock fetch, and wait; there are also some global files mocking resolved values and network errors?

You sweat a little, add many lines of code to your test, and ponder briefly if all of them are necessary. You notice tests unrelated to your changes started failing! You start feeling like the people in the first half of any infomercial.

…and you probably think: there has to be a better way! That’s when Mock Service Worker comes in handy.

The basic guide to Mock Service Worker (MSW)

Mock Service Worker intercepts real network requests that your tests make.

The components in your tests think they are talking with the real API, which means you can test their real functionality (as opposed to testing contained, mock functionality). If you don’t feel convinced about this approach just yet, I invite you to read Kent C. Dodd’s excellent blog post: Stop Mocking Fetch.

Let’s see this magical library in action. As with any new dependency, you need to start by adding it to your project: ‘npm install msw — save-dev or yarn add msw — dev’

Once the installation finishes, you will have to define your request handlers. MSW documentation suggests creating them in a file called mocks/handlers.js. Depending on your project, you can create REST or GraphQL handlers. MSW request handlers aim to hold instructions for specific API endpoints.

Let’s take a look at an example REST request handler:

// src/mocks/handlers.js
import { rest } from “msw”;

export const handlers = [
 // Handles a POST request
 rest.post(“https://fancy-app.com/postToThisEndpoint", (req, res, ctx) => {
 return res(
 // Respond with a 200 status code
 ctx.status(200)
 );
 }),

// Handles a GET request
 rest.get(“https://fancy-app.com/getSomeData", (req, res, ctx) => {
 return res(
 ctx.status(200),
 ctx.json({
 data: “fancy data string”,
 })
 );
 }),
];

msw.test.tsx hosted with ❤ by GitHub

We start by importing the rest function from MSW, then create an array of API endpoints we want to handle.

We can add anything we would like to this array. We can mock an error response; we can mock correct or faulty data objects. Remember to use absolute request URLs since we will use those request handlers in a NodeJS environment.

The only caveat here is that if you add multiple handlers for one API endpoint, the last one in the array will be the only one that’s actually used. But more on that later.

Once you have a few handlers ready, it is time to let your test suite know about them. We will need to set up a request mocking server and run it with our tests. This may sound scary, but don’t worry; the server setup file is three lines long.

Let’s create a new file called server.js:

// src/mocks/server.js
import { setupServer } from ‘msw/node’
import { handlers } from ‘./handlers’

// This configures a request mocking server with the given request handlers.
export const server = setupServer(…handlers)

msw.test.2.tsx hosted with ❤ by GitHub

We have to import the ‘setupServer’ function from ‘msw/node’ and pass the previously created request handlers to that function.

I don’t know about you, but this is the simplest mock server setup I have ever seen!

The very last step is running the mock server when you run your tests.

This step depends heavily on your project setup. There are various ways to set up and configure Jest, and this blog post will not try to cover all of them.

Instead, I’ll talk about the setup I’ve seen the most often: using a dedicated setupTests.js file, which is called through Jest’s setupFilesAfterEv.

If that’s the case in your project, congratulations! You only need to add the following lines:

// src/setupTests.js
import { server } from './mocks/server.js'
// Establish API mocking before all tests.
beforeAll(() => server.listen())

// Reset any request handlers that we may add during the tests,
// so they don't affect other tests.
afterEach(() => server.resetHandlers())

// Clean up after the tests are finished.
afterAll(() => server.close())

msw.test.2.tsx hosted with ❤ by GitHub

If you prefer to test MSW quickly in a single test file, you can do so as well.

It is possible to use the mock server directly anywhere you would like. This means you can skip all the steps above (except for the installation, let’s not get carried away!) and write something like this in your test file:

// __tests__/FancyPage.test.js
import { setupServer } from “msw/node”;
import { FancyComponentWithAPICall } from “../FancyComponentWithAPICall”;

const server = setupServer(
 rest.get(“https://fancy-app.com/getSomeData", (req, res, ctx) => {
 return res(ctx.json({ data: “return this string” }));
 })
);

describe(“<FancyComponentWithAPICall />”, () => {
 beforeAll(() => server.listen());
 afterAll(() => server.close());
 test(“displays data from backend”, async () => {
 // Render components, perform requests, receive mocked responses.
 });
});

msw.test.4.tsx hosted with ❤ by GitHub

This has all been fun and games so far, don’t you think?

Going through the setup takes less than an hour. Honestly, going through the official MSW documentation takes less than an hour!

If you’re working on a project that’s not too big, you can stop reading now, pat yourself on the back, and look at all those green check marks on your tests.

The advanced guide to Mock Service Worker

If you are working on a big application, maybe a robust dashboard, or an e-commerce website, you realize the basic setup presented above won’t cut it.

The handlers array will soon become a 10-thousand-line mess. People may add mock servers in random tests, making debugging errors difficult.

My team and I have faced those issues, and here’s how we decided to tackle them.

As stated above, the biggest issue in a big app using MSW is the handlers’ files becoming unreadable. We tackled this issue by dividing the handlers’ files into separate, feature-related files.

Now, instead of a single, long ‘handlers.js’, we had something in the shape of the following structure:

src
│
└───tools
| └───jest
│ │ commonMswHandlers.js
│ │ server.js 
| | setupTests.js
│
└───featureA
│ │ FeatureA.js
| |
| └───__tests__
│ │ FeatureA.test.js
│ │
│ └───msw
│ │ mswHandlers.js
│ 
└───featureB
│ │ FeatureB.js
| |
| └───__tests__
│ │ FeatureB.test.js
│ │
│ └───msw
│ │ mswHandlers.js

msw-test.5.tsx hosted with ❤ by GitHub

A few API endpoints which were commonly needed for the tests and did not clearly fit any feature were left in the ‘commonMswHandlers.js’ file.

Once we’ve effectively sliced the handlers array, we started wondering how these specific request handlers should be consumed. As we saw above, we could let the test authors import ‘setupServer’ with specific handlers directly in the test files.

However, this quickly became quite verbose. We decided to create helper functions in our ‘mswHandlers.js’ files. An example file would look like this:

// src/FancyHomepageFeature/msw/mswHandlers.js

import { rest } from ‘msw’;
// import the server created for the entire test suite
// this mock server includes commonMswHandlers
import { server } from ‘../tools/jest/server’;

const homeHandlers = [
 rest.get(‘https://fancy-app.com/homepage-data', (req, res, ctx) => {
 return res(
 ctx.json({
 contents: [
 {
 banner: ‘Fancy Banner’
 },
 ],
 })
 );
 }),
];

export const setupHomeHandlers = () => {
 server.use(…homeHandlers);
};

msw.test.6.tsx hosted with ❤ by GitHub

As you can see in the code above, we’re using the server.use() function. This function prepends request handlers to the current server instance. This means we are using everything that has been set up in the tools/jest/server.js file, and we’re adding a specific request handler for a specific URL.

Now, to use this helper function in a test, the test author would need to write something like this:

// src/FancyHomepageFeature/__tests__/FancyHomePage.test.js
import { FancyHomePage } from "../FancyHomePage";
import { setupHomeHandlers } from "./msw/mswHandlers";

describe("<FancyHomePage />", () => {
  beforeEach(() => setupHomeHandlers());
  test("displays homepage data", async () => {
    // Render homepage with backend data
  });
});

msw.test.7.tsx hosted with ❤ by GitHub

The test author must import the server helper and run it in a ‘beforeEach’ block.

Tests in this particular test suite will now look into the ‘homeHandlers’ array when the components need something from the *https://fancy-app.com/homepage-data* endpoint, while other test suites remain unaffected by this change.

Testing errors

What if you would like to test that your website can handle network errors on specific endpoints?

Let’s add another helper function to the ‘FancyHomepageFeature/msw/mswHandlers.js’ file:

// src/FancyHomepageFeature/msw/mswHandlers.js

import { rest } from 'msw';
import { server } from '../tools/jest/server';

//...

export const setupFaultyHomeHandlers = () => {
  server.use(
    rest.get('https://fancy-app.com/homepage-data', (_req, res, ctx) => {
      return res(ctx.status(200), ctx.json({weirdDataType: 'something went wrong'}));
    }),
  );
};

export const setupFailedHomeHandlers = () => {
  server.use(
    rest.get('https://fancy-app.com/homepage-data', (_req, res) => {
      return res.networkError('Failed to connect');
    })
  );
};

msw.test.8.tsx hosted with ❤ by GitHub

We can add tests for the scenarios described above: what should happen if the server returns a successful response, but the values are unexpected? How should the website behave if there is a network error?

Let’s see those tests in action:

// src/FancyHomepageFeature/__tests__/FancyHomePage.test.js
import { FancyHomePage } from "../FancyHomePage";
import {
  setupHomeHandlers,
  setupFaultyHomeHandlers,
  setupFailedHomeHandlers,
} from "./msw/mswHandlers";

describe("<FancyHomePage />", () => {
  beforeEach(() => setupHomeHandlers());
  test("displays homepage data", async () => {
    // Render homepage with backend data
  });
});

describe("<FancyHomePage /> - faulty data", () => {
  beforeEach(() => setupFaultyHomeHandlers());
  test("displays readable error when receiving unexpected data", async () => {
    // Render homepage with error information
  });
});

describe("<FancyHomePage /> - network error", () => {
  beforeEach(() => setupFailedHomeHandlers());
  test("displays network error", async () => {
    // Render homepage with network error information
  });
});

msw.test.8.tsx hosted with ❤ by GitHub

Request handler overrides

If you read the MSW documentation carefully, you may be tempted to use the one-time override (‘res.once()’) for testing errors.

We have tried using this strategy in our codebase. We have found that using ‘res.once()’ is counter-intuitive to the test author. If the test setup includes this one-time override, but the test suite has more than one test, only the first test will behave as expected.

It may take the test author quite some time and great detective work to figure out that all his tests were correct, but the MSW handlers were prepared to handle only one request. If I was ever to use ‘res.once()’, it would only be directly in a test file, where it’s easily visible, and never in setup files.

Response object overrides

There is another type of override that I do recommend using — response object overrides.

Let’s say you would like to test your network request with different, successful responses. You could write separate functions using ‘server.use()’, but that’s a lot of repetitive work.

One of my colleagues, Jan Jaworski, came up with a very elegant solution to this problem. He created a helper function that could accept override data and use it in the response object thanks to the spread operator.

The function looked roughly like this:

export const setupSmartMswHelper = (override = {}) => {
  server.use(
    rest.get("https://fancy-app.com/return-some-data", (req, res, ctx) => {
      return res(
        ctx.status(200),
        ctx.json({
          fancyData: "Im so fancy!",
          moreData: "You already know",
          ...override,
        })
      );
    })
  );
};

msw.test.9.tsx hosted with ❤ by GitHub

Here’s how this helper function would be used in a test:

// src/FancyHomepageFeature/__tests__/FancyHomePage.test.js
//...
test("handles updated data", async () => {
  setupSmartMswHelper({
    moreData: "Cant you taste this gold?",
  });
  //...
});

msw.test.10.tsx hosted with ❤ by GitHub

This strategy is especially useful for big data objects we don’t want to re-type multiple times.

Testing errors — bonus content

Since we started testing network errors, we discovered the terminal output got polluted with many ‘console.error’ messages. These error messages were expected, and we didn’t want them hiding real (as in UNexpected) errors.

We decided to add a ‘console.error’ override in the Jest setup file:

// tools/jest/setupTests.js
const error = console.error;

console.error = (...args) =>
  // Suppress error messages regarding network error in tests
  /Error: Request failed with status code 500/m.test(
    args[0]
  )
    ? void 0
    : error(...args);

msw.test.11.tsx hosted with ❤ by GitHub

Thanks to this little function, we hid only the specific console errors we were sure about.

Summary

If you were to take away only one thing from this blog post, I sincerely hope it would be the notion that MSW is a great tool worth trying, even in a big project.

The solutions I described worked great in a real project. They may not be 100% ideal for your needs, but I hope you find some inspiration here to create the best, most comfortable, and developer-friendly test setup possible. At the end of the day, we all want to feel like the people at the end of infomercials, no?

This article was originally published at callstack.com on September 27, 2022.

A Comprehensive Guide to Mock Service Worker (MSW) was originally published in Callstack Engineers on Medium, where people are continuing the conversation by highlighting and responding to this story.