Bringing the New React Native Architecture to the OSS Community - Fall Edition

Rate this content

At the end of 2021, we successfully rolled out the New React Native Architecture in the Facebook app. Now, it’s time to empower every React Native developer on the globe to use the New React Native Architecture, both the new Fabric renderer and the new TurboModule system. But migrating an entire ecosystem to a New Architecture is no easy task. To support the whole community in this endeavor, we lined up a set of tools and materials that will help both app and library developers to join us in this journey. In the talk, we will present how the New React Native Architecture looks in the OSS space. We will discuss the impact this will have on developing React Native projects. Lastly, we will cover what we learned from the React Native New Architecture migration at Meta, and how you can tackle your migration in your organization.

29 min
02 Dec, 2022

Video Summary and Transcription

The Talk discusses the new React Native architecture and its introduction to the open source community. The new architecture aims to bring React 18 to mobile and native platforms, while eliminating the Bridge component bottleneck. It includes core concepts like the new renderer (fabric), native module system (turbo modules), codegen for type safety, and bridge-less mode. The architecture simplifies the development process for web developers, requires changes in build tools, and recommends the use of the Hermes JavaScript engine. It also emphasizes the importance of exploring new APIs, migrating libraries, and providing feedback to improve the ecosystem.

Available in Español

1. Introduction to React Native Architecture

Short description:

We're going to talk about the new React Native architecture and how we bring it to the open source community. The new architecture is how we're going to bring React 18 to mobile and to native. The new architecture of React Native has been in the media for quite some time. We did our rollout internally. How do we bring it out? How do we let the open source community use it as well? This talk is going to be about this, exactly. Like, how do we let people outside of meta benefit from React 18 and the new architecture on Native? We want to bring all the benefits of React 18 to Native. But it's not only that. We wanted to get rid of the Bridge component, which is a huge bottleneck in the React Native architecture.

Awesome. So hi everyone. Thank you very much for joining me today. We're going to talk about the new React Native architecture and how we bring it to the open source community. As I believe a lot of you here might be React and not React Native developer, I hope you have heard about React 18. So to make it simple for you, the new architecture is how we're going to bring React 18 to mobile and to native.

A little story about myself. I'm actually an Android engineer working on the React Native team. You can find me online as Kurtinico on Twitter and on GitHub. And so the new architecture of React Native has been in the media for quite some time. If you actually go on line and search for React Native new architecture, you can find quite some content, I would say. And let's look through some of the videos that you will be seeing. The first one. It's from ReactConf 2018.

So well we have been talking so long about it. Like last year, my colleague Joshua gave a talk about it at React Native EU and it was all about the new architecture within meta. But now the point is, okay. So we did our rollout internally. How do we bring it out? How do we let the open source community use it as well? So if we look at a timeline of the new architecture, again, it was started as a six-month project in 2018. But it turns out that the biggest product that we have at meta that uses React Native, which is the Facebook app, is quite complicated. And trust me, engineers managed to use every possible edge case and every possible API of React Native to squeeze every performance out of this framework. So it took us, at the end of the day, nearly three years to do the full rollout of the new architecture on the Facebook app. But then from there, as I said, we looked at ourselves and we asked, OK, how do we roll this out in the open source? And so this talk is going to be about this, exactly. Like, how do we let people outside of meta benefit from React 18 and the new architecture on Native?

So to do, again, one step back and really understand why we are bringing the new architecture. As I said before, we want to bring all the benefits of React 18 to Native. But it's not only that. If you've been doing React Native, you probably know that there is this component which is sort of crucial in the React Native architecture, which is called the Bridge. It's essentially a component where it allows the JavaScript layer to communicate with the native layer and everything is passed through this bridge as JSON. And as you can imagine, it's a huge bottleneck. So, first we wanted to get rid of it.

2. Core Concepts of the New Architecture

Short description:

We wrote the internals of our architecture once, allowing us to share optimizations between Android and iOS. The new architecture introduces the codegen component for type safety and serves as a foundation for future features. The core concepts, or pillars, include the new renderer (fabric), the native module system (turbo modules), the Cogen for type safety, and bridge-less mode. On Android, Java classes will be generated.

As we wrote a lot of the internals of our architecture, we actually took a stance and wrote them once. Like, we used to have an Android renderer and an iOS renderer, which were, like, not exactly aligned. So we wrote a lot of internals in C++ and this allowed us to share some platform-specific optimizations between the two platforms.

On top of that, using the bridge meant that we could not really benefit from type safety. That's why the new architecture has a new component called the codegen, which brings type safety inside our API. And finally, you should think of the new architecture as the foundational stone for a lot of features that will be built on top of React 18 in these new APIs and will be delivered also to native. So, we need to make sure people are using those APIs.

So, what are the core concepts of the new architecture? We call them pillars. And we have several of them. First, we have the new renderer. And this is what actually uses React 18. And this new renderer is often referenced as fabric. Then we have the new native module system, which allows you to interact with the native platform and call APIs for Android and iOS. And we call this mechanism turbo modules. Then, as I said before, we wanted to bring type safety in our formula. That's why we introduced a new component called the Cogen. And the last pillar is bridge-less mode. So, once everything is in place, you have all of your components compatible with fabric and everything compatible with turbo modules and so on, you can fully turn off the bridge.

So how this will look like on Android. We are gonna generate some Java classes. So we'll have like an abstract class with the constructor and a method that respects the signature.

3. Architecture, Build Tools, and Hermes

Short description:

The new architecture simplifies the process of writing Android and iOS code for web developers. It generates the necessary boilerplate code based on the declared public API, reducing the need for manual coding. The architecture requires changes in build tools, with Gradle used for Android and CocoaPods for iOS. C++ code is encapsulated and hidden from web developers, but can be utilized for performance-specific applications. The build infrastructure has been improved, removing legacy code and addressing build failures. Additionally, the JavaScript engine Hermes is recommended for better support and issue tracking.

Here you define an interface and you say that you have a function which answers the ultimate question and you register this module. And again, the point is this function and this signature. The Cogen is able to understand that you are declaring a public API that you will use on your JavaScript word. And important information here is that there is an input which is a string and an output which is a number. From this information we can generate a lot of the boilerplate code that you don't have to write.

The thing is that web developers that work with React Native don't really like to write android and iOS code so we're trying to make this like as simple as possible. So how this will look like on Android. We are gonna generate some Java classes. So we'll have like an abstract class with the constructor and a method that respects the signature. So in this case this will be an abstract method that accepts a JavaString in input and returns a double. So we do all the type, we resolve the types to the platform specific types that every platform accepts. So on iOS, for example, you're going to have Objective-C protocol that accepts NSString and returns an NSNumber. Obviously at some point you need to write the business logic, like someone should answer the ultimate question, we can't answer that for you, but yeah, we're trying to simplify like a lot of boilerplate code that is not needed to be written anymore.

Okay, so yeah, like this new architecture required us to do a lot of changes across the board as you can imagine because now there is a code gen to run and there is yeah, a lot of moving parts. So, we took a stance at our build tools, so a lot of changes are actually coming on our integration with the underlying platform, and here there is a little bit of a challenge, because at Meta internally we use a build tool, which is called Buck, which is also open source, and the new architecture for us internally works on top of this, which is great, but we can't expect people outside of Meta to use Buck because it's, I mean it's open source, but we want to use the build tools which are specific to the platform you run on.

So on Android you will run on Gradle, and we took a lot of time to sort of make sure that everything integrates well. There will be some C++ code, so there will be also CMake files that are handled by Gradle. Little disclaimer, a lot of people told me I don't want to see C++ code, so we sort of encapsulated everything, web developers will not have to see CMake or C++ code at all, but it's under the hood and can be used for performance-specific applications. We wrote our Gradle plugin and effectively in React Native 71, this removes a lot of the legacy code and a lot of the build failures users were experiencing when creating your Android app, this logic has been completely rewritten. The TLDR here is that within your architecture, we're actually cleaning up a lot of the legacy code and legacy build infrastructure which built up on our open source code during the years.

On iOS, similarly we do have cocoa pods. And again, we took the stand here to clean up things a bit. We wrote a lot of the logic, now we have a full suite of Ruby scripts which are easier to use, they're smaller and they're fully tested. So hopefully you will see less build failures in the future.

Okay. So, another component that we actually, it's not necessarily part of the new architecture but we spend a lot of time on it and we envisioned the new architecture with these things bundled together is our JavaScript engine called Hermes. So, in the documentation for the new architecture you will actually find it recommended. And we can provide better support. Like if your app is crashing and you have Hermes we can know more what's going on. So, we invite users to use this engine and raise any issues you might have.

4. Bundled Hermes and Default Engine

Short description:

From React Native 69, React Native now comes bundled with Hermes, a JavaScript engine that is fully compatible with each version of React Native. In the past, compatibility issues arose when the engine and React Native were built at different times. However, with the bundled Hermes, you can use an engine that is fully compatible with your React Native version. Starting from React Native 70, Hermes is the default engine for new projects, although it can be disabled if necessary.

From React Native 69 we actually did a change which is called bundled Hermes. So, every version of React Native now comes with a specific version of this JavaScript engine which we know being fully compatible with the version of React Native. In the past we had scenarios where the engine was built at a given time and React Native was built at another time and they were not really compatible with each other. So, now you have an engine which is fully compatible with your version of React Native every time and you can just use it. From React Native 70 which we released a couple of months ago Hermes is actually the default engine. So, all the new projects will have Hermes enabled by default and if you don't want it because you might have a valid reason you will need to disable it.

5. Updates on Modern Languages and Timeline

Short description:

A couple of updates on the modern languages side. TypeScript is now fully supported by Cogent and will be the default language in React Native 71. Kotlin is fully supported on Android. The React Native .DEV website is fully migrated and bilingual, supporting both Java and Kotlin. The use of Zwift and C++ interoperability is being explored. The new architecture rollout began with React Native 68, and React 18 support was added in React Native 69.

A couple of updates also that we did on the modern languages side of things, like a lot of people ask us to use different programming languages when they use React Native. And here I have a lot of updates actually. TypeScript. When we released the first version of the New Architecture docs the most up-voted comment was I don't want to use flow, which I can totally understand. Our first version of the docs were like essentially our internal wiki polished and open sourced. And internally at Meta we use flow, but outside that's not the case. So we had to rebuild a lot of code and support.

Now TypeScript is actually fully supported by Cogent. And I'll tell you more, actually in 71, React Native 71, which is supposed to be released in the near future, matters of weeks at this point, TypeScript will actually be the default language. So the new projects will all be created with TypeScript. We are shipping types together with React Native. And we sort of took a closer look at our ecosystem and we thought like, we want to support TypeScript more. Next one on Android Kotlin. So it's currently fully supported. Actually, you can use Kotlin all over the places in React Native, I think the talk before will actually tell you a little bit, a lot more about it, so make sure you stay tuned. Our website is also fully migrated and bilingual. So all the examples on React Native .DEV are both in Java and Kotlin. And you can fully use the one you want and the template as we did for TypeScript. We might also update the template to use Kotlin. We haven't done this yet, but this is set to open sometime in the future. And last one, Zwift. Well, a lot of IS engineers are asking us to use Zwift, and yeah, this is a little bit more complicated because of how Zwift and C++ interoperate. I hope to have answers for this in the future. We're keeping a closer look at it and hopefully we'll know more.

So timeline. So what is happening and when? I mentioned some things like some versions of React Native, but let me recap them. So we started early this year, like the rollout of the new architecture started actually this year with React Native 68. That's the first version of React Native which supports those new APIs. Then in React Native 69 we actually added React 18 support. These are a little bit confusing, but effectively the way our React and React Native interact is that React Native decides which version of React to use.

6. React Native Versions and New Architecture

Short description:

The first version of React Native that supports 18 is 69. We ship bundled arms, with a lot of improvements on the experience related to the new architecture. We released new architecture on 68, with many improvements on build time and developer experience. In React Native 71, we simplified the template and removed all the C++ code. We want to hear from the community and collect feedback on the new APIs. To fully use React 18 and concurrent APIs, you need to be on React Native 69 and enable the new architecture.

And the first version of React Native that supports 18 is 69. So you need to be in 69 at least, you can't just change it. And we ship bundled arms, which I talked about before on 70, a lot of stuff and a lot of improvements actually on the experience related to the new architecture.

I don't have time to deep dive on all of them, but some of those points have actually been highly requested by the community. So we released new architecture on 68, and people came to us and told us, this is awesome, but it doesn't work for me because A, B, C and D. And we heard what people were telling us, and we developed a lot of improvements on build time, a lot of developer experience improvements, and so on. That made into 70. And into 71, we simplified the template a lot. As I said before, we removed all the C++ code. Essentially, now there is no C++ code at all, unless you really want to see it because you might have, I don't know, your crypto library, and you want to do your crazy stuff with C++, then you can opt-in and have C++ code that you are responsible of maintaining.

And then what's next? Well, today, Infinity and beyond because, as I said, we want to hear what works and what doesn't work for you. We want to hear from the community, like, yeah, this is valuable for me or this is not valuable. So please try those new APIs. They are still considered experimental. We are not enabling them by default. We will be doing that at some point, but in this stage, we are still collecting feedback and hearing from library authors, app authors, what is not working for them. I briefly talked about React 18 and React Native. Let me reiterate. Just to clarify the interactions between the two frameworks. If you are on React Native 67 or 68, you are effectively running React 17. Like, the version of React is 17. And some of those new APIs like star transition will not work. To fully use React 18 and all those concurrent APIs, you need to be at least on React Native 69. And you can't... You just can't change the React version. Like, React Native decides for you. And here the catch is that on 69 and 70, to use those new APIs you need to be on the new architecture. Like, you need to enable the new architecture to use concurrent React. If you try to use those APIs but you're not on the new architecture, they will just not work. They will be empty implementations and so on.

7. Exploring New APIs and Documentation

Short description:

To stay up to date with the evolving React Native ecosystem and framework, it's crucial to explore the new APIs and documentation. The official documentation includes explanations of the changes, guidelines for creating libraries and apps, migration support, and detailed design docs on the architecture. The new architecture simplifies the setup process for iOS and Android, allowing developers to easily try the new APIs by following specific instructions. Running the app with fabric set to true confirms the usage of the new architecture.

So, it's crucial that if you have a React Native app and you want to stay up to date with how the ecosystem is evolving and how our framework is evolving, you take a look at those... Yeah. At those new APIs. And what does it mean take a look at those APIs? We created a lot of docs. And we are still iterating on it and it's actually all about the docs. Because those APIs, which we released in 68, were actually available there for so long. Like, I think we added the fabric in React Native 64 or 65. But they were just not documented. I remember listening to this podcast, the React Native show, where folks were talking about like, yeah, some library are trying to use it, but don't know how they need to reverse engineer the framework code, which is not great. So that's why now we have an official doc. So you will find the new section on the website called the new architecture, where everything is explained why we did certain changes, how to create a new library, how to create a new app, and so on. And also, a dedicated section on migration. How do I go from a library or an app, which is non architecture compatible to to have the full support for architecture. On top of this, we now have a new section called architecture, which contains design docs on our our internals work and how the render works and so on. Like people, especially like if, for example, reanimated, which is a popular library, wanted to know how we work internally and what are the principles to follow and so on. So we took a stance and also wrote those docs the new up template, like whatever happens when you do and picks react native in it. My awesome app has been updated to let you try in your architecture easily. So what does this mean? It means that on iOS, instead of calling pod install, after you set up your project, you will call our city in Newark enabled one pod install. And this will reconfigure your project to let you try the new architecture. On Android instead, there is a file called Gradle dot properties, and they're Newark enabled from false to true. And you can just react native run Android, and you will be running the those those new APIs. Effectively, you will see on metro message that tells you like, Hey, you're running your app with fabric set to true, and so on. So you are effectively running the new architecture.

8. Working Group, Samples, and Open Source Tools

Short description:

We started the new architecture working group, which is a collaboration space for asking questions, sharing libraries, and discussing library migration. We also provide samples for app and library migration, as well as backward compatibility examples. We value feedback and want to hear migration stories to improve the APIs. The old architecture is still experimental, and we encourage people to try it and provide feedback. Our tools are open source, and we are committed to making them valuable for everyone.

Super quick on a couple of other things that we also did, because I see I'm out of time. But a couple of a couple of content more. First, we start the working group. It's called the new architecture working group. And this is similar to the react 18 working group we started a couple of years ago. And it's a collaboration space where you can ask questions, share your libraries, give updates on how your library is migrating to the new architecture and connect with other people which are also looking into those API's. It's if you open the working group, it looks like read only. But actually you can apply on the working group using the link below. And I'm going to review your application and send you an invite.

We also have samples, like stuff that effectively runs. So we have an app sample repo which contains multiple branches. And every branch explains to you how to migrate to one app from a given version of React Native, and so on. And every migration is done step by step. So you would see all the commits on how we enable the various stuff. We also have a library sample which contains examples on how to create a turbo module or native turbo module or fabric component which is backward compatible. So you can create something that works both in the old and in the new architecture.

And with this, I really hope that in the future, when I search React Native new architecture at some point, I will hear your stories like you will write about it and tell me like, hey, it was a complete mess because your folks missed here, here, and there, or talks were great or whatever. We really want to hear your migration story. We are iterating on this. We know some APIs are not as great and shiny as you like. And so, we did update some of them. So, that's why the old architecture is still experimental. And it's crucial now that people try this and tell us like what works and what doesn't work. Yeah. And I want to recall that all of our tools are actually open source. We are fully committed to this ecosystem. We spent a lot of time talking with partners, with library maintainers. And we just want to make those tools as great as possible and as valuable for everyone. And thank you very much for listening. Thank you very much, Nicola.

9. Switching to New Architecture and Dependencies

Short description:

When is a good time to switch for existing apps to the new architecture? The timeline for switching to the new architecture and dependencies are crucial considerations. While TurboModules are backward compatible and can be easily enabled, migrating UI libraries can be more challenging. It is recommended to review the list of dependencies and ensure that the majority are migrated. Unmaintained libraries pose a security risk and present an opportunity to evaluate and potentially update or revive them.

It was like you enlightened us about the new architecture. And yeah, we do have some time for questions. Yeah. It's we have some questions and I'll start straight away. When is a good time to switch for existing apps to the new architecture or what's, in your opinion, the timeline for switching to the new architecture or what dependencies? Yeah. So this is quite a crucial question. I would say, so when we started, beginning of this year, we had a lot of libraries, like a lot of popular libraries, which had no support for Fabric or TurboModules, which made immigration really hard, especially on Fabric. TurboModules are really backward compatible in a sense that you can just enable them. And if you have libraries which are migrated, or libraries which are not migrated, they will work well each other. On the UI side, instead, it's way harder. And we're actually taking a lot of effort on this side to let migrated and non-migrated libraries work well together. Hopefully, there will be more on this topic in the future. But as of now, my recommendation is to go through your list of dependencies, and see most of them, like a lot of them are actually migrated. For example, Reanimated, React Native screens, they're all migrated, and they have a version which is Fabric compatible. But you might sometimes use a library which is unmaintained. Well, that's unfortunate. I would say it's probably also an opportunity to take a stance at which libraries you're depending on, and depending on libraries which are not maintained, it's generally a security risk. So maybe it's also the opportunity for apps to take a look at what they're depending on and cleaning up some of those or potentially reviving some of those libraries, forking them and updating them.

10. Migrating Libraries and Backwards Compatibility

Short description:

Many libraries have migrated to the new architecture, indicating traction from the community. While the new architecture is considered experimental, it is production ready and being iterated upon. Backwards compatibility is available for non-UI components, but compatibility with fabric requires additional considerations. Collaboration with Microsoft on tools like AlignDepth and RnxKit aims to provide information on library compatibility. The RnX kit is gaining strength to support the new architecture.

I totally agree with you. I saw so many great libraries migrating to the new architecture, like reanimated, React Native SVG, gesture handlers, and you also named the screens. There is a lot of traction also from the community, but I think that as a junior developer or someone that has no understanding of C++ or Kotlin, or the new architecture itself, it's really hard to just go and update something, right? It is, and that's also why we keep on considering the new architecture as experimental.

I would say, if you were to ask me, is it production ready? I would tell you, well, the biggest React Native app, it's running on it, so well, it is production ready. Is it easy to use? We are iterating on it. There are some rough edges, for example, on 70, build time on Android was like, people told me, I need to wait half an hour to build. On 71, we used build time so much, like literally like now it's a matter of seconds. And those changes require feedback loop from your end and us also having time to fix them. All right.

And I think we have a question which got answered during your talk. Do you need to migrate all the libraries to the new architecture? It is backwards compatible. And I think that you mentioned about backwards compatibility. But if you can add more. Yeah, let me reiterate. So the backward compatibility story is as I said, a little bit more complicated on the two components, on the two pillars, native modules. So whatever is not UI is backward compatible. You can use once you turn on the new architecture, you can use turbo modules or legacy native modules, as we call them on the UI. Instead, if you enable fabric, like if you enable the new architecture and you have a component which is not compatible with fabric, you will see like a purple box that tells you like a here. I should have rendered something, but this is not fabric compatible. So I can't render it. This gives you immediate feedback if something is going on or not. But we are also working with folks at Microsoft on a tool called AlignDepth or Depth Check. You might have heard it's part of this collection of tools called RnxKit, which is a set of tools that Microsoft is building. And they are like, we are collaborating and iterating on providing more information on which libraries are effectively compatible with new architecture and not. On the React Native libraries directory, there is a label that tells you like, hey, this is compatible or not. But yeah, I mean, once this whole thing will be stable, trust me, there will be an easy way to know which libraries are compatible and which not.

Yeah, that was a great answer. And I also saw Lorenzo tweeting, yesterday I think, about the line depths and the RnX kit. It's like getting stronger and stronger, I would say, to support this new architecture. I think I have one more question, just quickly.

11. Performance and Migration to New Architecture

Short description:

For us, the new architecture has been worth it in terms of performance. It allows us to develop features like pre-rendering that were not possible before. However, enabling the new architecture does not guarantee immediate performance gains. It depends on your use case and libraries. Migrating to the new architecture will be necessary to benefit from new libraries and APIs.

In terms of performance, did it worth all the work you have done? So for us, yes. We were able to develop a feature like pre-rendering or like, do stuff that the previous architecture was not possible. Like, would not allow us to do.

Now people come to us and say like, yeah, enable the new architecture and expect, like, you know, spikes of gains here and there. That's not the case. Like, the architecture is a, as I said, is a foundational stone for tools that you have to build on top of. Like, if you were doing something which was the bridge, then doing that with the new architecture, doing that synchronously going from JavaScript directed to C plus plus, will give you performance gains. But that depends on your use case. It's not that there is no immediate performance gain out of it.

And yeah, it really depends on your use case, on your libraries, and what you're doing. And we will see more and more libraries that will use those new APIs, and you will have to migrate to benefit from from those new libraries. Great. Yeah. Thank you very much. Thanks a lot, Nicola.

Check out more articles and videos

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

React Advanced Conference 2023React Advanced Conference 2023
29 min
Raising the Bar: Our Journey Making React Native a Preferred Choice
At Microsoft, we're committed to providing our teams with the best tools and technologies to build high-quality mobile applications. React Native has long been a preferred choice for its high performance and great user experience, but getting stakeholders on board can be a challenge. In this talk, we will share our journey of making React Native a preferred choice for stakeholders who prioritize ease of integration and developer experience. We'll discuss the specific strategies we used to achieve our goal and the results we achieved.
React Finland 2021React Finland 2021
27 min
Opensource Documentation—Tales from React and React Native
Documentation is often your community's first point of contact with your project and their daily companion at work. So why is documentation the last thing that gets done, and how can we do it better? This talk shares how important documentation is for React and React Native and how you can invest in or contribute to making your favourite project's docs to build a thriving community
Vue.js London 2023Vue.js London 2023
11 min
The Hidden Cost of Open Source
There is a cost that many companies don’t consider when using open source. It can cost a lot of money and time to keep upgrading sunsetted versions.Open source is free for companies to use until the author sunsets a version.These are some best practices that we we recommend when considering open source adoption:        - Who is the author? Do they have a strong reputation that is going to be around for a long time? Do they have the resources to support an enterprise library?        - How much online support is there in the community for this library? How many dependencies are on this library?        - Does it have an end of life policy? What’s going to happen when they rev on a version? Will companies have an option to stay on older versions for a long time?        - What should you consider when migrating to a supported framework after a version has been sunsetted?
React Day Berlin 2023React Day Berlin 2023
29 min
Bringing React Server Components to React Native
React Server Components are new topic in community, bunch of frameworks are implementing them, people are discussing around this topic. But what if we could use React Server Components in React Native? And bring all optimisation features that RSC allows to mobile apps? In this talk I would present what we are able to do with RSC in React Native!
React Advanced Conference 2021React Advanced Conference 2021
21 min
Building Cross-Platform Component Libraries for Web and Native with React
Top Content
Building products for multiple platforms such as web and mobile often requires separate code-based despite most of the components being identical in look and feel. Is there a way where we could use shared React component library on different platforms and save time? In this presentation I'll demonstrate one way to build truly cross-platform component library with a unique approach of using React & React Native in combination.

Workshops on related topic

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