The New Architecture Is Here… What Now?

Rate this content
Bookmark
Slides

The React Native new architecture has been "coming next year!" since 2019 - but, this time, it’s actually here! So… what now? What do we actually need to do, to benefit from this all new shiny tech? In this talk, I want to provide some insights and in-depth analysis of the current state of the migration path to the new architecture, to help you and your team evaluate and estimate when and how and how long it will take you to get to the next level!

Lorenzo Sciandra
Lorenzo Sciandra
22 min
21 Oct, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

The Talk discusses the new architecture in React Native, highlighting its benefits such as native interoperability, concurrency, faster startup, better memory management, and improved code quality. The migration process to the new architecture involves refactoring, codegen, and extending native interfaces. Challenges include typing, configuration, and migrating third-party libraries. React 18 introduces automatic batching and compatibility with the new architecture. Microsoft is expanding React Native to target desktop platforms and has a dedicated open-source tooling repository. The Talk emphasizes the importance of open-source contribution and setting healthy boundaries.

Available in Español

1. Introduction to the New Architecture

Short description:

I'm here to talk about the new architecture and what it means to start using it. The main difference is the disappearance of the bridge, enabling native interoperability and concurrency. This leads to faster startup, better memory management, and improved code quality. The new architecture also provides a better developer experience. Let's start with the documentation.

All right. Thank you, Kathleen. I like the metaphor with Gandalf for two reasons. One of them is that in a very famous point of the Lord of the Rings, it kind of like just almost dies and just before doing that, it's like, run, you fools. So, I feel I'm in that phase. I don't know if I'm going to show up next year with like super white hair and white robe, but, you know, we can make things happen. We'll see about that.

Anyway, I'm here to talk about the new architecture, like we've had Gand, we've had Nicola talking about it. So I'm kind of here answering the, you know, the next logical question, which is like, okay, so we have the new architecture, what now? So Kathleen already did a great job introducing me. I just wanted to reiterate I'm a senior software engineer at Microsoft and I've been a React native core maintainer and a releaser since 2018. So, yeah, I've been around for a while.

And because we had Nicola and Gand doing a really great job kind of like going through the concepts of the new architecture, I'm just going to kind of cheat my way through my first few slides by saying, oh yeah, let's just, you know, this is the old architecture. We all know what it looks like. Absolutely we all do know. And then, boom, here's the new architecture. Yeah, we don't need to know literally everything about it. It's fine. Just let's recap very, very quickly like the main differences. So, the main one is the bridge disappearing. And that means no more communicating through JSONs, no more bottleneck. This means native interoperability and concurrency, which is great and enables all this fancy reg data and stuff. Because we have a better structure, it means that also we have a faster start up because now the native components get only loaded when it's actually needed. We have better memory management because now the OS knows more about what's going on within this cross platform app. And then also we have, well, by, you know, having more structure and having ties safely to things like Codegen, we have also, you know, less clashes, better code quality in general. And technically, through the new tooling, we also have a better developer experience. And on paper, this is great. You know, we have Gantt, we have Nikolai pinning it up and, you know, I'm an engineer. So the first thing that comes to mind whenever I hear something saying something positive is, huh, okay, when do I press X on this conversation? So let's try to kind of do that. Let's see actually what does it mean to start using the new architecture. And the first starting point, the easiest place to start is actually the documentation.

2. Migrating to the New Architecture

Short description:

The documentation for migrating to the new architecture is well done. The process involves refactoring, adding codegen to the package, running a command, and extending the native interfaces. For apps, the migration process is slightly more complicated but offers more granularity. From version 71 onward, the steps become smaller and more achievable. However, there are complications to consider, such as typing and the requirements from CodeGen and modules for the type system.

So if you go on the Rackintive website, in the guide section, there's a beautiful page called Migrating to the New Architecture. And actually, I wanted to take a second and give a huge round of applause to Ricardo, Nikolai, and the rest of the team because, like, the documentation is pretty well done. And, you know, usually, it sits fairly low in like the list of priorities. But, like, spending time on having proper documentation is very, very good.

And also, just keep this in mind from here onward, for this first few slides, the premise is that we are on 67, so the first version, the last version before new architecture and we want to migrate to latest, so the version that Nikolai was using earlier, so 71. Why that? You'll see in a second.

So if we look at that documentation and we're like, okay, I have a library, I need to migrate it. What we end up having in terms of load of things that we have to do is pretty much this. So we have our library, we need to do a bit of refactoring, we add the codegen to the package, and then through that we run a command and we have the native interfaces and now we just need to extend them. So it should be fairly straightforward. For apps instead, things get slightly more complicated but in both good and bad ways. Like, oh yeah, yeah, the drawing is much more complicated, it has more colors and stuff, but at the same time, has a level of granularity which, you know, allows us to kind of like migrate one part first and the second part second. But actually, this is where the things that Nicola was mentioning earlier with 71, like things are going to change because now, from 71 onward, pretty much like that entire draft reduces to this, which is much smaller, the steps are much more achievable. I hope you can read it, by the way. It's slightly small, but like the purpose is like big graph, smaller graph. So, we're fine. Now, what go wrong? Okay. So, we have documentation. We have seen that more or less things are getting easier. We have the steps, you know. Fine, everything is going to be absolutely perfect. Well, I already told you, I don't trust anything positive in the world, so let's see actually some of the complications. Now, for foreshadowing purposes, I called these challengers. Why? We'll see in a second. But, basically, I've selected three which I think are fairly important. And the first one of them is typing. As I was mentioning earlier, the new architecture pretty much forces you to type your code. If you're using vanilla JavaScript, you apparently like a lot of pain but like please just use TypeScript or Flow. And once you start looking into the requirements from CodeGen and to modules for your type system, you realize that okay, on a surface level, like all the main types, they all work just fine. But then you start looking into the more advanced things and like, oh, hang on a second.

3. Challenges and Evolving Trends

Short description:

I cannot have union types or custom types. The types must be read-only and have the exact same signatures. Things have been evolving, as Nikola mentioned, with improvements in TypeScript support. Meta and Microsoft are collaborating to make it better for everyone.

I cannot have union types. I cannot really do custom types. The types must be read only and they need to have the exact same signatures and things start to get a bit more messy. Things are evolving in the previous version of this talk like the exact signature that add a red dot because I wanted to showcase that you really need to add it. But since then, things have been evolving, as Nikola mentioned. They're really listening. They're really changing things up overall. So, yeah, things are evolving for the better. And also TypeScript support is feeling better technically. This is something where Meta and Microsoft are trying to collaborate. And we have a huge set of PRs that we're sending back and forth to try and make it so that it's better for everyone because, you know, most people use TypeScript these days.

4. Newark Configuration Challenge

Short description:

The second challenge is the Newark configuration, where certain things don't quite gel properly. For example, the command to run the code gen differs between platforms, requiring attention. Refactoring the library may be necessary, including moving the require Native component to a separate file.

The second challenge is what I would call the Newark configuration. And what I mean by that, let's go back to the documentation a second, is that if you look closely, when I said refactoring for your library, I said, oh, yeah, it's going to be fine. Actually, there's a bunch of stuff that you need to do. And if your library uses any of this, it basically means that you need to change your library. Especially, like, even if you don't have, like, most of these things, like the require Native component literally requires you to move that part into a separate file. So even if you're like, oh, I'm fine, I shouldn't do anything, yeah, no, actually you still need to do the require Native component one. And also on the topic of Newark configuration, we have a combo here because, like, there are still certain things that don't really quite gel properly. Like, for example, the command to run the code gen is different between the two platforms and it's not even, like, oh, one is a yarn command and the other one is actually, you know, a Gradle site command. So it's kind of like, oh, okay, yeah, these things needs to be addressed.

5. Third Party Libraries Migration

Short description:

The third challenge is the migration of third-party libraries to the new architecture. Currently, only eight plus one libraries are fully migrated, with seven more in progress. This creates a disparity between the number of libraries documented on React Native Directory and those migrated to the new architecture.

And the third one which is probably the one that also Nicola was teasing earlier is the third party libraries. And what I mean by that is that if we go on React Native Directory which is like this website where, like, a lot of libraries are documented and you can quickly find out the ones that you may need. We have over 1,000 libraries there, right? And now if we go into the React Native New Architecture Working Group that Nicola was mentioning earlier and we look at the dedicated third party libraries section, we'll actually see that only eight plus one libraries are fully migrated to the new architecture which is like a bit smaller than the one thousand we have on the other side. And, okay, to be fair, like, there's actually seven more that are in progress currently in there and this is not by any means like a full one to one like all the libraries are documented in both places, but still like, it's a bit of disparity in terms of like where we should be and where we are right now.

6. React 18 and the New Architecture

Short description:

React 18 introduced automatic batching, which optimizes performance but can make it harder to understand what's happening. When migrating to React 18, ensure your state management library is also compatible. A blog post on frontend development provides in-depth information on React 18 support and how it interacts with React Native. The new architecture has ripple effects to consider. While there are no benchmarks available, trust that the new architecture is good. Microsoft, a heavy user of React Native, has five apps in their showcase.

And then, oh, what's going on here? Oh, no. The foreshadowing is happening. There's a new challenger. And, yeah, basically what I wanted to talk a second about is React 18 because, yeah, React 18 is great, absolutely. You know, React used to be like this very smooth linear like logically linear thing and you're like, okay, yeah, if I render something up, everything goes, and you render the things down and, you know, it's just one direction and you kind of like know all the steps of the way. And then we got React 18. They introduced automatic batching which is perfect, it's an optimized thing, but also at the same time that means that the library is saying, you know, I know how to optimize stuff, and that implies that you don't really know what's going on sometimes. So, basically, when you move to React 18, which is a requirement for Fabric, you need to also migrate your state management library to a newer version that is React 18 compliant. Like literally unless your library says, yes, I know how to handle React native stuff, like, look into that please. And to help with that, I actually found this very good blog post. I don't know who wrote it, but like is this frontend something something blog post. And like this blog post really goes into depth about this React 18 support, automatic batching and stuff. And also, as we were mentioning earlier, hey, I think I've seen that earlier. Yeah, like how React and React 18 and React Native interact with each other is a bit more complicated. It's not just about, oh, the version that I set on my package.json. So, you know, when you start thinking about the new architecture, you also start need to think about all these ripple effects. And, you know, in the sake of time, like let's just say there's a bunch of more stuff. But please trust me, the new architecture, it's good. It's good. It's good. Absolutely. And also, since this also came up as a question earlier, yeah, so no benchmarks. The reason for that is that there are a few ones that are popping up. But honestly, I don't feel confident enough in any of those React team, I'm looking at you, because, yeah, there are kind of like edge cases and things like I don't really feel like I can properly show benchmarks like, oh, this is how bad it is. So going into the last part, okay, so we have seen that there's implementation for that. We've kind of looked through it very quickly and now we have an idea of what the challenges are going to be. How do we plan for all of this? So as I mentioned, I'm from Microsoft. And Microsoft, we use React Native a lot. This is from the showcase. And there are five apps.

7. Migrating Libraries and Native Code

Short description:

To enable your app to migrate to the new architecture, start by migrating your libraries or extracting custom native code into a library. Check the React Native Directory website for libraries that support the new architecture. Consider using React Native Library, RNT Turbo Module Sorter, and React Native Test App for a smoother migration process.

You may have seen some of these. I don't know if you, you know, are a gamer or like you work in general. Like those kind of things tend to show up. I'm sorry if you need to use Teams, but no, it's fine. No, I'm joking. I'm joking. But like this is a subset. To be, like, to be completely serious, this is a subset. Like we could have done like three more rows, but then it would have felt like React Native and then Microsoft and then all the way down there, everything else. So we're like, all right, let's just pick five. But basically what this means is that internally I need to come up with some ideas that I can share with everyone else. We're like, okay, this is how we're going to do it because these projects are massive and we need to make sure that things work. So what I come up with is this kind of thing because I like graphs. You may have realized that by now. And I know it's small so let me try to make it slightly bigger, probably still unreadable. But the basic gist of it is that you want to be on the latest React Native version available at any point in time because again as Nicola was saying, we're still trying to make things better every single time and every occasion that we have. But then, because the libraries are what you need to migrate in order to enable your app to migrate to the new architecture, that's the first step. Like if you have a library, migrate the library. If you don't have a library but you have custom native code, extract it into a library and then migrate that separately. Start from the libraries. That's pretty much it. In the React Native Directory website that I was mentioning earlier by the way, there's now a flag in the filters to show like libraries that support the new architecture. So that should help you evaluate, okay, I'm using these libraries, let's see on the website if they show up in this list. If not, let's migrate or like interact and let's understand what we can do to help migrate those. And especially, if you're looking into extracting your native modules, please also take a look at React Native Library or RNT Turbo Module Sorter, those two libraries help you really kick off your, you know, the new version Turbo Module Supported Library. And also, you can use React Native Test App, which is a library from us at Microsoft as a test app because it makes things so much smoother. It's already supporting your architecture, you just switch a flag and it works. And, yeah, that's more or less the plan that I'm kind of like throwing around internally. I hope it will help you too. But of course, there's one big question which is like why start now? Like clearly, things are still evolving.

8. Feedback Loop and New Architecture

Short description:

The feedback loop through the dedicated repo is something unique. Take this chance to report issues and improve React Native. There's a separate discussion on how to improve React Native. The new architecture is awesome and will be a big deal. Prepare for it and enable OS libraries to migrate. Try fast, fail fast, and tell everyone.

But to be honest, as someone that's been around React Native a lot, even like trying to be a maintainer so communicating a lot back and forth, I can tell you that right now, the feedback loop that exists through this dedicated repo is really something else. Like, the fact that you can report something and like, hey, by the way, I don't think this works really well, smooth out. Like, it's not something that happens every day. Like, meta has not been like this forever. And maybe they will not be in the future. So take this chance while you can.

And talking about taking your chances while you can, right now, there's also a separate discussion about more general like how can we improve React Native. But this is literally only on Tuesday. So take your chances. Go there. Be a React Native team. This is what I would like for you to do better. Like, it's good. They're very listening mode. They're very proactive in helping out. So take this chance.

So, closing in the off, we have 30 seconds. So, yes. Yeah. The new architecture is pretty, pretty awesome. Again, I kind of cheated here and just kind of like throw a couple of drafts at you, but please trust me. Like, from an architecture perspective, it's so much better. The second thing, which is what I hope you can go back to your managers and peers to say, is like, hey, by the way, the new architecture is going to be a big deal. We need to prepare for it. And then, of course, enabling OS libraries to migrate to the new architecture is key. Like, you need to have your libraries working within your architecture to be able to migrate yourself. So if I had to sum it up, if you need to write a tweet about it, it's just this. Try fast, fail fast, and tell everyone. Because, like, if we don't help each other, this is going to be much messier. And thank you, everyone.

9. React Native at Microsoft

Short description:

We love React Native and we're expanding it to target desktop platforms with React Native Windows and React Native macOS. We have dedicated teams and an open-source tooling repository called RNX kit, which includes a dependency aligner and other critical tools. We've also added tree-shaking to Metro through one of the plugins and developed React Native desktop, which has a lot of potential in the future.

Thank you. Wow. Thank you so much. Lorenzo. Yeah. And again, the work that you put in inside this entire React Native community it's, yeah, it's huge. Thank you. Huge. And yeah. Thank you very much.

We do have some time, right, for questions? Yeah. So if you haven't already, just go ahead to Slido to one to four. Don't forget about the old track. Ask the question there and we are going to go through them. Otherwise, if there are no questions available yet, let me check it out.

Meanwhile, I have a question prepared for you. I like questions. You're talking about Microsoft and React Native ecosystem inside Microsoft. If you can give us more things maybe that you haven't touched or what's actually happening inside Microsoft in terms of React Native? Oh yeah. I mean, as I was saying, we love React Native and we're doing a lot of things. Maybe some of the most famous are, you know, we're expanding it in terms of platforms, you know, React Native core as iOS and Android. At Microsoft, we actually believe so much in that idea that we've created React Native Windows and React Native macOS to target to the desktop platforms. So we have dedicated teams for those. And also, I kind of tease that like we have an entire set of tooling that we are open sourcing for React Native developers because that's what we have people using internally. So we have the RNX kit repository, which is pretty much where we try to put all our tooling. So for example, you would find like a dependency aligner in there and other critical tools. We add the tree-shaking to Metro through one of the plugins there. And also we have the React Native desktop, which is like this sandbox up, which is pretty, pretty good. Like we are investing a lot into it because we think it has a lot of potential in the future. That's great.

10. Open Source Contribution and Dealing with Stress

Short description:

RNX kit is amazing. Find a small project to contribute to and establish direct communication with the maintainer. Every contribution counts. Establish healthy boundaries in open source and don't rush. Stress in open source is common, set boundaries and don't feel the need to respond immediately. The new architecture opens opportunities for optimizations that are not achievable with native code.

Yeah. RNX kit, it's amazing. I really would like to invite everyone to check it out, especially if you'd like to upgrade your React Native application, you should do so.

I do have one more question. What's your advice for open source newcomers? Or, yeah, because you are the best person to ask, if you can give us, like, I'm a newcomer to the open source community, what I should do first and what do you think it's, what's your advice here? Yeah, I mean, I think open source can really feel like a massive thing, and React Native repo, the repository in particular, is so massive that people can get scared off quite easily. My suggestion is, like, find a small project that you use, like, let's say a library, a React Native library, that you use, but it's, like, let's say has less than 100 stars, like, something small, and try to establish a direct communication with the maintainer. Like, be like, hey, I would like to learn open source, I would like to help out with this library, and, you know, usually what happens, especially with these smaller libraries, is that the person is really able to, you know, walk you through and give you some understanding of, like, what's needed and how you do, you know, contributions, and also, like, the other half of this is every contribution is a good contribution. Like, it's not like, oh, I submitted, I fixed the typo, and that doesn't count, no, literally everything, that's how I started. There was that website that showed your first ever PR, and it was like, I fixed the typo in a ruby website or something, it's about getting started and learning how the tooling works, and then all of the things will happen over time, just don't rush it.

Okay, that's great, and as a follow-up question to this, I mean, let's assume that you know how to get started with open source, you have contributed a little or quite a lot, how to deal with the stress in open source, and yeah, maybe the imposter syndrome, but the stress in general. Oh, yeah. Doing open source can be really stressful, like, I'm kind of like, in the one percent of people that, like, whenever I click release, I don't want to think about the download numbers because if not, I'm never going to release anything. But like, it's hard. You need to establish healthy boundaries, and like, don't get sucked into the actual culture of like, oh, I need to do it every day, I need to be immediately responding to every issue, like, it's fine, it can wait. Like, unless you're working on, for some reason, an open source project that like, keeps an hospital alive, it's fine. If it takes one week too long, it's okay. Like, it, you know, it's a lot about creating boundaries, I think. Speaking about hospitals, just a side parenthesis here. We do have a talk on Monday about public toilets in the UK, so definitely you should check it out, which is open source, by the way. It's, yeah.

So, thank you so much, Lorenzo, we unfortunately ran out of time. If you'd like to ask any question, just find him out. Actually we have one, okay. What are the opportunities coming from the new architecture that you're the most excited about? Oh, okay, yeah. I'll try to be brief, because we are out of time. But I think the new architecture especially opens the door for optimizations that normally with native code are not achievable. So I can foresee a future where some React native based apps and components are actually faster than their native counterparts. That's technically possible so I'm just looking forward to see that happen in the future. That's great, yeah. Thank you so much and once again, just give a round of applause to Lorenzo.

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

Scaling Up with Remix and Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Full Stack Components
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
Understanding React’s Fiber Architecture
React Advanced Conference 2022React Advanced Conference 2022
29 min
Understanding React’s Fiber Architecture
Top Content
We've heard a lot about React's Fiber Architecture, but it feels like few of us understand it in depth (or have the time to). In this talk, Tejas will go over his best attempt at understanding Fiber (reviewed by other experts), and present it in an 'explain-like-I'm-five years old' way.
Raising the Bar: Our Journey Making React Native a Preferred Choice
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.
Opensource Documentation—Tales from React and React Native
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
The Eternal Sunshine of the Zero Build Pipeline
React Finland 2021React Finland 2021
36 min
The Eternal Sunshine of the Zero Build Pipeline
For many years, we have migrated all our devtools to Node.js for the sake of simplicity: a common language (JS/TS), a large ecosystem (NPM), and a powerful engine. In the meantime, we moved a lot of computation tasks to the client-side thanks to PWA and JavaScript Hegemony.
So we made Webapps for years, developing with awesome reactive frameworks and bundling a lot of dependencies. We progressively moved from our simplicity to complex apps toolchains. We've become the new Java-like ecosystem. It sucks.
It's 2021, we've got a lot of new technologies to sustain our Users eXperience. It's time to have a break and rethink our tools rather than going faster and faster in the same direction. It's time to redesign the Developer eXperience. It's time for a bundle-free dev environment. It's time to embrace a new frontend building philosophy, still with our lovely JavaScript.
Introducing Snowpack, Vite, Astro, and other Bare Modules tools concepts!

Workshops on related topic

AI on Demand: Serverless AI
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Top Content
Featured WorkshopFree
Nathan Disidore
Nathan Disidore
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
Introducing FlashList: Let's build a performant React Native list all together
React Advanced Conference 2022React Advanced Conference 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
WorkshopFree
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
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
Detox 101: How to write stable end-to-end tests for your React Native application
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Yevheniia Hlovatska
Yevheniia Hlovatska
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
How to Build an Interactive “Wheel of Fortune” Animation with React Native
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
Workshop
Oli Bates
Oli Bates
- 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
Effective Detox Testing
React Advanced Conference 2023React Advanced Conference 2023
159 min
Effective Detox Testing
Workshop
Josh Justice
Josh Justice
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
Prerequisites
- 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
Deploying React Native Apps in the Cloud
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
Cecelia Martinez
Cecelia Martinez
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.