The 1.0 is a Lie

Rate this content
Bookmark

Whenever there's a conversation about working on React Native, versioning and release cycle usually arise as one of the pain points. But why is that the case? How complicated is it to create a new release of React Native? Surely it looks similar to the release process you are using... or not! During this talk I'll walk you through the many steps and complexities involved in publishing a new version or React Native, and I'll challenge one fundamental idea – that 1.0 is the solution to all problems. I hope you're ready, it's going to be wild!

22 min
02 Aug, 2021

AI Generated Video Summary

Welcome to a talk on React Native releases, where the speaker shares their experience and perspective. The complexities of React Native releases are discussed, including the challenges of manual testing and conflicts with dependencies. The involvement of the community and improved communication with Facebook are highlighted. The speaker also mentions the incremental automation of the release process. React Native 1.0 is seen as a promise of a finalized product with long-term support. The long-term plan for React Native's new architecture is mentioned, with a focus on minimizing breaking changes.

1. Introduction to React Native Releases

Short description:

Welcome to my talk on React Native releases. I've been a developer in React Native for the last three years and a releaser since version 57. This talk is based on my experience and point of view. I'm interested to know which version of React Native you've been using and how long you've been around. We'll also have a Q&A session after the presentation. Let's dive into releases and discuss why we do them.

Welcome, everyone. I'm so glad to be here and talking with you all. And today, I'm going to talk to you about something that is really near and dear to my heart, and to probably most of you React Native developers.

So let's jump right into it. I'm Lorenzo. You may know me as Kalset. I'm a software engineer at Formidable for the U.K. office in London, where I live. I'm a React Native Core maintainer, which is maybe why you may know about me, and also an organizer for Provided As Is, which is a meetup here in London for open source maintainers, which I jokingly usually call group therapy for maintainers.

You see, today I want to talk about releases, but I want to make sure that we start with the right foot. So to give you a bit of context, I've been a developer in React Native, using React Native, for the last three years almost. So I've been around since version 30, more or less. And I've been a releaser since version 57. That one you see over there, in particular, is my first-ever release. This is to say that I've been around quite a while, but please, just make sure to remember that this talk is from my experience, my point of view. So don't take anything I say as official.

Also, I want to know about you. I know we have a chat going on. I'm going to read all your answers and your comments while doing the presentation. But please let me know which version you've been using since how long have you been around for React Native. It's really interesting, usually, to know how far back we can go. Sometimes people are even from version 20. And also, remember that if you have any questions for me, we have a Q&A after this, and we have a speakers' room, and there's also an advice lounge. So there's plenty of time to ask me anything that comes to your mind while seeing this presentation.

So let's dive into releases. And the first bit that I want to talk about is why do we do releases? It sounds quite simple, right? We want to provide somehow our code to other people so that they can use it, right? It's not just that. Technically, when you expose your code on GitHub, for example, the packages.json NPM allows you to technically point to any given repository without the need of a strict release in the NPM registry. But we do releases. We do versioning because we want to introduce a level of staticness. We want to say, okay, this is a version.

2. Code Versioning and Reproducibility

Short description:

This is a version of the code that I've decided is good enough to be given out as a package. I prefer strict staticness for reproducibility, especially in the mobile world. It allows me to test previous versions of the app with precise code.

This is a version of the code. This is a package that I've decided is good enough for it to be given out as a sort of a unit. It's that. Also, this is one of the reasons why the dynamic dependencies, the use of the cara for some dependencies, I don't really like that. I prefer strict staticness. Why I like that? Because it allows reproducibility. In particular in the mobile world, I really want to minimize the possibility for me to not be able to get to the point in time to that snapshot precise for that code. For example, if I need to test the previous version of the app I released, I need to make sure that the code and every single piece of code I'm using, or at the most part, as much as I can control, is precisely the same so that I can work on it.

3. Different Release Examples

Short description:

Let's start with a simple example: I push my website code to GitHub, triggering a Git hook that leads to Netlify doing its magic. For a more complex app, we branch from master, generate a tag, and run a series of triggers in our CI tool. Once it's all green, the app is bundled and sent to the stores. The React Native release pipeline is even more involved, with multiple steps and considerations.

That said, how do we release? To sort of like tackle this question, I've decided to go for some examples. So, let's start with a simple one. Calcet.dev is my website, and it's awful. Please, please, please don't go. Don't look at it. It's ugly. You're going to hate me for going there. So, don't hate me. Just trust that it exists. I push it up on GitHub, then there's a Git hook that gets triggered, and that leads Netlify to do its magic, and then the code is ready. It's out there. It's released, and it rides into the sunset.

Now, of course, this is really simple. Let's try to go for a better one, for one that comes from my past, in my experience. This is potentially an app I worked on, I don't want to say too much about it, but basically we had a bunch of commits. Whenever we wanted to do a new release, we do a branch from master. We generate a tag on this new branch. We push this up, and we have a CI tool that runs a series of triggers that are getting triggered by this tag. And then once it's all green, and it's all done, we have an app ready to be bundled, ready to be sent to the stores, where the users can download it and ride into the sunset.

And now React Native, this is the hard example. So we run a script, and it runs... It just goes into the sunset. Yeah, okay, of course. That's not it, right? Yeah, of course, it's not. This is the real pipeline for releasing a version of React Native. Probably you're not able to read all the steps and don't worry, it's fine. This is just to showcase how much work goes into one or any given React Native release that we do currently. In particular, this is what we've used for 62. And also I had to squash together some steps in order to make it readable. One thing in particular, that I want to point out, is that the step I was showing you earlier is actually over there.

4. Complexities in React Native Releases

Short description:

The complexity of React Native releases stems from various factors. In open source projects, caring for the community and ensuring developers can consume releases effectively is crucial. Manual testing is necessary due to the fast-paced codebase and dependencies on other libraries. While Facebook owns React Native, the community manages releases, which has its challenges. The codebase moves quickly, and patch releases can be difficult due to conflicts. Despite these complexities, improvements are being made, driven by a commitment to caring for the community.

It's one of them, but it's really, really far ahead and there's a lot else going on. And I'm pretty sure that right now what you're asking yourself is why is that complicated? What's the complexity? And I can sort of like tackle two different series of complexities. The first kind is actually related to a series of things that happen in any sort of like medium to big open source project. Like these are generic complexities that most of us doing open source may face. For example, the fact that you care about the community. It may sound weird, but basically whenever you care about your community, whenever you do a release, you want also to produce the material so that your developers, the developers using your library, can actually consume it well. So in React Native, in particular, where we feel strongly about it, we have the changelog blogpost, we do diffs so that UpgradeHelper can show what you need to do, we have the documentation and a lot of other things. And also we do a lot of manual testing because yes, we trust CI, but also we don't. Also, the codebase moves really, really fast. In particular, in React Native, we have around 400 commits landing every month, which makes, you know, it's a challenge to keep up with that pace. And in particular, talking about code moving fast, since React Native depends on React, for example, depends on the Android and iOS ecosystems, we also need to keep moving fast enough so that we can catch up to all these other libraries. It may sound trivial, like, oh, well, React, you just need to bump the version library, right? Well, not really. For React Native to use a specific version of React, it needs to have a sync commit where some manual work is involved. And I left there an example. But talking about React Native-specific complexities, I've sort of, like, tackled two in this slide. One, which is probably the one there's most misconception around, is that Facebook is the owner of React Native, but the community manages the releases. And this is something that, and I'll talk a bit more about it later, like, it's been improving, but Facebook internally, in their monorepo, they use React Native. Like, they don't do React Native in it, so their experience of the code is different. Also, because the code of React Native is not open source first, as it happens for React, but it's a mirror of the code they have in their monorepo, when a person from the React Native team does a commit internally, then that gets replicated into the master branch of the open source version without going through the standard PR procedure. It doesn't go through the same CI. So sometimes, because the CI internal and the CI external are different, sometimes the CI external may break. And also, Facebook can always have the last word or the last say. Or they can decide something about release, and we have to keep up with these new requirements. Also, because as I mentioned, the codebase moves fast, and the release process goes through branches, so per each stable release, we do a branch. Sometimes it's hard to do patch releases. So if, let's say, 62.1, we wanted to cherrypick a commit, but this commit landed, let's say, two months after the point in which we cut the branch, cherrypicking it, which is a procedure in Git to take a commit and reapply it into a branch, may lead to conflicts. So that introduces a bit of complexity. So, as I mentioned, while there are these complexities, in particular the Facebook aspect, it's improving, like it's improving a lot, and I'm going to mention a bit more about it in a bit. But now, let's review those steps. As I was saying, a lot of work, a lot of iterations, a lot of steps that we do here are not strictly because of the code, but because we care.

5. Community Involvement and Improved Communication

Short description:

As you can see, we do a lot of things to generate community-related material, including documentation, blog posts, and diffs for the upgrade helper. We also do manual testing to ensure the code behaves as expected. We solve what we can and work around what we can't. One useful solution we implemented is the RC phase, where each release is tested before reaching point zero. We have increased the number of people involved in the process, and there has been improved communication with Facebook, thanks to Eloy from the Microsoft team. This increased involvement and communication are heartwarming and will likely continue to increase over time.

As you can see, all the yellow, it's all things that we do for generating community-related material, so the documentation, the blog post, the diffs for the upgrade helper, and also there's a lot of manual testing that we do to ensure that we can trust the AI, but also that we are reliably seeing the code behaving. You see, all of this is because – and this kind of started even before this comment, but this comment really highlighted the problem around direct-need-to releases and has really left the whole set of people working on this issue with the constant question in the back of our mind of, how do we solve this problem? And I think that the easier answer to this is that we solve what we can and we work around what we can't. You know, as I just mentioned, it's really complicated, so it's not like we can actually tackle every single problem. For example, when it comes to solving, one thing that we have done, which has been quite useful, is the introduction of the RC phase, as we call it. And some of you may be like, oh yeah, we've been doing that forever. No, actually the first time we did it was version 60, which even I was confused. I was like, oh, no, we should have done that even way before that. But also the reason why we started doing that is because each release is tested before getting to point zero and make sure that the cause is stable and all the major regressions are cut before that. Also, we've introduced more people to the process, like when I started doing this, it was basically just Mike, then I joined him, and usually it was either me or him, and then we got either Ciarpini or Hector Ramos to help us for the website and the documentation part, but now, and it's so refreshing and it's so nice to see, we have at least four to five people constantly involved in every release, and there are even more that are more like drive-by, they do one thing, they help, and then they sort of like go back to do what they were mostly focused on. And also, as I mentioned already before, there's a really good increase in communication with Facebook lately. It's not just a general thing, it's also thanks to Eloy from the Microsoft team, as I already just mentioned, and every other member from the Facebook team really stepped up. Eli in particular has been a big proponent of this new level of communication as like this issue highlights, he opened this issue about 63, which is a version that has not even been cut in terms of branching. And it's incredible because he took the time to already tell us like what's going to happen in that version, what work is required and some dates around it, which is incredible. To me, seeing this new level of involvement, it's really heartwarming and I can see this increasing more and more over time.

6. Automating the Release Process

Short description:

We are aware that we cannot fully automate the complete process of releasing, which is why we incrementally iterate on this process. The Upgrade Helper and Upgrade Support repo are ways for the community to come together and help each other in upgrading. We are constantly improving the process, such as improving the script for end-to-end testing and making the generation of new DEVS automatic.

Talking about work arounding though, for example, we are quite sure that it's never going to get to the point of an upgrade being a one line script. There are a couple in the CLI over time over the past few years they have tried to go for that route but in our experience, they never actually fully support or like leave your code base clean after being run. And that's why we've created Upgrade Helper which is a web app and I really hope that you all know what it is by this point it's been around for a couple of versions and the new Upgrade Support repo. And they are both ways for the community to come together and to help each other out in upgrading from a version to another. And also we are aware that we cannot fully automate the complete process of releasing which is why we incrementally iterate on this process on the bullet point list like it's never been that list from start. That's a progress, that's a work that we started back then and it's still improving right now. Like, for example, Eloy is doing right now another PR to improve the script that we use for end-to-end testing manually when we do the branching and the testing locally. And also Lucas has been doing a big work for the upgrade helper. They are planning now to basically make the whole part of generating new DEVS completely automatic. So, again, it's a constant process of improvement over what we cannot solve completely.

7. React Native Releases: 1.0 and Usability

Short description:

Releasing React Native is complicated, but 1.0 is not the final solution. 1.0 is just semantics, a promise of a finalized product and long-term support. React Native can be used before 1.0, just like Gmail was in beta for 5 years. React Native is already vastly usable and has been successfully used by many companies. I've been a React Native developer for years, and all my projects are still running.

So, to sum it up, releasing React Native - I hope at this point I've convinced you - is really complicated. The code base moves really, really fast and everyone involved is working to improve it, to improve the experience. Not just releasing it, but also the actual release and the experience for everyone consuming React Native so that everyone can have a better experience with it.

And, again, it's not just people from the community. It's the Facebook team and the Microsoft teams that have been collaborating a lot and collaborating way more than just me personally.

That said, let's go back to the title of my talk, in a way. I'm pretty sure by this point you're like, yeah, sure, OK, it's complicated, but wouldn't 1.0 be the final solution? Wouldn't having a version 1.0 fix all my problems? Like, should I wait for 1.0 to use React Native in production? And to that, my answer is a clear no. Let me explain. 1.0, per se, is just semantics. 1.0 is a promise. It's a promise of having a finalized product, so like, OK, that square, now it's complete, and it's a square that I can promise is going to work the way it should, it's the way I envisioned it, and also it's kind of bringing with it a promise of long-term support. Like, we're not used too much to have you know, many major releases, one after the other, in particular, for bigger pieces of software without, like, massive breaking changes and usually, we would expect you know, the major, to be supported for a long time. But that said, 1.0 doesn't mean that the product is not not usable, like simply because 1.0 is not there doesn't mean React Native cannot be used. Like, take Gmail. Like, let's go in a completely other realm. Let's talk about a piece of software that has been around for a really long time. Probably most of you don't remember this. But like, when it was released for the public, it actually was still in beta. Like, you have the Gmail logo with the beta label and it stayed in that way for 5 years. And why is that? Well, because that label was there to say hey folks, we're still working on it. We're still tweaking it and adding new things. Which is sort of what's happening with ReacNative. So, are we doomed? Like, since we don't get 1.0, should we never use ReacNative in production? I hope that by this point you kind of already know where I'm going with my answer. But the answer, of course, is heck no. Like, ReacNative is already vastly usable. Like, it's been successfully used all around the world. So many companies have used it successfully. Of course, not everyone, but hundreds and hundreds have. I've been a ReacNative developer for three to four years right now. And all the projects I've worked on are still there, are still around, still kicking, and I'm still really sure that it's been the right bet for those projects.

8. React Native Long-term Plan and Closing Remarks

Short description:

React Native has a long-term plan in place for the new architecture. Discussions with Facebook are underway to handle the release of the first pieces. The goal is to ensure the least breaking experience possible. The release process is complicated but necessary. React Native is continuously evolving, and version 1.0 is still far away. Enjoy using React Native now. Thank you for joining the conversation and stay tuned for the Q&A session and speaker room.

Also, as you may be aware, there's a long-term plan actually in place now, which is the new architecture of React Native. And in particular, I'm gonna say this, let's keep it secret between us basically, but we're talking already with Facebook to about how we should handle releasing one of the first pieces of the new architecture in the future, and we're trying to create a roadmap for that. So there's a long-term plan, we're already acting on it and we're trying to make it sure that it's the least breaking experience possible for everyone.

So, you can rest assured that we're constantly trying to improve. So as I was mentioning, to close it off altogether, the release process is complicated but for good reasons. React Native is still moving and everyone knows it still and 1.0 1.0.0 is still far away for React Native. So yeah, basically, 1.0 is a lie and you can just have fun using React Native right now.

I want to thank you all for sticking around, listening to this conversation, I hope that you enjoyed learning a bit more about the releases. My contacts are over there, you can reach out to me at my twitter, I have an email address over there and if you're watching this live, now we are going to have a Q&A and then there's going to be a speaker room and then there's an advance launch, so if you have any extra questions, please, please, please, ask me over there and I'm going to post the slides on my twitter quite soon. Thank you for staying around.

Check out more articles and videos

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

React Advanced Conference 2023React Advanced Conference 2023
29 min
Raising the Bar: Our Journey Making React Native a Preferred Choice
At Microsoft, we're committed to providing our teams with the best tools and technologies to build high-quality mobile applications. React Native has long been a preferred choice for its high performance and great user experience, but getting stakeholders on board can be a challenge. In this talk, we will share our journey of making React Native a preferred choice for stakeholders who prioritize ease of integration and developer experience. We'll discuss the specific strategies we used to achieve our goal and the results we achieved.
React Finland 2021React Finland 2021
27 min
Opensource Documentation—Tales from React and React Native
Documentation is often your community's first point of contact with your project and their daily companion at work. So why is documentation the last thing that gets done, and how can we do it better? This talk shares how important documentation is for React and React Native and how you can invest in or contribute to making your favourite project's docs to build a thriving community
React 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
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 Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
WorkshopFree
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 Advanced Conference 2022React Advanced Conference 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
WorkshopFree
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 Remote Edition 2021React Summit Remote Edition 2021
60 min
How to Build an Interactive “Wheel of Fortune” Animation with React Native
Workshop
- 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
Workshop
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
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
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
Workshop
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 goal.you 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 https://docs.expo.dev/get-started/create-a-new-app/