How the Type System Improves Your JavaScript Code

So you do not have time to turn around, and the month is already striving for its completion. A few days remain until the launch of a new thread on the course "JavaScript Developer" , according to tradition, before starting the course we will share with you the translation of useful material.

Vanilla JavaScript is not typed by nature. You can even call him “smart,” because he is able to calculate what is a number and what is a string.

This makes it easier to run JavaScript code in a browser or when running Node.js. However, it is vulnerable to numerous runtime errors (runtime), which can ruin your user experience.



If you ever happen to what will be described later, then you will only gain if you use the type system.

• After receiving a list of data, you find that a certain field does not exist in one of the records. This leads to a malfunction of the application if this case is not caught and not processed explicitly.
• The instance of the class you imported does not have the method you are trying to call.
• Your IDE does not know what methods and properties are available for modules and libraries, so it cannot offer auto-completion efficiently.

Flow, TypeScript or ReasonML

Let's say you have an existing code base that you want to make more reliable and stable. Taking into account existing typing errors, you can try to use Flow or TypeScript for this (they have fairly similar syntax).

On the other hand, using each of these bulky tools is tricky. You will load yourself with the work of creating types and interfaces for code that have not been previously developed.

Nevertheless, Flow and TypeScript do not provide 100% security when adding typing in code.
For this reason, ideal typing security is achieved through inference and makes annotating variables and function signatures simpler.

Simple and clearly contrived examples

Consider the following code:

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

In regular JavaScript, these arguments can be numbers or strings. In TypeScript or Flow, these arguments can be annotated as:

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

Now we are apparently setting exactly two int values. Not two floats or two strings; other operators are used for their addition operations.

Now let's take a look at a slightly modified example in Reason:

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

This feature works! And that may seem surprising. How does Reason understand this?

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

This feature had flaws at the implementation level. Reason has different operators for adding int, float and string.

The purpose of this simple example is to show that it is possible to have extra “type errors” even if this does not drop the application.

In a Reason program, developers do not have to deal with production bugs that arise due to incompatibility of types or null values.

Developer Experience

One of the nicest features in TypeScript is that you see suggestions for improvement or auto-completion in the code editor.

This is one area where TypeScript takes precedence over Reason, because a TypeScript program does not have to be compiled perfectly to offer autocompletion. Reason will force you to correct all errors in the syntax and types before offering you a useful fix.

This is how it works in VSCode, but I know many Reason developers who use vim. Here we will not go into comparisons.

Although I am a big fan of Reason, I also wrote applications in TypeScript or Flow. The hype wave around TypeScript provides a good incentive to choose it, because because of this, it has great community support.

Reason, on the other hand, is harder to use because fewer articles and documentation are available to it. I hope that with its development this will be corrected.

If you are interested in Reason, you can find its documentation here . And follow people like @jordwalke , @jaredforsyth and @sgrove on Twitter. They can tell a lot about the Reason / OCaml ecosystem.

If you want to know how Reason works with GraphQL, refer to my other article, “Reason with GraphQL, the Future of Type-Safe Web Applications” .

We are waiting for feedback on the material and, according to established tradition, we invite all readers to an open day , which will be held on March 25 by our teacher, Alexander Korzhikov .