Reason in React Native

Ever since its initial release in 2015, React native took over the cross-platform development field. This facebook-backed, open source project grew from mobile toolchain through web and desktop support, to finally occupy even niche platforms like VR. 

It’s safe to say that React Native is here to stay.  

In this piece we’ll take a look at the biggest strengths and weaknesses of this framework, and try to forecast its future. 

Spoiler alert: the future is here and it’s called Reason ML.

Background

Around 2012, Jordan Walke from Facebook developed React JS. This internal project quickly grew and was deployed on both facebook.com and instagram.com, not to mention getting open-sourced several months later.

Web-developers loved it. It wasn’t long until a plethora of resources, online courses and blogs started to appear in large quantities, bringing even more programmers ready to jump on the React train. Seemingly endless capabilities of the social media giant contributed to that phenomenon as well. 

Interest over time, React - Angular - Vue. 

Encouraged by the reception of React, Facebook started working on the cross-platform mobile framework. In an attempt to ease the development process and create a unified front-end experience, Facebook applied React principles to mobile development.

Launched in 2015, React Native took what’s best from its sibling and brought some special sauce all of its own. Familiarity helped web coders to quickly adapt to new conditions of mobile development. Platform differences were abstracted away and unified in common API, making for much faster development process. Again, thanks to the enormous scope of Facebook ecosystem and an impact it has on developers’ community, framework got a lot of traction. 

React Native is now not only limited to mobile devices. It can also be found on VR sets, native windows applications, web sites and other platforms. So, what were the biggest advantages of React Native that allowed it to balloon to the ecosystem we know today? 

Out of the box, goodies

React and React Native benefited greatly from adopting JavaScript. JS is one of the most popular programming languages out there with a huge repository of learning resources and reasonable learning curve. Once a sidekick of HTML, it looked fully-fledged with all those new, fancy ES6 features back in 2015.

Another cool perk that comes with language this popular is the abundance of libraries. A package manager helps to add all necessary building blocks of application with few commands. Even React Native boilerplate project itself is distributed that way, and comes in a few flavours as well. 

What makes React Native applications stand out from all other cross-platform solutions is, in fact, being native. Whatever is possible on the underlying platform, can be done using framework. In short, JavaScript code is executed inside native application and interacts with it over a bridge. 

Whenever we want to show something on the screen, it is always a native view. The application has the design language, feedback conventions, and platform continuity of native apps. Thanks to this thoughtful design, React Native applications feel and behave indistinguishably from standard ones. 

Well, only when it’s well-written, and thoroughly-tested, that is. 

Live by JavaScript, die by JavaScript

There is one big elephant in the JavaScript room and a few smaller ones. The big one is its type system - it’s weak by default.

Let’s look at how that can lead us to a buggy code: 

This is a completely fine code that renders text input:

   <TextInput
               style={{
                 borderWidth: 1,
                 marginTop: 8,
                 fontSize: 18,
                 fontWeight: '400',
                 color: Colors.dark
               }}
             />

Firstly, there is a property name "style".

JavaScript React Native will accept every property you'll pass to the component, for instance, “styles.” Might complain, but will run regardless. Will not style the component though ... 

Let's imagine that we want our font size to be a dynamic value, calculated with this piece of code:

let fontSize1 = 2 + 18;
 
let fontSize2 = 2 * "10";
 
let fontSize3 = 2 + "18";

What ill happen now?

The first font size will be correct and the component will render large text of size 20.

In the second example, strangely, the same thing happens. Number and string multiplication results in a number, which is the correct type to use as a fontSize property. 

Third crashes though. This number and string addition computes to string and underlying Android platform cannot accept a string as for fontSize.

What's happened there? Is it a JavaScript bug? 

It’s not a bug, it’s a feature.

Add some reason to this 

Remember Jordan Walke, a Facebook engineer who invented React in the first place? Well, for the last 3 years he has been busy working on a new language which can alleviate the problems with Javascript. Behold ReasonML. 

Well, this is not exactly a new language. It is a syntax extension of OCaml that makes this battle-proven language accessible for JavaScript developers.

let add = (a, b) => a + b;

This is a valid ReasonML and JavaScript code. 

import { Text, View } from 'react-native';
 
const Component = () =>
 <View>
   <Text>
     {"This is test text"}
   </Text>
 </View>;

open ReactNative;
 
let make = () => {
 <View>
   <Text>
     {React.string("This is test text")}
   </Text>
 </View>;
};

Above is an example of a component in JavaScript and ReasonML. 

As you can see, Reason syntax looks almost exactly like JavaScript, and experienced web/react-native developers can pick up on it almost in no time. That is not the only example of JS’s Reason interchangeability.

Reason can be introduced to React Native project gradually as behind the scenes it compiles to JS anyway. That means all those useful NPM repositories are still valid resources in this new environment. 

Application written in Reason will benefit greatly from its type system. Everything has a type here, but most of them are inferred by the compile. That directly converts to less runtime errors, for instance, messenger.com, one of main Facebook products to adopt Reason, dropped its bug reports count from several daily to 10 a year! 

The JavaScript issues from the previous section simply would not happen in Reason. 

It does not allow you to do arithmetic operations on different types; you will need to convert it first. It accepts only predefined properties for components and style objects, which are created through functions. That approach eliminates most runtime errors and forces developers to fix all those at compile time. 

Summary

It is clear that Reason ML is well positioned to become a heir to JavaScript. Not only online, but in all other use cases, it brings more clarity and consistency to the table. Created by React and React Native authors, it might outdo both of those. That is certainly the goal.