Skip to main content

· 5 min read
MoOx

Following BuckleScript & Reason Rebranding to offer a unified experience, what was know as Reason React Native is now ReScript React Native.

To make this short: all packages that were published on the behalf of Reason React Native organisation are now published as the ReScript React Native organisation.

This means:

Should I migrate now all my packages?​

It depends on what version of React Native your are using. There is no rush, really.

You use React Native 0.63​

You can keep using reason-react-native and friends for now. Revisit this post when you will need to upgrade to 0.64.

You use React Native 0.64​

Here you have 2 possibles upgrades path:

Keep using reason-react-native​

Before renaming all packages, we offered a last release for reason-react-native to cover React Native 0.64. You can use that until you are ready to switch to ReScript named packages. If you want to know what this will involve, keep reading.

Switch to rescript-react-native​

The package rescript-react-native starts with version 0.64.1. You can try to use it for earlier version of React Native of course, but you might end up to minor inconsistencies, especially for bindings that have been tuned for 0.64. Check out breaking changes in release notes to know what this is all about.

If you are ready to move to ReScript naming, you can use all the new packages. Except rescript-react-native, other packages of this organisation have just been renamed for most of them, without any changes.

You can expects minor change between reason-react-native@0.64 & rescript-react-native@0.64 but this should not cause you any major trouble to switch. You will probably notice some Js.t have been converted to record syntax, some polymorphic variants changes and minor things like that, but compiler should just tell you what to do.

Please note that @rescript/react is required for switching​

You cannot use reason-react and @rescript/react as they exposes the same module. This means this will be "all or nothing". Some bindings rely on React module, so they now depend on @rescript/react. This is true for rescript-react-native and some other modules.

This is briefly mentionned in rescript-react-native@0.64.1 release notes but you will also need bs-platform@^9.0.0.

Before you ask, rescript package is now a thing and up for testing (you can track this using the ReScript forum, Announcements section). This is considered beta at the time of writing this post, so we will change this peer dependency in a near future, when it's officially stable. This will replace bs-platform, probably in next "major" release (0.65 or maybe a 0.64.x-rescript).

tl;dr​

If you want to switch to the new naming, you need to be ready to use

  • React 17 and @rescript/react@^0.10
  • React Native 0.64 with rescript-react-native@^0.64.1
  • ReScript 9 via bs-platform@^9.0.0

If you have any questions regarding these changes and how to proceed, feel free to open a discussion on GitHub, or use ReScript forum.

Wait.. That's it?​

You might have a question that is still pending: "where is gone the promise of cross-platform code that ReasonML was supposed to offer? I was thinking I could someday use my Reason React Native code to compile it to a lower level language that JavaScript to have blazing fast performance... "

Like I did in the past in my sweet dreams, you may be looking for this. And maybe this will be a reality one day in the future. Some people want this JSX like convenience to build native apps. Some will argue that there are things that you can use today. But React Native ecosytem is more mature than existing solutions.

React Native can safely be used in production today, and it is for many successful companies. All the modules availables (from the core or the community) make it very easy to avoid writing specific code per platform. Performance is better and better for every release. Recently Hermes JavaScript engine was released for iOS and it's really fast. And don't forget TurboModules!

You can not only write mobile apps this days, but also web apps, thanks to React Native for Web, and even native desktop apps, thanks to React Native Windows + macOS. More than enough to ship amazing products to production, today.

What's next​

I guess for the near future, nothing crazy will happen for ReScript React Native. We have to update some bindings from time to time, but beside having to switch from bs-platform to rescript, things should go smoothly. Feel free to open a discussion if you want bindings for some modules (or just help to write them).

When stars are not correctly aligned and some package have incorrect bindings, remember that you can always use the fantastic patch-package to fix things real quick, and then open an issue at the right place.

❤️ I mostly maintain all this packages all by myself this days, so feel free to Sponsor Me on GitHub and just share kind words on Twitter to keep me motivated. I hope you enjoy this work like I do.

· 5 min read
MoOx

Today is a big day for the ReasonML community as we are releasing the fruits of a long effort started about 4 months ago.

As more and more people were starting to use ReasonML on production apps using React Native, we wanted to make the ReScript / BuckleScript bindings for React Native, known has bs-react-native, more accessible. This would have involved several breaking changes in order to simplify some APIs that have been designed with a high level of security in mind, but at some costs. The cost of being harder to start with (for newcomers to ReasonML) as well as the cost in terms of code size and performance.

While some of us were thinking about some simplifications, some others, involved in Reason React incoming changes, directly started a new approach for this bindings, following the zero-cost approach offered by reason-react 0.7.0.

CCA started this effort on what is now know as the new reason-react-native bindings, that eliminates a huge part of the additional JavaScript code produced by the bindings.

Zero-cost​

By zero-cost, we means zero additional cost. The JavaScript code ReScript / BuckleScript produces using this bindings will most of the time directly hit React Native JavaScript code without creating an unnecessary abstraction above it 🙌.

Here are some random examples:

Some modules are even empty or with some minor require() that can be themselves almost empty and easily removed by some JavaScript bundlers.

How cool is that?

But why reason-react-native ?​

bs-react-native already had multiple breaking changes in the past and we didn't really want to offer a poor experience by creating a new release with tons of changes that won't be easy to codemod (or would require much more work from us).

On top of that, reason-react latest release already added an important breaking change with JSX 3.

That's why we had this idea about offering an easy and smooth transition by offering 2 packages to say goodbye to bs-react-native without pain.

  • bs-react-native-jsx3-compat (0.11.1)
  • reason-react-native (0.60.0)

Wait, what is bs-react-native-jsx3-compat ?​

bs-react-native is using JSX 2 so in order to use it with JSX 3 we would have to create an additional layer on top of the current bindings to offer both JSX 2 and 3 bindings. And since we wanted to do away with some current APIs of bs-react-native we started to think about a new approach.

We knew that we wanted to:

  • offer to bs-react-native users a migration plan, so they can start very easily to use JSX 3 and new reason-react (so they can use hooks),
  • offer new reason-react-native bindings, more accessible and with a zero cost approach.
  • offer a smooth transition between these two packages so people can slowly upgrade their codebase without having to make an insane PR that switches from one to the other.

We don't want your co-workers to hate you with a PR that comes directly from hell 😅.

That's where we thought about offering bs-react-native-jsx3-compat. It's a package that has the same APIs bs-react-native has but that uses reason-react-native under the hood.

This means you will have to make a migration from JSX 2 to 3. That's the only thing you will have to do, then with a single change from bs-react-native with bs-react-native-jsx3-compat in your bs-dependencies you will be ready to use hooks and directly benefit of (almost) zero-cost bindings!

And since we care about you and don't want you to upgrade from JSX 2 to 3 by hand, we got you covered with a script made with love to help you with that.

You will find all the required instructions to migrate from bs-react-native to bs-react-native-jsx3-compat in our documentation.

tl;dr​

Thanks​

This required effort has been keeping us busy for weeks and wouldn't have been possible without the following people:

  • CCA team and especially @cknitt for leading us to the right direction for the new zero-cost bindings and all the contributions that come with this move
  • @sgny for all his contributions to the new bindings
  • @MoOx for leading the effort, the compat layer and the new website you are seeing here
  • @bloodyowl for his magical reason-react-compat layer and the alternate JSX 3 upgrade path that goes with it
  • all the people that helped us on Discord and GitHub in various code reviews and improvements like the react native template (thanks @dawee)

What's next?​

Now that reason-react-native is ready to be used and that our migration plan is usable, we will probably be focused on documentation as lots of APIs and Components need to be documented. We really want to offer the best developer experience possible and that's definitely part of it.

👉Now it's time for you to check our Getting Started with Reason React Native documentation