Why be careful using Typescript
With a simple example
Premises
Lately, the use of Typescript is becoming more and more popular.
I agree with the use of Typescript, type systems eliminate a large number of errors in programs. Typescript comes in handy in some cases.
But Typescript doesn’t eliminate the type “problems” that exist in Javascript, at least not at runtime (but this too is opinionable). In fact, having a type system on Javascript does not completely guarantee immunity from either “type bugs” or type conversion (aka coercion).
I disagree when some developers say Typescript “makes refactoring easier”. In my opinion, refactoring is really facilitated when all code is covered by testing.
I’m not here to tell you if using plain Javascript is better than adding Typescript on top, you can read it in many articles to get your idea.
Instead, I will talk about how we can try to limit and improve some corner cases when we develop in Typescript but also in Javascript.
Typescript hides the DNA of Javascript
When we use Typescript we forget or just do not know the real functioning is really written in the DNA of Javascript.
Let’s take the simple case of a function that adds two numbers.
This function is very simple, we have a function declaration, with two parameters, the body of the function returns the sum of these two parameters.
But what if one of the two arguments is NaN.
This is because NaN in the DNA of Javascript is a number.
So what should we do in this case?
From my point of view, in a limited environment with Typescript what is sufficient is:
Managing this corner case, through the use of Number.isNaN, are you wondering why?
Because “Number.isNaN” compared to its global brother “isNaN”, does not do the coercion (Type Conversion), and when the context of the code is used it is circumscribed within the same application written in Typescript. Number.isNaN is sufficient in that particular case.
This is not the only edge case, but there are more, for the sake of simplicity I chose this to get to a very important point.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/isNaN
In fact, almost all IDEs will help you not to make mistakes, passing for example a string as an argument instead of a number.
Protect yourself when your code will be used externally
Yes that’s right, protect yourself when your code will be used externally.
Lately, I have created a Typescript project to create a generic library that can be used easily on projects that are not strictly written in Typescript.
In the end, what will have to come out of your project, written in Typescript, will be simple and pure Javascript. And at runtime, there will be no one to defend your code.
When you expose functions from your library, don’t limit yourself to just the way of thinking you apply when writing your project in Typescript.
Your simple “sum” function could be used in a way you don’t expect.
Remember, Number.isNaN checks if the value is NaN, it doesn't convert it.
With this example, I want to make you understand that using Typescript does not completely eliminate “problems” that are and will remain for a long time in the DNA of Javascript.
I know this example is silly, but with this simple example I am trying to make you understand that Typescript does not completely eliminate the main requirement that every Javascript developer must have: Knowledge of Javascript DNA.
Here is an example of how we might protect our beloved “sum” function.
Personally, in this case, I prefer to leave the user to the possibility of using type conversion. Of Course, there are other corner cases that we have to handle. For example “” (empty string, or string with empty spaces) and null toNumber return 0. So we can limit to allow the coercion for string and handle the respective corner cases. It may not be the best way, but the best way is the one that fits you best.
But to protect yourself, you need to know Javascript in depth.
Final Toughts
I hope this article has helped some of you understand the potential of knowing the tools we use in depth.
Each of us must study well the tools we use.
To conclude, using Typescript help, but on the other hand, adds complexity to a language that is good to know deeply and require the knowledge of tools to compile the code. Because we should master what we use, otherwise it would be like taking a knife but not knowing which way to hold it.
The tool itself is useful, but if we don’t know how to use it, we can get hurt.
Thanks for reading and feel free to add comments about your experiences :)
