In this book, we are exploring the techniques and idioms available in type-driven development. Some people also refer to type-driven development as type-level programming. Static types offer several benefits, including:

• Preventing incorrect code from getting a chance to run
• Documenting the current codebase
• Helping to correctly refactor the codebase by pointing out any parts of code you may have missed
• Offering richer IDE support, for example, auto-completion
• Better performance when the compiler knows types and can optimize code accordingly

Type-driven development is the practice of using static types to restrict what your code can do. Normally, your programming language gives you enough power to represent any computation. With type-driven development, you are essentially trying to make it impossible for your code to do undesirable things.

In this chapter, we will do some basic critical analysis of a piece of code and look at the possible errors it may contain. We'll also introduce ReasonML, the language we will use to learn type-driven development and compare it with JavaScript. We'll get started with a basic Reason project and then introduce Reason, as well as its related communities and ecosystems.

In this chapter, we will cover the following topics:

• The main idea and benefits of type-driven development
• Dynamically typed code versus its statically typed ReasonML equivalent
• The Reason language, ecosystem, and related projects
• How to set up a basic Reason project, which we will use throughout this book
• The Try Reason online playground

Let's suppose that you have the following JavaScript:

// src/Ch01/Ch01_Demo.js
function makePerson(id, name) { return {id, name}; }

A lot of things can go wrong with the preceding code; they are as follows:

• The caller can pass in nulls or undefined values as arguments
• The caller can pass in unintended types of arguments
• The caller can manipulate the returned person object any way they like, for example, they can add or remove properties

In other words, this code doesn't prevent a number of potential errors. In JavaScript, we have linters, such as ESLint (https://eslint.org/), that check for a lot of possible errors, but you have to remember to find them, enable them, and then work around their limitations. A linter can be helpful in various other ways, such as by pointing out the recommended best practices in a coding style. However, linters in JavaScript are often re-purposed to perform static type checking tasks as well; because they offer so much flexibility and need to be configured (in fact, people usually upload their preferred sets of configuration for different styles of programming), there may be large differences in what exactly gets checked across different codebases.

With a static type system, we can restrict our makePerson function in quite a few ways. Here's an example using ReasonML, the language that we're using in this book to learn type-driven development:

/* src/Ch01/Ch01_Demo.re */
type person = {id: int, name: string};
let makePerson(id, name) = {id, name};

Here, we define a new data type, person, and a function that creates a value of the type given the required arguments. We have one more line in the preceding code than we do in the JavaScript code, but in exchange, we get the following guarantees:

• The caller cannot pass in null or undefined arguments
• The caller cannot pass in the wrong types of arguments
• The caller cannot mutate the result value of the function

Notice in the previous example that we didn't have to declare the argument or types for the makePerson function. This is because ReasonML has great type inference that automatically understands that int, string, and person must be the only possible types allowed for those parts of the function.

ReasonML will compile the previous code into the following JavaScript:

// src/Ch01/Ch01_Demo.bs.js
function makePerson(id, name) { return [id, name]; }

As you can see, the preceding code looks almost exactly like the JavaScript we wrote earlier—the main difference is that Reason's JavaScript compiler turns records (which we'll explore later) into JavaScript arrays to take advantage of their speed.

This is just a glimpse of what static types can do to your codebase. In the coming chapters, we'll have a look at many more practical applications.

We're going to explore type-driven development using ReasonML (https://reasonml.github.io/). Reason is a JavaScript-like syntax and is also a set of tools for OCaml (https://ocaml.org/). OCaml is a mature statically typed functional programming language with excellent support for object-oriented and modular programming.

We're going to write Reason code and compile it to JavaScript using the BuckleScript compiler (https://bucklescript.github.io/). BuckleScript takes input from Reason code and outputs essentially a simple subset of ES5 (that is, no ES2015-style classes, no arrow functions, and so on). This will allow us to write strongly statically typed code and see what the output JavaScript looks like with all the types stripped away.

The Reason toolkit currently consists of:

• A code formatting and syntax translation tool, refmt
• An interactive code evaluation environment, rtop
• A build manager for native-compilation projects (we won't need this one for this book), rebuild
• A tool that provides intellisense abilities to editors, ocamlmerlin-reason

These tools work together to provide a minimal, yet powerful, development experience. Together with a good editor (we recommend Visual Studio Code), they cover most of your day-to-day development needs.

So why have we chosen ReasonML over something else? For example, TypeScript and Flow are popular languages that target JavaScript today (among many others), but we chose Reason because:

• It has a powerful and elegant type system, which neatly fits together many type-driven development concepts
• Its JavaScript compiler (BuckleScript) has incredibly fast compiles, optimization, and high-quality dead-code elimination; fast compiles are great to have if you’re doing type-driven development, and performant code is great to have in any system
• It has a very helpful and enthusiastic community that's very accessible
• It gives you access to the mature OCaml community and its aggregated knowledge base

We will take advantage of the contrasts between the two languages to understand how statically typed Reason code is converted into dynamically typed JavaScript code yet still runs safely by design.

The Reason website has a great quickstart guide as well as tutorials for setting up editor support. First, install NodeJS to get the node package manager (npm). Then, run the following:

npm install -g bs-platform
cd <your-projects-folder>
bsb –init learning-tydd-reason –theme basic-reason
cd learning-tydd-reason

Now we can do an initial compile with the following command:

bsb -make-world

The preceding command builds your entire project and its dependencies recursively. It will be almost instantaneous.

It's worth mentioning that we actually recommend running the preceding shell commands (substituting in your actual projects folder, of course), because throughout this book, we're going to arrange the code examples in the form of a single project, learning-tydd-reason, and the code examples that you type into the various given file names will fit together to make up that project.

You will almost certainly want to set up editor support in Reason so that you can get things like autocompletion and go to definition. The guides available on the ReasonML website (https://reasonml.github.io/docs/en/global-installation.html) are very helpful for this. Currently, Visual Studio Code (http://code.visualstudio.com/) is the best-supported editor; you will probably get the best results from using that.

Reason provides a fantastic resource for learners: an online Reason-to-JavaScript compiler and evaluator. To access it, go to the Reason website and click Try in the navigation bar at the top. You can use it to quickly try out different ideas.

Let's run through a quick example using Try Reason to get our bearings. Type in the example code from src/Ch01/Ch01_Demo.re into the Reason section of the Try Reason web app. Now add the following line after that:

let bob = makePerson(1, "Bob");

Now if you examine the output JS, you should see that the following changes have been made:

• Types have been stripped away
• Records have been transformed into arrays without field names (records are roughly like C structs or JavaScript objects)
• Every declared value is explicitly exported (made public)

Note that we have purposely introduced very little actual Reason syntax in this chapter. If you are curious to explore the syntax (which is very similar to JavaScript at its core), it's best if you explore the excellent Reason website documentation. Since the focus of this book is type-driven development, in the upcoming chapters we will introduce all the syntax we will need and discuss its impact on our understanding of the code.

The ReasonML community is a helpful, fast-growing one. If you need help with anything, don't be afraid to ask. You'll only be a beginner once, and once you're comfortable, you'll be able to help other beginners. Check out the community page at https://reasonml.github.io/docs/en/community.html and drop by the discord chat as the first point of contact.

In this chapter, we introduced the basic ideas of type-driven development and critically analyzed a piece of dynamically-typed code to explore its potential error conditions that would be prevented by adding static types. We also introduced the ReasonML language and its ecosystem, set up our own Reason project, and got a glimpse of how it can compile statically typed code to JavaScript.

The next chapter will be an important one—we'll delve more into types, values, and working in Reason. See you there!