Using any as a type
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
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
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
const and only use
var when you really have to.