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
No comments:
Post a Comment