Hello, today I’d like to share my experience applying Fabric (the new architecture) to the open-source project react-native-video.

First, Fabric refers to a native module related to Views (UI) in the new architecture introduced in React Native (RN).

You can read the official documentation on Fabric here:

React Native Fabric Renderer Documentation

1. New Architecture

To my understanding, the New Architecture eliminates the need for the bridge between the JavaScript layer and the native layer, which was a performance bottleneck in the old architecture. Instead, it uses C++ to directly interact between layers, improving performance.

You can find more detailed official information on the New Architecture here:

React Native New Architecture Overview

2. react-native-video

react-native-video is a well-known open-source RN library for handling videos. Like other domains in RN, there’s a major open-source library for each feature, and for video-related tasks, react-native-video is the go-to native library.

You can find the library on GitHub here:

react-native-video GitHub Repository

It’s a massive library offering various features, but due to the complexity of video functionality, it’s often hard to maintain all the features in one place.

The task I worked on was applying the New Architecture to this pre-existing open-source library.

I collaborated with a colleague at work to submit a PR, but it hasn’t been merged yet.

PRs:

PR #3122

PR #3204

Since the codebase had changed a lot and the PR was quite large, we tried to break it up into smaller parts, but even then, it became a heavy PR. Eventually, we ended up submitting a PR that included codegen support:

PR #3487

3. Troubleshooting

Since we started implementing the new architecture later, I had the advantage of referencing other RN open-source libraries that had already applied it.

Here are a few libraries I referenced that helped a lot:

• react-native-safe-area-context
• lottie-react-native
• react-navigation

Many major libraries had already adopted the New Architecture by the time we started, so it was very helpful to study how they implemented Fabric.

For iOS, the first step was to handle podspecs.

As shown in this example, we checked if the new architecture was applied in the podspec and installed the necessary pod modules.

For Android, this was handled in the build.gradle.

As seen here, files were split depending on whether Fabric was applied.

The first challenge was integrating codegen with TypeScript. I had issues before version 0.73.0, since array types (read-only arrays) were not supported for event callback parameters. However, this support was added from version 0.73.0 onward, so make sure to check it out!

Here’s the relevant changelog entry:

React Native Changelog for 0.73.0

One of the key differences was that codegen is done using C++ namespaces, meaning you cannot use the same variable name in different types. For example:

type SomeType {
  name: string
}

type AnotherType {
  name: string
}

Had to be changed to:

type SomeType {
  someTypeName: string
}

type AnotherType {
  anotherTypeName: string
}

On iOS, since we’re dealing directly with C++, we had to work with .mm files, which was a bit tricky at first. My colleague, who worked on iOS, referred to StackOverflow to create utility functions that parse props passed down from JS.

For Android, it was relatively simpler, but it required creating and managing new files for each event type, which was a bit challenging.

Eventually, we finished the migration work and were progressing toward deploying it in production. However, since the React Native New Architecture was still unstable, with UI issues, we reverted to the old architecture and proceeded with the deployment.

Conclusion: Troubleshooting Process

• I referred to other open-source libraries for guidance.
• For C++ code, StackOverflow was an invaluable resource.
• I followed the React Native changelog for updates.

It was a challenging task, but we managed to overcome the hurdles.

This was my first time contributing to such a large open-source project. Although the PR hasn’t been merged yet, I realized that breaking features into smaller PRs makes it easier for maintainers to manage.