The rise of complexity
As the code becomes increasingly complex, the likelihood of bugs, often concerning trivial aspects of programming and therefore easily avoidable, increases accordingly. For example, they may involve passing an incorrect parameter to a function – perhaps because it’s part of an outdated portion of code or the result of another developer’s unreadable contribution.
A static type checker to the rescue
When designing React components, for example, we use TypeScript to define the type of values that the function or class expects as parameters. By working in this way we reduce the probability of bugs by reporting an error in the code in advance and – no less important – we write a “living documentation” of the code, which can save us a lot of time when we come back to work on it after a while, or if other developers get their hands on it later.
Using TypeScript in a project is a bit like having a person by your side correcting you and alerting you to problems as you write an application’s code.
Do it early
In the past we’ve had to start a web development project without being able to include a type checking system: at the beginning we didn’t experience any particular problems, but as the codebase expanded and new developers were added to the team, the number of bugs and the time needed to reuse existing components and functions increased. Using TypeScript (or another type checker) at the start of a new project is good practice in order to avoid getting in trouble when complexity inevitably increases later on. To be frank, using a static type checker generally means more work for the programmer, because they will have to design the type management for each feature to be implemented in advance; however, the additional effort will be largely repaid in the future by fewer bugs and the ease of reading old portions of code.
TypeScript & Flow