ReasonML for JS developers

Let me ask you a few questions.

Are you a JavaScript developer?
Are you annoyed by every undefined is not an object?
Do you think static type checking makes your code slightly better?
Currently, there is a hype for a ReasonML. Do you want to be on the bleeding edge?
Do you want to learn a new functional language?
Are you tired of fixing production bugs?

If you answered yes to at least one of them you should stay with me for the next 10 minutes!

note: This is an article from a Cross-platform Newsletter. Subscribe to get more content like this right in your inbox!

What is ReasonML

ReasonML is a statically typed functional language. It bases on OCaml — a language created over 20 years ago. Reason combines the experience of OCaml (especially in the matter of types) and a fresh look with nice syntax similar to JavaScript. What is also important — it was built to be easily understandable for us — JS developers. Yeey!

Why the heck my JavaScript soul should even look at ReasonML?

Good question. There are two main reasons. The first you will get to know after reading this article. The second is because you can. And you can because reason compiles extremely fast to JavaScript. Readable JS. It’s possible thanks to BuckleScript — OCaml/ReasonML compiler which transforms your Reason code into JavaScript. So in the end, you have JS code, which you can use wherever you would use classic JS — in the browser, in node.js or in React Native application. What’s also great is that you can still use your JavaScript tooling! Your favourite npm libraries are at your fingertips. The only thing you need are bindings to them and you’re ready to go. But this is a topic for a completely different article.

Tip: you can try all of the examples below in a sketch.sh. Just copy the example, paste it there, hit cmd+s (ctrl+s) and voila. You should know the right shortcut chain. It is what most of the developers (especially me) do at the daily basis — cmd+c cmd+v cmd+s ;)

Variables

Below you can find the same fragment of code written in JS (first example) and ReasonML (second example).

JS

ReasonML

Looks similar, right? Although there are two differences under the hood — in Reason there is onlylet keyword and that every variable is immutable which means you cannot change the value of the already created variable.

Tip: variables in Reason are immutable but you can bind totally new value to a variable with the same name. So let myVar in two different lines in the same scope isn't anything weird.

Types

Right now you are probably wondering why there are no type definitions in reason example above. Though you read a few seconds earlier that it is statically typed language. You’re right, I just forgot to mention that it is also extremely smart. Reason infers your types from your code so in most of the cases you don’t have to worry about them.

Of course, if you want you can specify types just like you do with flow or TypeScript - by adding semicolon proceeded with the type name after the variable name.

JS + flow — type definition

Reason — type definition

In Reason you can find most of the primitive types you probably already know:

• string — let value: string = "Hi"; (string in Flow)
• int — let value: int = 12; (number in Flow)
• float — let value: float= 12.2; (number in Flow)
• bool — let value: bool = true; (boolean in Flow)
• char — let value: char = 'a'; (string in Flow)

Tip: in ReasonML different types require differen operators. For example + operator in JS could concatenate strings, add floats or integers. In Reason you have to use ++ for strings, + for integers and +. for floats. You can finde more information here: https://reasonml.github.io/docs/en/integer-and-float

Objects (aka records)

In JS to group some data we use plain objects. In Reason it’s very similar, see examples below.

JS

ReasonML

Nothing new here except that in Reason you have to define the type before you create an “object”. To do this you have to use type keyword and inside curly braces list all fields and their types. The syntax is familiar but there are more differences under the hood. The first difference is a name. What you see in the snippet is called a Record. The second difference is a fact that Reason’s records are immutable. You cannot reassign a field of an already created record. What you can only do is to create it in exactly the same shape as its type and then use it, nothing more.

Tip: Mutating records is forbidden but like in JS you can create a new record based on existing one using spread operator.

Functions

You probably use arrow functions on your daily basis. In ReasonML it is the only way to create a function.

JS — function which adds two numbers

ReasonML — function which adds two numbers

The difference here — return keyword. In ReasonML everything is an expression. So the last line in each scope will be returned — return is not needed.

Tip: You can ommit { brackets for function with only one line of code inside — just like in JS (suprise)

Tip 2: You can define the types of function arguments by adding :TypeName after the each argument name. Although it’s not required in most of the cases.
Example: let add = (a: int, b: int) => a + b;

Tip 3: You can also add labels to your arguments and call the function using argument’s labels instead of its order. They’re called labeled arguments and you can find more information about them here: https://reasonml.github.io/docs/en/function#labeled-arguments

Sequences of data

To start our discussion about sequences of data please look at the examples below.

JS — List

ReasonML — List and Array

At first, JS and Reason versions look almost the same but in ReasonML example you can see two different syntaxes — one with [ and another with [|. The first one is called aList and the second one is an Array. For us — JS enthusiasts — it looks a bit overcomplicated. Why differentiate Lists and Arrays? The answer is simple. Lists are immutable and fast at prepending items. You will probably use it for dynamic data structures. List of TODOs for TODO app will be a good place for using them.
Arrays are mutable (you can mutate each item), fast at random access & updates. If you’re looking for a JS-like experience and don’t have to add new items to array it’s the best choice for you.

When it comes to iterating over List or Array there are more differences between JS and Reason. Look for example at a simple map:

JS — Iterating over an array

ReasonML — Iterating over an array

In JavaScript we have Array prototype with a bag of methods we can call directly on an array instance. There’s no such thing in ReasonML. But we have Array and List modules. Both are very similar and with an even bigger bag of useful functions like map, length or sort.

Tip: Accessing List items might be a little bit confusing at the first time so I recommend to start with an Array, learn more about pattern matching and recursion in Reason and than go back to Lists — https://reasonml.github.io/docs/en/list-and-array#list

Modules

This will become a little bit crazy — But this is the level of craziness that everybody likes ;) Let’s compare JS with ReasonML by creating two similar modules that contain simple add function.

JS — basic module

ReasonML — basic module

First weirdness… There is no exporting in Reason. Each and every one of your files will become a module with the same name as the file.

Let’s move to the example of consuming the module. Imagine that we have file App directly in src/ directory and we want to use add function from AddModule file in src/utils/. Here is how it looks like:

JS —using simple module

ReasonML — using simple module

Did I just forget to import the module in ReasonML example? No! No export — no import, easy. In ReasonML you can use your modules by using their names (in our example the filename). But what is more important — a location of the module doesn’t matter. You probably noticed in the example that AddModule file is in a different location than theApp and we still were able to use it by simply calling its name. Pretty awesome, right? Just please remember to be careful with filenames to protect yourself from a name clashing.

Because using ModuleName. everytime you want to use some modules function could be problematic ReasonML allows you to open the whole module for a specific scope. It basically means that you can make the content of a module visible inside some block of code — for example for the whole other module. To do this you have to typeopen ModuleName; at the beginning of a scope. So if you have some file (Math.re) with an add function inside and do open Math; at the beginning of another file you will be able to do add(1, 2) without any prefixes.

Tip: Be aware that openning modules globally could easly break your code. Situation when the module you’re opening has a function with the same name as some of yours functions or variables is more than possible. In those cases you can open module only locally. For example if you want to create a list with a few results of add function you can do the following:AddModule.[add(1, 2), add(2, 3), add(2, 4), add(2, 5)]; You can find more details in the official ReasonML documentation or here.

Variants

Imagine you have some blogging app abd you want to keep information about user review under every post. You would like to have three simple choices: Bad, Neutral and Awesome. Code which checks if the review is “not bad” could look like this:

JS — variants/enums/options

ReasonML — variants

Except for type definitions, both examples look very similar. The difference is that JS version is more error-prone. Each typo in the review name could cause a few hours of bug fixing. If you do the same typo in ReasonML compiler will tell you that you have a bug even before you start testing it.

But that’s not all. Imagine you want to keep some explanation text for the Bad option. Normally you would keep the data as a separated variable but ReasonML variants have one additional ability — constructors.

JS — adding the review with additional data

ReasonML — adding the review with additional data (aka Variant Constructors)

The thing you see above is called a constructor. It’s a way to store some data inside a variant. This is an ideal way to store different types of data. Do you want to accept strings, integers or floats in some variable? Just create a variant: type data = Text(string) | Int(integer) | Fl(float);.

Tip: In a single variant, you can store more than one value. You can, for example, do the following: Point(float, float).

Pipeline operator — chaining function calls

Calling function with the result of another function is something we do very often. Currently, in JS there is no better way than nesting function calls or assigning function result to some variable and than passing it to another one. In ReasonML there is a special operator that makes our lives easier — pipeline operator. You’ve probably heard this name before because it is quite common in other languages than JS. We even have a tc39 proposal with it.

JS — function calls chain

Well in Reason we already have it!

ReasonML — function calls chain

Like you see above we can use |> to pass value on the left side of operator to the function on the right as its last argument. Extremaly simple syntax which makes the code much clearer.

Another great use case for the pipeline operators is the usage of modules like Array or List. When you were reading the paragraph about Lists you probably wondered how advanced use case would look like. In JavaScript it’s simple. Because we have a lot of useful methods on different object prototypes we can easily chain them. So this is a normal thing in JavaScript: array.filter(…).map(…). Few of you probably remember the times when chaining jQuery selectors and functions were the most important part of every front-end developer’s life. It’s natural and clean but it’s not possible in ReasonML… but don’t worry, we have a pipeline operator… God bless the pipeline operator.

Below you can see the example of an advanced array modifying. The code filters out the 0 from an array, multiplies each value and converts it to a string.

JS — chaining Array prototype functions

ReasonML — chaining Array module function using pipe operator

Thanks to pipeline operator our ReasonML code looks almost the same as JS one. And what is more important there are no magic creatures like object instances, prototypes or this. There are just simple functions.

Pattern matching

If you’ve already heard some good opinions about RreasonML the most common thing that everybody loves about the language is Pattern Matching. What is it exactly? Pattern matching is like JS switch-case but on steroids.
Below we have an example of a function which returns some feedback for users after they left a review (we will use variants from the previous example).

JS — Switch statement (little brother of Pattern matching)

ReasonML — Pattern matching

It is just a switch statement but prettier (nobreak or return keywords) , right? So, why everybody loves it so much? Look closer to the line with Bad variant. We just destructured it and assigned the value from variant constructor to comment variable. For those who don't know, destructuring is a way for easy extracting nested values of some variable - In ReasonML it could be a Record, an Array or for example a Variant constructorand it works exactly the same as in JS. We used destructuring of a Variant in pattern matching so analogically we can do it for any other type. We can match values in a very specific way and while doing it we can assign those values to variables — that’s why it’s called “Pattern Matching”. We match some patterns in our value.

Let’s see a little bit more exhaustive example of this powerful feature. After that, I hope you will either love Pattern matching or decide to spend more time with it ;)

ReasonML — advanced Pattern matching example

Just imagine how nested if statements hell would look like in JS after you implement the same logic… If you are brave enough here you can see an example.

Tip: Of course this is not everything. Maybe do you want to add some additional check to some of your matched values? Using when keyword you can do something like that: | { name, phone, age } when age > 20 => “Matched every person above 20!”.

Tip2: There is also one nice thing. Reason compiler will warn you if you won’t cover all cases from the Variant. Goodbye unhandled cases.

There are more…

We went through the most interesting parts of ReasonML but there are much more — tuples, fast pipe operator, promises, advanced function currying, Objects, mutations, JS interop, native compilation etc.

To learn more I encourage you to look at some amazing tutorials, articles, or podcasts made by amazing people in the community:

• Official ReasonML documentation — very good place to start the adventure with ReasonML
• Exploring ReasonML book by Dr. Axel Rauschmayer — it’s free if you want to read it online
• “Get Started with Reason” egghead course — great tutorial for beginners
• reason.town podcast — ReasonML news and useful discussions with interesting topics from native compilation to Reason on a server
• reason.chat — Forum when you can ask about everything about ReasonML
• ReasonML discord server — hundreds of ReasonML developers ready to help you

If you liked the language after reading this article there is a homework for you — play a little with ReasonML, learn it, do something small and then conquer the world with it.

This article was originally published at callstack.com on December 14, 2018.