JS Type enforcement

Have you ever faced a huge JS project and adding/editing features was a nightmare?

It could be that you had to dig deep into the functions to understand how they are used, and you'll end up inside a rabbit hole in Alice's wonderland. You could even find variables that were simultaneously objects and functions, resembling Shroedinger's cat.
Example:
var a = function() {return "a function";}; a.str="a string";
a() // "a function"
a.str // "a string"

Or perhaps it was less painful to copy-paste some similar functionality in another part of the project and pray for the best.

Fortunately project structure have evolved greatly in the last 1-2 decades.
JS code is now encouraged to be:

- modulated, so we don't have thousands of lines inside each file, making it easier to access the information we want.

- unit tested, so we can be sure that the functions that we write do what we actually want;

- properly documented. Let's face it, no one likes to read/skim through dozens lines of documentation every time when using a new function from a new file. Ideally we would just want to know what it does, what we need to feed it, and what comes out of it.
What it does should be clearly and concisely defined on its name.
What arguments we need to use and what it returns can be handled by type enforcement, which is the topic of this post.

Currently there are 2 main ways of enforcing types: with a static type checker( like Typescript) and dynamic type checkers (like PropTypes).

Typescript / FlowJs

If you're coming from a strongly typed language, such as Java, C# or C++, the odds are that JS is just too wild and confusing. It's a free for all fiesta and is weird to go to a point without a road laid down.

Typescript allows developers to hard type what every variable should be, what every function should return, use interfaces and even allows intellisense, just like a static type language (ex: BE languages).

Unfortunately, typescripts comes with a few downsides. Having every variable with a type defined dilutes the code, with more syntax noise and sometimes making it harder to read.
Also, developers that start using typescript will have a lot to learn before start collecting the benefits of typescript. [1]
Sometimes the benefits of static type languages, like intellisense and catching bugs earlier, outweights the burden of retraining a whole team of developers. Sometimes it doesn't.

But there are other options.

 

PropType

If we don't mind, or want, variables to be checked at runtime, we can use a dynamic type check library like PropTypes.

It has the advantage of allowing type checking on a different project and doesn't get compiled when going for production.

You can get 99% of the benefits of static types, without the extra syntax noise and cognitive overhead of type annotations. [1]

The disadvantage is that you can only catch the error after running the code, and you don't have access to the intellisense.

That said, it's also possible to use both if you wish, although it can also be a bit of an overkill.
Or use none at all at your own risk.

 

[1] https://medium.com/javascript-scene/you-might-not-need-typescript-or-static-types-aa7cb670a77b