The 5 Issues That Happen on TypeScript

If Javascript was a road, Typescript would be the guardrail: built on top of them, it helps you make sure you stay on track. But even if Typescript prevents you to shoot yourself in the foot in many cases, there are still some issues you do. Let’s review the most common.

Using any as a type

The main objective of Typescript is to add a type system on top of Javascript. The objective of adding a type system is to prevent shooting yourself in the foot and making sure you do not add an integer with a string.

Your variables, constants, functions arguments, and return type are all annotated with the type they use. You can still specify any as a type and ignore all type checking from Typescript. Some developers still use any to “move things and break fast” (pun intended) but doing so bypass all Typescript verification.

Rule: never use any unless you have to (and generally for backward compatibility). If you keep using any, just stick to Javascript and be ready for some fun debugging sessions when things will break in production.

Not checking for errors when loading API data

Many developers love to write code and test it manually in their local environments. Many developers think about the “happy case” and commit their code once they verified their code works on their laptop. But they often forget to verify that the code handles the error case.

There is an example of code I recently found in some production code. The objective of the code is to load data using GraphQL (spoiler alert: it’s buggy).

In this code, the useQuery function sends a GraphQL query and returns if the query is loading and the data of the query (if the results came back).

The problem with the above code is that it does not handle errors. If the request has an error or if the backend is not available, loading will be false, data will be undefined and the error is not being handled.

Instead, what should be done is to use the following code that detects if the request returns an error and handles it correctly (e.g. display an error message to the end user).

Rule: always handle the error case

Using class components

In the early days of React, a component was written using a class. However, it appeared quickly that using a class required writing a constructor and a lot of useless syntactic elements. A functional component takes just a few lines of code and is easier to test (you just pass arguments!).

Rule: prefer functional components over class components

Writing loooooooooooonnnnnnnng components

Even if it’s known for a long time, this rule is rarely enforced, especially when developers start coding. How many times you have seen files with 10 functions, each of them spanning over 200 lines of code?

The same rule applies to React components: it’s always a good idea to keep components small and be able to fit the code of your component on your screen. Components should be at most 100 lines and if not, it is always a good idea to refactor and code and divide the component into sub-components.

Rule: avoid components that take hundreds of lines of code. Keep your components short and sweet.

Using variables and not constants

Using variables makes it hard to trace when values are being modified. As the program becomes larger, it’s difficult to trace when the variable and if a change may introduce a regression (especially when there is no test).

For that reason, prefer immutable values. When you need to update a value, create a new const based on the previous value instead of mutating the original value.

For example, instead of writing the following code

Use the following one

Rule: use const and only use let or var when you really have to.