
![file cabinet](https://images.unsplash.com/photo-1569235186275-626cb53b83ce?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=1952&q=80)

_Photo by [Maksym Kaharlytskyi](https://unsplash.com/@qwitka) on Unsplash_

Building backend services with Rust can be difficult if you have to keep 10 tabs worth of documentation open at all times. I find it helpful to practice and learn how certain libraries work, reducing the time spent combing through documentation.

Depending on the kind of application or utility you are making, you may need to deal with the filesystem at some point.

If you're creating some sort of data storage without reaching for a database like Postgres or MySQL, you'll probably store your data in files.

If you're writing software to compose audio or video, you'd have to be able to write and read those files.

If you're creating a utility to help scaffold out a project like `create-react-app` or `cargo new`, you would want to use the filesystem to create your boilerplate directories and files.

Regardless of your goals, it would be helpful to know the common methods used in the `std::fs` namespace as you'll otherwise be looking them up all the time while building your project.

# Overview of Key Functions

> **Docs:** The docs for the `fs` crate are available [here](https://doc.rust-lang.org/std/fs/index.html).

## Reading files

> **Note:** If you do not yet understand how generic function parameters work, you can read [this chapter in the Rust Book](https://doc.rust-lang.org/book/ch10-01-syntax.html?highlight=generic#generic-data-types).

> For example, a path, P, is defined to be any type which implements a method which implements the trait `AsRef<Path>`.

Starting with the basics, this is the function signature for `std::fs::read`.

```rust
fn read<P: AsRef<Path>>(path: P) -> io::Result<Vec<u8>>
```

You can use this method of the `fs` crate in order to read a file at a given **path** and return a **vector of bytes**. Its usage works like the below snippet:

```rust
use std::fs;
use std::path::Path;

fn main() {
  let path = Path::new("screenshot.png");
  let data = fs::read(path).unwrap();

  // do something with `data`
}

```

The read method is actually a convenience wrapper for calls to `File::open` and `std::fs::read_to_end`. This is nice because we have access to the granular, low-level functions without sacrificing the simpler `read` method.

```rust
pub fn read<P: AsRef<Path>>(path: P) -> io::Result<Vec<u8>> {
    fn inner(path: &Path) -> io::Result<Vec<u8>> {
        let mut file = File::open(path)?;
        let mut bytes = Vec::with_capacity(initial_buffer_size(&file));
        file.read_to_end(&mut bytes)?;
        Ok(bytes)
    }
    inner(path.as_ref())
}
```

## Writing files

Here is the function signature for `fs::write`:

```rust
fn write<P: AsRef<Path>, C: AsRef<[u8]>>(path: P, contents: C) -> Result<()>
```

Assuming you have some data as a **slice of bytes**, you can write this to a file at a **path**.

Since the write method is merely a side-effect, it's return is just a `Result` type which resolves to either unit or an error if something went wrong.

```rust
use std::fs;
use std::path::Path;

fn main() {
  let path = Path::new("hello.txt");
  let contents = "hello there";
  fs::write(path, contents).unwrap();
}

```

Just like with the read method, write is a convenience wrapper for `File::create` and `std::io::write_all`. Here is the actual implementation:

```rust
pub fn write<P: AsRef<Path>, C: AsRef<[u8]>>(path: P, contents: C)
  -> io::Result<()> {
    fn inner(path: &Path, contents: &[u8]) -> io::Result<()> {
        File::create(path)?.write_all(contents)
    }
    inner(path.as_ref(), contents.as_ref())
}
```

With both `fs::read` and `fs::write`, we see generic type arguments in action. For the P argument, this allows us to use types like `str`, `String`, `Path`, or `PathBuf` when calling one of these methods.

The standard library uses a pattern where they define an `inner` function with specific type parameters. They then call it with the outermost arguments after casting them with `as_ref`, the function required by the `AsRef` trait.

My goal is not to explain generic types and traits, but I find exploring how the standard library uses them to be quite insightful.

## An Example: Copying files

Let us say we'd like to copy a file from one directory to another, similar to the `cp` command on unix.

We could do this by writing:

```rust
use std::fs;
use std::path::Path;

fn main() {
  let input = Path::new("hello.txt");
  let data = fs::read(input).unwrap();

  let output = Path::new("hello_copy.txt");
  fs::write(output, data).unwrap();
}
```

Rust's `fs` library gives us yet another convenience method for this task, `fs::copy`.

```rust
use std::fs;
use std::path::Path;

fn main() {
  let input = Path::new("hello.txt");
  let output = Path::new("hello_copy.txt");
  fs::copy(input, output).unwrap();
}
```

## Other Useful Methods

Read and write are definitely some of the more obvious uses of a filesystem, but generally speaking, a thorough application will also include other capabilities like handling directories.

**Reading utilities:**

- `fs::read_to_string` - returns file contents as a `String` rather than `[u8]` bytes
- `fs::read_dir` - returns an iterator over all of the entries (files and other directories) within a directory

**Writing utilities:**

- `fs::create_dir` - creates a new, empty directory at a given path.
- `fs::create_dir_all` - given a path, will recursively create all necessary directories if they are missing
- `fs::rename` - rename a file or directory to a given name, similar to `mv` command in unix

**Removal utilities:**

- `fs::remove_file` - remove a given file
- `fs::remove_dir` - remove a given, **empty** directory
- `fs::remove_dir_all` - remove a directory and all of its contents (be careful with this one)

Since this isn't a match statement, I won't present an exhaustive list of methods, but you can view that [in the docs](https://doc.rust-lang.org/std/fs/index.html).

## Thanks For Reading

I hope you have enjoyed this article or found some sort of use for it. I am currently working on a project that uses some of these method to create something that will help my own development.

If you'd like to keep up with the next time I drop an article in the realm of Rust, ReasonML, GraphQL, or software development at large, feel free to give me a follow on [Twitter](https://twitter.com/iwilson), [dev.to](https://dev.to/iwilsonq), or on my website at [ianwilson.io](https://ianwilson.io).


Reading and writing files and directories with Rust

Mastering the File System with Rust


Creative professions can be great fun when you're in rhythm. In this state, the ideas emanate from your fingertips. When you're productive: you're hitting your deadlines.

You push metal at the gym, clean your room, and beat the Elite 4. You're the unstoppable force that will build the next unicorn.

But then things take a turn. You have personal stresses at home like a breakup or a fatal pet emergency. You suffer an injury while lifting weights or downhill mountain biking. Your mojo vanishes, even for no clear reason at all — it happens to everyone.

Recently, I experienced a rut. It is a total lack of energy to do anything beside drink beer and watch all the Austin Powers movies. Not the worst fate, I will add, but I would like to do other things too.

To break out, I employed strategies that would help anyone whether you've been out of it for a single day or 6 months.

## Action Yields Action

Consider the how you might try to break out of a writers block. I wrote my last article on September 13, 2019, with the goal to continue writing articles. Every week, I would write about fantastic programming topics like Rust or ReasonML.

Now it's 2020, and I'm writing the next one since then. I've had the intent to write _something_ on my mind almost every day for the past several months but I never did it.

I sat down, wrote those first two sentences you can see above, and then vacuumed my living room.

And then, I wrote the rest of it.

My point is, the simple act of scribbling those two sentences spawned a flurry of motivation. By writing two sentences, I had convinced myself that I could do it.

I always _knew_ I could because I had written plenty of articles before. But subconsciously, I could not execute.

I had created the **inspiration** that it would be possible to write this post. That **inspiration** led to **motivation** to continue writing, thus leading to more writing. That is the **action** which is our real goal here.

Watch a motivational speaker or a Get-Rich-Quick guru. You may come away with the feeling of **inspiration**.

"Wow look at these people, they are so rich and so inspiring!", you think. The crowd applauds until the final sales pitch, when they file out of the room.

After you get home, then what? Flip on Netflix, after all, seeing those people was stressful and now its time to relax. Even though that presentation (or video, or book...) was inspiring, it does not always spur the **action** that will get you to where you want to be.

Make a simple move towards where you want to be, and then dwell on it. Be proud of that effort, because it is proof that you can do it.

## Try Not to Go All-In

Let us suppose you put in a little action and now you have more energy and motivation than you know what to do with. What now? While you could try to exhaust all of it in one sitting, I advise against this.

It is more effective to be increasing in productivity day by day rather than blow it over a short period. A single burst of activity will sound cool. You can show off how productive you were that one day, but consider the trade-offs.

- If you do too much, you force your brain to think you'll be working this hard every day.

- If you use all of your energy, you may lead yourself right back into a rut when you're mentally exhausted the next day.

- If you have a full time job _and_ you want to balance it with exercise, family, friends, and whatever other priorities you have... take it easy.

My suggestion is to start with small wins; a couple sentences, a new function/class, a single song on a guitar. When you've completed a simple action, the rest will follow.

After you've been working at it for 20-50 minutes, take a break and reflect on what you accomplished. You can continue for another period of time, or you can trust the same technique to help you carry on tomorrow.

Savor your victories today. The next ones will be bigger and even more rewarding. The goal is consistency.

## Smaller, Yet Effective Tips

Here are a few little tips I can offer up to get you out of the rut.

- Eat well. I've had a pretty big boost in energy with Athletic Greens after I saw it mentioned on Tim Ferriss's show. They don't sponsor me but there's a ton of benefit for getting your full daily quota of veggies right away. Its part of my excuse to eat whatever else I'd like that day.

- Don't overeat when you go out, save your leftovers. When I go out, I prefer pasta since I know it will also taste good later. Meal planned.

- Cleaning your living space has a tremendous effect on what you feel you can accomplish.

- Exercise often, but not too hard! I run a lot, but I am much more depleted throughout the day/week when I spent too much time around 90% of my maximum heart rate. If you exercise after work, understand that being mentally exhausted will affect your perceived effort.

---

I usually post articles that are heavy on the technical side. If you're interested in ReasonML or Rust, definitely check out my other works.

If you came here to get out of a rut, then I hope a little action helps lift you out.

Thanks for reading, and see you next time!


Break through your creative block and unleash the power within.

Breaking Out of a Rut or Creative Block

Let us see what goes into building a GraphQL server with Rust.

Building Powerful GraphQL Servers with Rust


![](/timer.png)

ReasonML is a programming language that combines the simplicity of JavaScript with the performance of OCaml. JavaScript programmers should give ReasonML a try. Reason's inherits OCaml's typesystem as well as the approachability of JavaScript.

With [ReasonReact](https://reasonml.github.io/reason-react/) and [BuckleScript](https://bucklescript.github.io/), we can compile Reason code to JavaScript that works like good old React.

But that's not all, things are getting even better for the Reason ecosystem. Earlier last week, ReasonReact [version 0.7.0 dropped](https://reasonml.github.io/reason-react/blog/2019/04/10/react-hooks), with support for React hooks. We can now build robust components with React hooks that:

- eliminate duplicated lifecycle logic (like in componentDidMount, componentDidUpdate, and componentWillUnmount)
- eliminate the need for complicated patterns like higher-order components or render props
- allow _easier refactoring_ of stateful components

Think for a moment about that last point, what else give us easier refactorability?

A rock solid typesystem and a helpful compiler!

Today, we're going to build a Pomodoro Timer [like this](https://tomato-timer.com/) using Reason and React.

A pomodoro timer allows you to set a timer for say 25 or 30 minutes that lets you know when to stop working. Because sometimes taking a break is good, and you better believe I'm using one while writing this.

## Initializing a Project

The first step is to install BuckleScript, a tool that will compile our Reason code to JavaScript.

```sh
npm install -g bs-platform
```

After that, we can scaffold our project with the `init` command, and setting the `theme` to react-hooks.

```sh
bsb -init pomodoro-timer -theme react-hooks
cd pomodoro-timer && npm install
```

Now that our project set up, we can mention our folder layout. Our Reason code belongs in the src directory. Where we usually have an index.js file in a JavaScript React project, we have an Index.re file. These files serve the same purpose: render the app root.

Since our code will compile to JavaScript, I still like to have a bundler like Webpack to bundle those files.

> Tip: It is generally considered a best practice to keep your folder structure as flat as possible with ReasonML, using captialized file names (like Timer.re). See the [ReasonML docs](https://reasonml.github.io/docs/en/project-structure#folders) for a discussion on project structure.

### Running the code

Before I clean up the environment, let us try running the code. This will need two or three separate terminal tabs:

```sh
# in one tab
npm start
```

This runs `bsb -make-world -w` which compiles your Reason files on every change. It does this quickly, mind you.

```sh
# in another tab
npm run webpack
```

This command takes our compiled JavaScript and spits out a bundle that we can then open in a browser using:

```sh
open build/index.html
```

I prefer use a static file server like [zeit/serve](https://github.com/zeit/serve).

```sh
# install `serve` globally
npm i -g serve

# serve it!
serve build/
```

![initial project](./initial_project.png)

### Cleaning up the Environment

I want to clean up the default project structure before writing an implementation.

1. Remove the Component1.re and Component2.re files, we will not be using these. You can still read them and try to making sense of how hooks are working in our new environment.
2. Replace index.html with the following:

```html
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Pomodoro Timer</title>
  </head>
  <body>
    <div id="root"></div>
    <script src="Index.js"></script>
  </body>
</html>
```

Replace Index.re with the following:

```reason
ReactDOMRe.renderToElementWithId(<Timer />, "root");
```

Open up bsconfig.json and change the field "in-source" from true to false. This will output our compiled JavaScript into the lib/js directory. I prefer this over leaving them inside of our root src directory.

Tell webpack to build from the new location by changing webpack.config.js to the following:

```js
module.exports = {
  entry: './lib/js/src/Index.bs.js',
  // rest of webpack config
};
```

And now with all out that taken care of, we can begin the fun part, the implementation.

## Building a Stateless Component

After cleaning up, notice that we are trying to render a `Timer` component but we have not even defined one. Let us write a stateless component to render to the page.

```reason
[@react.component]
let make = () => {
  <div> {ReasonReact.string("One day this will be a timer")} </div>;
};
```

I want to highlight how simple this code is. Writing a stateless React component in the previous version was more verbose:

```reason
/* DO NOT WRITE THIS */
let component = ReasonReact.statelessComponent("Timer");
let make = () => {
  ...component,
  render: _children =>  <div> {ReasonReact.string("One day this will be a timer")} </div>;
};
```

Even compared to regular JavaScript with React, this new syntax is incredibly slick. With Reason projects, we do not need to layer imports on top of the file every time we make a new file.

## The useReducer Hook

Now we are going to introduce some state into this equation. We do not have any "class" components, we are still using functional components. But now we are going to use React hooks to compose a solution.

For our timer, we need to keep track of at least two things:

1. The seconds on the clock
2. Whether it is ticking or not

When we consider any timer, we usually have three buttons: `Start`, `Stop`, and `Reset`. These map to directly to user interactions, but there is one more: the `Tick` itself. Even though the tick is not controlled by the user, it is still an action that should return a new state for our reducer.

At the top of Timer.re, where we will build this whole app, add the following:

```reason
type state = {
  seconds: int,
  isTicking: bool
};

type action =
  | Start
  | Stop
  | Reset
  | Tick;
```

How easy it is, to implement an application after you have described your states needs and actions!

Next we'll update our make function to use a reducer:

```reason
[@react.component]
let make = () => {
  let (state, dispatch) =
    React.useReducer(
      (state, action) =>
        switch (action) {
        | Start => {...state, isTicking: true}
        | Stop => {...state, isTicking: false}
        | Reset => {...state, seconds: 30}
        | Tick => {...state, seconds: state.seconds - 1}
        },
      {isTicking: false, seconds: 30},
    );

  <div>
    {ReasonReact.string(
       "There are " ++ string_of_int(state.seconds) ++ " on the clock",
     )}
  </div>;
};
```

The syntax is like that of ReactJS. The `useReducer` function returns a tuple as opposed an array. This is because JavaScript does not know what the heck a tuple is. We make sure to handle each of our action types inside this reducer, returning a whole copy of the state.

The second argument to `useReducer` is the initial state of the reducer. It would make sense for the time to receive the initial time as a prop but I'll leave it this way for now.

Now we need a way to invoke these actions. Let us start with the `Tick` because it is the most complicated bit.

## The useEffect hook

To update the timer every second, we need to create an effect. In the JavaScript world, this means putting a callback function within `setInterval`.

Let us add this hook between the `useReducer` function and the returned JSX.

```reason
React.useEffect0(() => {
  let timerId = Js.Global.setInterval(() => dispatch(Tick), 1000);
  Some(() => Js.Global.clearInterval(timerId));
});
```

If you recall the way `useEffect` works:

- The first argument is a callback function that runs when the component mounts, updates, or unmounts.
- Optionally, the callback function can return another function that performs cleanup. This includes unsubscribing from sockets or clearing a setInterval so it does not persist forever.

If you run the code and refresh your browser, you'll see that our timer is going to run indefinitely.

It should not do this, so lets update our reducer again to account for whether the `isTicking` flag is true or false. We will also make sure that `seconds` are greater than zero so we do not go negative.

```reason
let (state, dispatch) =
    React.useReducer(
      (state, action) =>
        switch (action) {
        | Start => {...state, isTicking: true}
        | Stop => {...state, isTicking: false}
        | Reset => {...state, seconds: 30}
        | Tick => state.isTicking && state.seconds > 0
            ? {...state, seconds: state.seconds - 1} : state
        },
      {isTicking: false, seconds: 30},
    );
```

Now you can verify this by setting `isTicking` to true and `seconds` to 3. Lovely, this app is functional now. If you wanted to actually use it, refresh your browser and watch it count down.

## Interactivity with Buttons

To make this Timer even better, I am going to add buttons.

Let us define a Button module in the same file as our Timer, right above the make function.

```reason
module Button = {
  [@react.component]
  let make = (~label, ~onClick) => {
    <button onClick> {label |> ReasonReact.string} </button>;
  };
};
```

This button takes a label and an onClick prop. We can add them to our Timer, at the bottom of the make function like so:

```reason

[@react.component]
let make = () => {
  /* useReducer */

  /* useEffect0 */

  <div>
      {ReasonReact.string(
        "There are " ++ string_of_int(state.seconds) ++ " seconds on the clock",
      )}
      {state.isTicking
        ? <Button label="STOP" onClick={_event => dispatch(Stop)} />
        : <>
            <Button label="START" onClick={_event => dispatch(Start)} />
            <Button label="RESET" onClick={_event => dispatch(Reset)} />
          </>}
    </div>;
};
```

Try running this in your browser, you should see:

![start and stop buttons](./start_stop.png)

If you click START, it will start. If you click STOP it will stop. RESET will bring the timer back up to the initial time. Pretty straightforward how it just works!

At this point, our app is **feature-complete**. Read on to make it even cooler, with style and other aesthetic details.

## Aesthetic Concerns

Let us add some styles and make this timer look pretty. Or at least better.

Update the JSX in Timer to the following:

```reason
[@react.component]
let make = () => {
  /* useReducer */

  /* useEffect0 */
<div
    style={ReactDOMRe.Style.make(
      ~border="1px solid black",
      ~borderRadius="8px",
      ~maxWidth="180px",
      ~textAlign="center",
      (),
    )}>
    <p
      style={ReactDOMRe.Style.make(
        ~color="#444444",
        ~fontSize="42px",
        ~margin="16px 0",
        (),
      )}>
      {state.seconds |> formatTime |> str}
    </p>
    {state.isTicking
       ? <Button label="STOP" onClick={_event => dispatch(Stop)} />
       : <>
           <Button label="START" onClick={_event => dispatch(Start)} />
           <Button label="RESET" onClick={_event => dispatch(Reset)} />
         </>}
  </div>;
};
```

I have introduced the default styles that come with ReasonReact. They are not my preferred style solution as I like [bs-css](https://github.com/SentiaAnalytics/bs-css) better, but for this small project, they will do fine.

I also introduce a `formatTime` function. Let us implement that function so our project compiles:

```reason
let padNumber = numString =>
  if (numString |> int_of_string < 10) {
    "0" ++ numString;
  } else {
    numString;
  };

let formatTime = seconds => {
  let mins = seconds / 60;
  let minsString = mins |> string_of_int |> padNumber;
  let seconds = seconds mod 60;
  let secondsString = seconds |> string_of_int |> padNumber;
  minsString ++ ":" ++ secondsString;
};
```

I included `padNumber` as well, a useful utility that pads minutes and seconds which are less than 10. This makes the timer more reader friendly.

I will be honest, this timer looks pretty good right now and I have not even styled the buttons. I will leave that as a task for the reader if they are so inclined.

![finished timer](./finished_timer.png)

## Update the Document Title

The concept of a timer in the browser can be further improved. If we have the time remaining persist in the browser tab itself, it would be visible if the user is in another tab.

All we have to do to get that going is update our `Tick` action in the reducer. I'll even show off ReasonML's interop with JavaScript by updating the document title. Note the `%bs.raw` directive, this allows us to put on the JavaScript training wheels and use it directly.

```reason
let updateTitle: string => unit = [%bs.raw
  {|
  function updateTitle(remaining) {
    document.title = "⏰ " + remaining + " ⏰";
  }|}
];

[@react.component]
let make = () => {
let (state, dispatch) =
    React.useReducer(
      (state, action) =>
        switch (action) {
        | Start => {...state, isTicking: true}
        | Stop => {...state, isTicking: false}
        | Reset => {...state, seconds: 30}
        | Tick =>
          state.isTicking && state.seconds > 0
            ? {
              updateTitle(formatTime(state.seconds - 1));
              {...state, seconds: state.seconds - 1};
            }
            : state
        },
      {isTicking: false, seconds: 30},
    );

/* useEffect0 */


/* JSX return */
};
```

And with that, I am finished with the implementation of the timer:

![finished timer with title update](./finished_timer_title.png)

## Summary

With this tutorial we tackled the updated ReasonReact syntax with React hooks. when React hooks dropped late last year I could not wait to be able to use them in Reason projects. Now that they are here, we can take advantage of strong typed, composable, functional code.

We learned:

- how to make a basic stateless component
- how to use the `useReducer` hook
- how to use the `useEffect` hook
- how to define other React components in the same file/module.
- how to use basic styles in ReasonReact
- how to do interon with `%bs.raw`

I hope this has been a fun or useful experience, be sure to follow me @iwilsonq on [dev.to](https://dev.to/iwilsonq), [Twitter](https://twitter.com/iwilsonq), [Medium](https://medium.com/@iwilsonq) or anywhere else I roam.

If you want to how ReasonML works seamlessly with GraphQL, check out this article I wrote on [ReasonML with GraphQL, the Future of Type-Safe Web Applications](https://medium.com/open-graphql/reasonml-with-graphql-the-future-of-type-safe-web-applications-65be2e8f34c8).

If you'd like to keep up with future posts, [sign up for my newsletter here](https://buttondown.email/iwilsonq)!


Learn Reason React by building a Pomodoro Timer with React hooks

ReasonML with React Hooks Tutorial — Building a Pomodoro Timer


![](/steps.jpg)

ReasonML has stolen my attention recently.

If I'm not at work or running about, I am probably digging into some ReasonML/OCaml repositories like an addict in the tenderloin.

Perhaps I like it for the unparalleled incremental build speed.

Perhaps I like it because its not too different from JavaScript yet it nets me a plethora of built-in advantages like type safety.

Perhaps I like it because of my affinity for math in school, and the functional paradigm gives me a warm fuzzy feeling inside.

There are a few reasons, no pun intended, for my love of Reason. Just like a functional program wields function composition with immutable state to achieve its goal, Reason's composition of the best of OCaml and JavaScript make it a strong candidate for the future of programming.

## The Edge of OCaml

For starters, Reason is basically a syntax upgrade to OCaml. Let me start by describing how that helps us.

### Speed

OCaml is a pretty damn fast language. It's incremental build times dwarf that of almost any other language. Since Reason is just a toolchain on top of OCaml, it maintains the many of the same characteristics of OCaml.

For instance take a look at this table from the docs of [fastpack](https://fastpack.sh), an alternative to Webpack or Parcel for bundling JavaScript applications.

_~1100 modules / 5.3Mb / MB Pro 2017_

|                  | Fastpack | Webpack | Parcel |
| ---------------- | -------- | ------- | ------ |
| initial build    | 0.811s   | 3.86s   | 11.07s |
| persistent cache | 0.208s   | N/A     | 1.39s  |
| watch mode       | 0.088s   | 0.226s  | 0.291s |

Fastpack is still rather new but these numbers are promising -- and the result implies we can made super-quick devtools for a vanilla JavaScript workflow.

### Static Typing

Another thing Reason inherits from OCaml is a power, nearly impenetrable type system. The compiler does a solid job of making sure you exhaust all of your options in branching logic.

It also does away with silly errors like "undefined is not a function" or "cannot read property 'x'". The same could be said about adopting TypeScript or Flow, but they do not _force_ you to cover such cases.

### ...with Great Inference

It's powerful type inference cleans up a lot of the verbosity associated with annotating functions and variables with types. The following function adds two integers. Not two floats or two strings, just two integers.

```reason
  /* the type system knows that the arguments and the return value are ints here */
  let add = (a, b) => a + b;
```

If that example is too basic, then try this one. Note how I am not annotating the types in the function signatures:

```reason
  type animal =
    | Dog
    | Cat
    | Octopus;

  let animalToString = animal =>
    switch(animal) {
    | Dog => "dog"
    | Cat => "cat"
    | Octopus => "octopus"
    };

  let getWelcomeMessage = (name, visits, animal) => {
    "Hello " ++
    name ++
    ", you've visited this website " ++
    string_of_int(visits) ++
    " times and your favorite animal is the " ++
    animalToString(animal);
  };
```

The ReasonML/OCaml type system is capable of inferring based on our usage what the return types are, as well as each of the arguments. How neat is that?

### Industry Proven

OCaml is a proven language of academics and industries where safety and mission critical code is paramount. This was one of the reason's it was adopted as the base for ReasonML.

At Facebook, OCaml is used to build some of their important everyday tools, like [Flow](https://flow.org) and [Hack](https://hacklang.org). But they're also working on Reason, which in my opinion, is neat because Reason brings more joy than flow.

## The Wit of JavaScript

With Reason comes a lighter, more JavaScript-like syntax. The first example I showed above would work just as well in regular JavaScript.

### Syntax

Reason syntax is far easier to read and digest than that of OCaml, and most other functional languages for that matter.

### Easy Build System

Its massively more accessible to newcomers than OCaml in that you probably wont spend days trying to install your dependencies properly. When using BuckleScript its often just another npm install {package}.

### JavaScript Interop

If you need training wheels when writing Reason, do not fear. You can use special directives to write JavaScript directly in your Reason code. Its not cheating, the language was designed this way to make migrating codebases easier.

### NodeJS Too

The language that powers web applications can be used on the server with the help of NodeJS. The language being Reason of course. Since it transpiles to JavaScript, theres no reason you cannot simply write Reason which becomes server code.

You can write basically everything in your tech stack with JavaScript and in most cases it will be just fine. What motive would someone have to write Reason then, especially if they have built their likely profitable career on JavaScript?

## The Courage of Reason

Over the past few weeks, I've been exploring writing Native Reason code. I think some of the projects that are being developed show great courage in showing off the potential of ReasonML.

While I certainly appreciate it's benefits on the frontend when transpiled to JavaScript, it would be super neat if I could write it on the server too.

I want to communicate with databases, make blazing quick command line tools, and write super efficient servers, perhaps serving GraphQL.

And I want to do it with the same language that I'm writing in for my web applications.

Currently, we can do this with JavaScript, but I think we can do better.

By further leveraging the OCaml ecosystem we can actually write incredibly robust servers and developer tools.

The [Esy](https://esy.sh) package manager allows us to install and build packages from npm or opam in a convenient package.json fashion without having to manually hack system dependencies.

As Esy further develops, Reason on the backend will become increasingly more accessible to developers looking to write stupidly fast native code.

If you're interested in what's already been made with Esy, check out the following projects:

- [fnm](https://github.com/Schniz/fnm), an alternative to nvm for managing your NodeJS version. It's much faster than nvm.
- [fastpack](https://fastpack.sh/), a ridiculously fast JavaScript bundler
- [revery](https://www.outrunlabs.com/revery/), a desktop UI framework like electron, except without downloading a whole browser onto your users' computer.

And there are more out there in the **Forests of Open Source**.

This certainly won't be my last post on this topic so stay tuned for more Reason evangelism on the horizon.


Discover the features of Reason that make it so appealing to a JavaScript developer.

The Edge, Wit, and Courage of ReasonML


![](https://thepracticaldev.s3.amazonaws.com/i/aejew3ps1khqnw7gy0yk.png)

_I made this graphic myself_

ReasonML, also known as JavaScript-flavored OCaml, offers nearly impenetrable type safety for developing user interfaces. By adopting a static type system, you can eliminate an entire class of errors before your app is served.

We’re going to look into building a small web application that uses consumes a GraphQL endpoint using ReasonML. We’ll cover:

- getting started with a ReasonReact project
- setting up a client with reason-apollo
- sending queries
- mutating data

If you’re new to both GraphQL and ReasonML, I’d suggest learning one at a time. Learning more than one big thing at once is often difficult for me. If you’re experienced with JavaScript and GraphQL, but want to learn ReasonML, read on, but keep the [docs](https://reasonml.github.io) handy.

## Getting Started - Establishing a ReasonReact Project

In order to get going with ReasonML, we must first install the cli, `bsb-platform` that handles bootstrapping the project. You should also get an editor plugin that helps with developing ReasonML apps. If you’re using VSCode, reason-vscode by Jared Forsyth is my preferred plugin.

```bash
npm install -g bsb-platform
```

This installs the BuckleScript compiler that turns our ReasonML into wonderful JavaScript which has already been type-checked and can be run in the browser.

Now we can initialize our project and hop right in.

```bash
bsb -init reason-graphql-example -theme react
cd reason-graphql-example
npm install
```

- The `init` argument specifies the name of the project we’re initializing.
- The `theme` argument specifies the template we wish to use. I usually just choose the react theme.
- We run `npm install` to install dependences just like in any other JavaScript project.

With the project scaffolded, we can try to build it. In two separate terminal panes, run:

```bash
npm start
# and
npm run webpack
```

- `npm start` tells BuckleScript (bsb) to build the project watch for changes to your .re files.
- `npm run webpack` fires up webpack to build your main JavaScript bundle

_Quick tip: you’ll notice that the webpack output is in the **build** folder but the index.html file is in the **src** folder. We can make serving the project a little bit easier by moving the index.html file to the build folder and rewriting the script tag to point at the adjacent Index.js file. _

With all that taken care of, you can serve your build folder using `http-server build` or `serve build` and check out the project.

![initial screen](https://thepracticaldev.s3.amazonaws.com/i/sfcjd5lxm76wsycbrcny.png)

When I’m developing a ReasonML project, I’m running 3 terminal tabs:

1. `npm start` to transpile ReasonML to JavaScript
2. `npm run webpack` to bundle JavaScript
3. `serve build` to actually serve the build on a port

Before we can get to the fun stuff, we still must clear out the boilerplate and set up react-apollo.

Go ahead and remove the Component1 and Component2 files, and then update Index.re to the following:

```ocaml
ReactDOMRe.renderToElementWithId(<App />, "root");
```

Update index.html to:

```html
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>ReasonML GraphQL Example</title>
  </head>
  <body>
    <div id="root"></div>

    <script src="./Index.js"></script>
  </body>
</html>
```

Finally, create an App.re file and add the following:

```ocaml
/* App.re */
let str = ReasonReact.string;
let component = ReasonReact.statelessComponent("App");

let make = _children => {
  ...component,
  render: _self =>
	<div>
	  <h1> {"Hello ReasonReact" |> str} </h1>
	</div>
};
```

You might have to re-run your terminal commands, but with all that said and done, you should have something like this appear on your screen:

![hello reason react](https://thepracticaldev.s3.amazonaws.com/i/7732nf5s6g7o93r406rp.png)

It feels like a lot of effort to get started, but accepting early friction for a smoother experience later on is the tradeoff here.

## Initializing Reason Apollo

In order to get set up with Apollo we’re going to run:

```bash
npm install -S reason-apollo react-apollo apollo-client apollo-cache-inmemory apollo-link apollo-link-context apollo-link-error apollo-link-http graphql graphql-tag apollo-link-ws apollo-upload-client subscriptions-transport-ws
```

That looks like a big install command. It is, but only the first package, reason-apollo, is consumed in our ReasonML code. However, reason-apollo is a library of binding labels depends on these other JavaScript packages.

In order to make writing GraphQL queries more friendly we’ll need one more dev dependency.

```bash
npm install -D graphql_ppx
```

As that installs we can open up our bsconfig.json file and update the “bs-dependencies” and “ppx-flags” keys like so:

```json
// bsconfig.json
{
  "bs-dependencies": ["reason-react", "reason-apollo"],
  "ppx-flags": ["graphql_ppx/ppx"]

  // other fields...
}
```

The “bs-dependencies” array tells BuckleScript to include those npm modules in the build process. The ppx flags array lets our IDE know how to handle preprocess certain directives, GraphQL in our case.

Create a file inside the src folder called Client.re. This is where we will declare our instance of the Apollo Client.

```ocaml
/* Client.re */
let inMemoryCache = ApolloInMemoryCache.createInMemoryCache();

let httpLink =
  ApolloLinks.createHttpLink(~uri="https://video-game-api-pvibqsoxza.now.sh/graphql", ());

let instance =
  ReasonApollo.createApolloClient(~link=httpLink, ~cache=inMemoryCache, ());
```

> Note: If this uri, https://video-game-api-pvibqsoxza.now.sh/graphql does not work, please send me a message on twitter or here in the comments and I’ll update that as quickly as possible

When we work with ReasonML, any variable that we create with a `let` binding is automatically exported from the module for us.

With the instance created, we can reference it in any of our other .re files. Update Index.re to the following:

```ocaml
/* Index.re */
ReactDOMRe.renderToElementWithId(
  <ReasonApollo.Provider client=Client.instance>
    <App />
  </ReasonApollo.Provider>,
  "root",
);
```

It looks a little like a standard React JS application, with a couple caveats. Notice that there are no import statements. In ReasonML, we have access to all of the namespaces built in our application. From the perspective of Index.re, We can see the `Client` and the `App` modules.

When we create a .re file in our src folder, it becomes a module. We could also declare our modules explicitly within our files.

It is now time to consume our API.

## Sending Queries and Rendering a List

While writing this article I created a small Node GraphQL server, the code of which is available at [this repo](https://github.com/iwilsonq/video-game-api). To keep costs low, I declared an array of mock data to return on each GraphQL request rather than host a database.

Rather than create a todo app, I decided to create a list of video games that I played at some point long ago. Then, I could check if I finished it or not, thus remembering the games that I still haven’t beat.

As we are working with a GraphQL server, we should be able to figure out exactly how to call it by observing the schema.

```Graphql
  type VideoGame {
    id: ID!
    title: String!
    developer: String!
    completed: Boolean!
  }

  type Query {
    videoGames: [VideoGame!]!
  }

  type Mutation {
    completeGame(id: ID!): VideoGame!
  }
```

Currently, we have one query and one mutation, both of which operate around this `VideoGame` type. A GraphQL adept will notice that every return value is non-nullable, that is, these responses cannot return unset fields or null objects.

Soon we’ll see why all of the !’s are particularly important for our ReasonML code.

Let’s begin by defining the query in on top of App.re, just below the `component` declaration.

```ocaml
/* App.re */

module VideoGames = [%graphql
  {|
  query VideoGames {
    videoGames {
      id
      title
      developer
      completed
    }
  }
|}
];

module VideoGamesQuery = ReasonApollo.CreateQuery(VideoGames);

/* let make = ... */
```

Comparing with the JavaScript in react-apollo, this code would be most analogous to:

```js
const VideoGames = gql`
  query VideoGames {
    videoGames {
      id
      title
      developer
      completed
    }
  }
`

// later in render
render() {
  return (
    <Query query={VideoGames}> {/* ... */} </Query>
  )
}

```

Now let’s update the render function:

```ocaml
/* App.re */
let make = _children => {
  ...component,
  render: _self => {
	let videoGamesQuery = VideoGames.make();
	<div>
		<h1> {"ReasonML + ReasonReact + GraphQL" |> str} </h1>
		<VideoGamesQuery variables=videoGamesQuery##variables>
        ...{
             ({result}) =>
               switch (result) {
               | Loading => <div> {"Loading video games!" |> str} </div>
               | Error(error) => <div> {error##message |> str} </div>
               | Data(data) => <VideoGameList items=data##videoGames />
               }
           }
      </VideoGamesQuery>
	</div>;
  }
};
```

Here, we’re taking advantage of ReasonML’s coolest feature - [pattern matching](https://reasonml.github.io/docs/en/pattern-matching). Pattern matching combined with [variants](https://reasonml.github.io/docs/en/variant) makes the logic that you would otherwise put in branches of if-else statements more linear and easier to follow. It is also reduces branch checking to [constant rather than linear time](https://reasonml.github.io/docs/en/variant), making it more efficient.

If the ReasonML code ever seems more verbose, just remember we’re still getting perfect type safety when it compiles. We still need to build the `VideoGamesList` component as well as define the `videoGame` record type.

Starting with the record type, create a new file called VideoGame.re and add the following:

```ocaml
/* VideoGame.re */

[@bs.deriving jsConverter]
type videoGame = {
  id: string,
  title: string,
  developer: string,
  completed: bool,
};
```

The `videoGame` type as we have it here, has 4 fields, none of which are optional. The BuckleScript directive above it adds a pair of exported utility methods that allow us to [convert between ReasonML records and JavaScript objects](https://bucklescript.github.io/docs/en/generate-converters-accessors).

> Tip: when Apollo returns a response, it returns untyped JavaScript objects. The `jsConverter` directive gives us an exported method called `videoGameFromJs` that we can use to map the Apollo query data to fully typed ReasonML.

To see this mechanic in action, create a new file called VideoGameList.re and add:

```ocaml
/* VideoGameList.re */
open VideoGame;

let str = ReasonReact.string;
let component = ReasonReact.statelessComponent("VideoGameList");

let make = (~items, _children) => {
  ...component,
  render: _self =>
    <ul style={ReactDOMRe.Style.make(~listStyleType="none", ())}>
      {
        items
        |> Array.map(videoGameFromJs)
        |> Array.map(item =>
             <li key={item.id}>
             	<input
                  id={item.id}
                  type_="checkbox"
                  checked={item.completed}
                />
                <label htmlFor={item.id}>
                  {item.title ++ " | " ++ item.developer |> str}
                </label>
             </li>
           )
        |> ReasonReact.array
      }
    </ul>,
};
```

1. Open the `VideoGame` module (VideoGame.re) at the top so we can use all of it’s exports in the `VideoGameList` module.
2. Declare the component type and string rendering shorthand.
3. Define a make function that expects one prop, `items`.
4. Inside the render function, pipe the items to convert JS objects to ReasonML records, map records to JSX, and finally output them as an array.

> Note: Piping basically reverses the order of function calls to potentially improve readability. With the `|>` operator, the `items` object is applied to each function as the _last_ argument.

Though I like prefer the piping style, the following are equivalent.

```ocaml
items
	|> Array.map(videoGameFromJs)
	|> Array.map(renderItem)
	|> ReasonReact.array;

ReasonReact.array(
	Array.map(
		renderItem,
		Array.map(
			videoGameFromJs,
			items
		)
	)
);
```

I think we are ready to once again compile and serve our project. If you haven’t already, run this command in your project root:

```bash
yarn send-introspection-query https://video-game-api-pvibqsoxza.now.sh/graphql
```

This generates a `graphql_schema.json` file that Reason Apollo uses to type check your queries. If your ReasonML app asks for a field that isn’t on the schema, or if it doesn’t properly handle optional data types, it will not compile.

The strict typing serves as a wonderful sanity check for writing queries and mutations.

When all is said and done, you should see the following.

![finished screen](https://thepracticaldev.s3.amazonaws.com/i/96prj40pfw9frc23j68r.png)

Don’t yell at me for not finishing the main story in Skyrim.

## Mutating Data

One thing you may notice thus far is that clicking the checkboxes doesn’t do anything. This is expected, since we have not yet wired up a mutation.

Let us begin by recalling our schema above, and creating a module for the mutation to mark a game completed.

Inside VideoGameList.re, add these modules to the top of the file just beneath the call to create a component.

```ocaml
/* VideoGameList.re */
module CompleteGame = [%graphql
  {|
  mutation CompleteGame($id: ID!) {
    completeGame(id: $id) {
      id
      completed
    }
  }
|}
];

module CompleteGameMutation = ReasonApollo.CreateMutation(CompleteGame);
```

For the render prop of the mutation, it’ll look pretty similar to the JavaScript version. I’ll put this code here and then walk through it, starting from inside the `<li>` tag.

```ocaml
/* VideoGameList.re */

<li key={item.id}>
  <CompleteGameMutation>
    ...{
        (mutate, {result}) => {
          let loading = result == Loading;
          <div>
            <input
              id={item.id}
              type_="checkbox"
              checked={item.completed}
              onChange={
                _event => {
                  let completeGame =
                    CompleteGame.make(~id=item.id, ());
                  mutate(~variables=completeGame##variables, ())
                  |> ignore;
                }
              }
            />
            <label
              htmlFor={item.id}
              style={
                ReactDOMRe.Style.make(
                  ~color=loading ? "orange" : "default",
                  (),
                )
              }>
              {item.title ++ " | " ++ item.developer |> str}
            </label>
          </div>;
        }
      }
  </CompleteGameMutation>
</li>
```

Like the Apollo `VideoGamesQuery` component we used earlier, the `CompleteGameMutation` component we see here passes to its children a mutate function as well as a results object.

This particular component is not the best example to show off how you could use that results object, as I only take advantage of it when a single item is being updated. If it is, I color the text of the item label green and call that the loading state.

I’m no UX guy, but I think that’ll do for today.

## Wrapping Up

ReasonML is a pretty powerful and expressive language. If you are new to ReasonML and itching to build some type safe user interfaces, here are some resources to learn from:

1. Many of the third party tools we use in JavaScript come out of the box with ReasonML. This [article by David Kopal explains how](https://medium.freecodecamp.org/psst-heres-why-reasonreact-is-the-best-way-to-write-react-5088d434d035?source=linkShare-2467058898a1-1543182271), along with some other reasons why writing ReasonML is so cool.
2. [Jared Forsyth’s blog](https://jaredforsyth.com) has great content about ReasonML and OCaml. He is one of the most active contributors to the community.
3. I get most of my learning done through the [ReasonML docs](reasonml.github.io) and the [BuckleScript docs](bucklescript.github.io). They are easy to follow and contain powerful insights on the design choices when implementing language features.

If you want to quickly set up your own GraphQL server then check out my other article, [Learn to Build a GraphQL Server with Minimal Effort](https://medium.freecodecamp.org/learn-to-build-a-graphql-server-with-minimal-effort-fc7fcabe8ebd).

I hope to write more articles about ReasonML and GraphQL in the future. If these interest you then by all means follow me on [Medium](https://medium.com/@iwilsonq) and on [Twitter](https://twitter.com/iwilsonq)!

This article was originally published in _[Open GraphQL on Medium](https://medium.com/open-graphql/reasonml-with-graphql-the-future-of-type-safe-web-applications-65be2e8f34c8)_.


Build a small ReasonReact web application that consumes a GraphQL endpoint using reason-apollo

ReasonML with GraphQL, the Future of Type-Safe Web Applications


ReasonML is a super fast, expressive, and functional programming language. Currently, it can be compiled to optimized JavaScript for the web, WebGL/OpenGL for graphics rendering, or even native bytecode.

One of my favorite features of Reason are variant data types. These types allow us to handle enums in a sane way, forcing us to handle all possibilities for a particular scenario. We can define a variant type like this:

```reason
type color =
  | Red
  | Blue
  | White
  | Black
  | Grey;
```

We see that the type `color` can be represented as this enumeration of different colors. Not too complicated, but not too enlightening either. In JavaScript, we could handle this with an object mapping:

```javascript
const COLORS = {
  RED: 'red',
  BLUE: 'blue',
  WHITE: 'white',
  BLACK: 'black',
  GREY: 'grey',
};
```

I used maps like this all the time in my JavaScript projects, they help a ton when your goal is to keep constants defined in the same place. If you need to update, add, or remove a field, you only need to do so in one location.

If this were the whole story, I would probably decide that a compiled-to-js programming language like Reason is not worth the effort involved when I could just add TypeScript support. After all, so far it has only saved us a tiny amount of code.

Let's take a look at an example to see how Reason would help us where ordinary JavaScript falls short.

```javascript
function getMonthlyPriceForCarColor(color) {
  switch (color) {
    case COLORS.RED:
      return 28;
    case COLORS.BLUE:
      return 24;
    case COLORS.WHITE:
      return 20;
  }
}
```

This function takes a color (from our convenient colors lookup-map) and returns to us the additional monthly price of getting a Tesla Model S. In other words, getting a red Tesla costs more because it is the best color.

One other thing you might notice is that I did not provide a default case, and as an imperfect programmer, I neglected some of the other colors. JavaScript will not yell at me for this on its own, so I will probably have to find out the hard way that I forgot some of the other cases.

Hopefully QA will catch this bug before my code lands in production. But even if they're really thorough, I'd still have to make changes and push/review more code. Wouldn't it be nice if our typechecker could alert us on the fly?

The same function in Reason looks like this:

```reason
let getMonthlyPriceForCarColor = color =>
  switch(color) {
    | Red => 28
    | Blue => 24
    | White => 20
  };
```

First of all there's less code, which is great, but beside the point. In practice, this function will actually have red squiggly underlines, alerting us that our switch is not exhaustive - it does not cover all of the possibilities or our `color` variant.

The error message is actually quite helpful when this happens.

![Error: Non exhaustive switch statement](/images/non-exhaustive.png)

Fixing this issue simply requires that you cover the other possibilities.

```reason
let getMonthlyPriceForCarColor = color =>
  switch(color) {
    | Red => 28
    | Blue => 24
    | White => 20
    | Black => 0
    | Grey => 0
  };
```

Reason wont let us compile our code if we don't have a case for each possibility in this function. This is a sampling of the incredibly powerful typesystem we have with Reason.

## Variants as Constructors

As I've demonstrated so far, variants can be used as enumerations, but they exhibit a power that takes enumeration to a whole new level. Variants can be used as generic constructors that take arguments, allowing developers to further customize applications for their use case.

For example, we can adjust our price (arbitraily) based on the shade of grey or even go as far as to specify a totally arbitrary color somewhere in the RGB scale.

Updating our color type to the following:

```reason
type color =
  | Red
  | Blue
  | White
  | Black
  | Grey(float)
  | Rgb(int, int, int);
```

Now when we run our function, we can let the customer to pick whatever color they want. To keep make the pricing more reasonable with our already hardcoded values, we'll allow grey to range from $0 to $20. depending on whatever number given between 0.0 and 1.0.

The `Rgb` constructor will be the most expensive since we have to create new paint in order to satisfy that requirement. The higher the values of red, blue, and green color, the closer to \$36 it will be.

```reason
let getMonthlyPriceForCarColor = color =>
  switch(color) {
    | Red => 28
    | Blue => 24
    | White => 20
    | Black => 0
    | Grey(pct) => int_of_float(pct *. 20.0)
    | Rgb(red, green, blue) => {
      /* completely random calculation. Tesla probably does not do this */
      let sum = red + green + blue;
      if (sum > 500) {
        36
      } else {
        32
      }
    }
  };

Js.log(getMonthlyPriceForCarColor(Red));                /* 28 */
Js.log(getMonthlyPriceForCarColor(Grey(0.64)));         /* 12 */
Js.log(getMonthlyPriceForCarColor(Rgb(150, 210, 67)));  /* 32 */
Js.log(getMonthlyPriceForCarColor(Rgb(150, 210, 167))); /* 36 */
```

This is pretty neat huh? This example displays the expressive power of a robust type-safe language like Reason.

When we introduce constructor arguments like this, we no longer have an ordinary switch statement that you can find in most programming languages. We call this _pattern matching_ in Reason.

In conjuction with data structures like variants, tuples, and lists, pattern matching creates a readable and concise flow of logic.

## Refactor with confidence

The only thing I have yet to do to make this example stronger, is validate the constructor inputs. So to send off this post with a bang, I am going to make some helper functions.

```reason
let validatePercentage = pct =>
  restrictRangef(pct, 0.0, 1.0);

let validateRgb = (red, blue, green) => {
  let red = restrictRange(red, 0, 255);
  let green = restrictRange(green, 0, 255);
  let blue = restrictRange(blue, 0, 255);
  (red, blue, green);
};
```

These functions validate the required input to the extend that they cut off the values if they are too low or too high. Here are their corresponding `restrictRange` functions.

```reason
let restrictRange = (number, min, max) =>
  if (number > max) {
    max;
  } else if (number < min) {
    min;
  } else {
    number;
  };

let restrictRangef = (number, min, max) =>
  if (number > max) {
    max;
  } else if (number < min) {
    min;
  } else {
    number;
  };
```

One last thing to note is that we must have separate `restrictRange` functions for `int` and `float` types. By convention, when we have functions that take ints, their float variation will have the same name but with an "f" at the end.

A little extra code here is a small price to pay here when we have superior type coverage.

Finally I can update our `getMonthlyPriceForCarColor` function with our new helpers:

```reason
let getMonthlyPriceForCarColor = color =>
  switch (color) {
  | Red => 28
  | Blue => 24
  | White => 20
  | Black => 0
  | Grey(pct) => int_of_float(validatePercentage(pct) *. 20.0)
  | Rgb(red, green, blue) => {
      let (r, g, b) = validateRgb(red, green, blue);
      let sum = r + g + b;
      if (sum > 500) {
        36
      } else {
        32
      };
    }
  };
```

# And thats a wrap

We've taken a look at variants and how we can use them with constructor arguments through pattern matching. This is a super powerful feature that you won't find in just any modern programming language.

When you build an application with complete type safety, you begin to reap the advantages as the size of your project grows and you begin to make refactors. Knowing that your code compiles increases your confidence that you wont break critical or even basic features in production.


Learn to wield ReasonML variants to create better, typesafe web applications

Intro to ReasonML Variants


Vanilla JavaScript is untyped by nature, some will call it “smart” because it is able to figure out what is a number or a string.

This makes it easier to run JavaScript code, it simply needs to be executed in a browser or Node.js runtime. However, its vulnerable to numerous runtime errors that can spoil your user experience.

If you’ve ever experienced the following, you would benefit from adopting a type system.

- After fetching a list of data you may find that a certain field doesn’t exist on one of the records, causing the app to crash unless explicitly handled.
- An instance of a class you imported doesn’t have a method you’re trying to invoke.
- Your IDE doesn’t know what methods and properties are available, so it cannot easily assist you with autocomplete.
- Difficulty reasoning about code, type systems at a glance make it easier to refactor

## Flow, TypeScript, or ReasonML

Let's say you have an existing codebase that you wish to make bulletproof. With respect to type errors, you could try adopting Flow or TypeScript -- they have a fairly similar syntax.

On the other hand adopting one of these in a large, existing codebase is difficult. You would have a backlog crammed with tasks relating to creating types and interfaces with code that made not have been designed in a type friendly way.

On top of all of this, Flow and TypeScript do not offer 100% type safety in their code.

Reason accomplished perfect type safety through inference, and makes annotating variables and function signatures much more straightforward.

## Simple and Clearly Contrived Examples

Consider the following code:

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

In basic JavaScript these arguments can be numbers or strings. In TypeScript or Flow these arguments can be annotated like so

```javascript
let add = (a: number, b: number) => a + b;
```

The first code snippet knows that we are adding two int values. Not two floats nor two strings, there are different operators for those addition operations. JavaScript can hardly tell the difference between an int and a float.

Allow me now to expose this gradual typing with a contrived example.

```javascript
let add = (a: string, b: number) => a + b;
add('some string', 5); // outputs: "some string5"
```

That function works! This is absolutely preposterous! Now how does Reason handle this?

```reason
let add = (a, b) => a + b;
add("some string", 5);
/*
This has type:
  string
but somewhere wanted:
  int
*/
```

This function was flawed at the implementation level. Reason has different operators for int, float, and string addition.

The purpose of this contrived example was to show that it is still very possible to have odd type "errors" even though it wont _break_ the application.

In a pure Reason program, developers will not have to deal with productions bugs that have to do with types or null values.

## Developer Experience

One of the neatest features of TypeScript is the enhancement you get in code editor suggestions & autocompletion.

This is one area where TypeScript has a leg up on Reason, because a TypeScript program doesn't need to compile perfectly in order to offer autocompletion. Reason makes you fix errors in syntax or types before it gives you helpful autosuggestion.

This is the case on VSCode, but I know many Reason developers use vim. I cannot answer for the level of support each editor has.

Even though I am a big fan of ReasonML, I have built production applications with TypeScript or Flow and I enjoy them as well. The wave behind TypeScript makes it especially good to pick up these days, considering there is plenty of writing and community support behind it.

Reason on the other hand is harder to pick up because there is comparatively less writing and content behind it. Through blog posts like this, I am hoping to change that.

If you have some interest in checking out Reason, I'd start with the [docs here](https://reasonml.github.io). Also, be sure to follow people like [@jordwalke](https://twitter.com/@jordwalke), [@jaredforsyth](https://twitter.com/@jaredforsyth), and [@sgrove](https://twitter.com/@sgrove) on twitter. They are pretty knowledgable with respect to the ReasonML/OCaml ecosystem.

If you want to how ReasonML works seamlessly with GraphQL, check out this article I wrote on [ReasonML with GraphQL, the Future of Type-Safe Web Applications](https://medium.com/open-graphql/reasonml-with-graphql-the-future-of-type-safe-web-applications-65be2e8f34c8).


Discover how a type system improves your developer workflow

How a Type System Improves your JavaScript Code

Learn about Rust, ReasonML, GraphQL, and other tech goodies.

Ian Wilson

Fullstack Web Developer living in the San Francisco Bay Area.

Sign Up for the Newsletter