1. Using the "any" type excessively and Not avoiding implicit "any" scenarios:

   When we do not know what to use, we use the any type, which is an extremely common mistake. When we do that, we are explicitly asking the typescript compiler to turn off the type checking, which removes the fundamental reason for using TS in any project.

   

   Or when we do not explicitly type our variables properly, Typescript implicitly gives them the any type.

   

   In both cases, we are eliminating the primary advantage of using TypeScript. An alternate solution is to use the unknown type. It is a type-safe alternative of any where we are telling the typescript compiler that I don't know the type of the variable currently but I will know when I try to use this variable anywhere in my code. In simpler words, we are not asking the Typescript compiler to silence itself, rather the compiler doesn't allow operations to be performed on a unknown type unless we narrow it down to a more specific type using some conditions. This allows us to safely type our variables even when we do not know their types in the present moment.

2. Not using the strictNullChecks compiler option:

   There are times when we unconsciously try to access variables that might be null or undefined. Enabling the strictNullChecks compiler saves us from falling into this pitfall. Enabling this ensures that variables are not given null or undefined unless explicitly told (using a union type).

   Here's an example that shows myCircleArea is used without it being defined and TS compiles this without any errors.

   

   However, if I enable the strictNullChecks or simply the strict flag in compiler options under my tsconfig.json file, the same code will throw me a compile error:

   

3. Overcomplicating the types instead of using discriminating unions:

   To understand this, let's consider the following example, where UserState is trying to represent three different states that the data can be in Loading, Success, or Error.

   a) If we are in the Loading state, there can be no error messages as well as no user information.

   b) If we are in the Success state, there can be no error messages.

   c) If we are in the Error state, there can be no user information.

   Currently, the following code suggests that we can be in the Loading state, but we can also have the user information and errors at the same time. Or we could be in the Success state but we can not have the user information, etc. Because of this, the TS compiler yells at me saying 'user.error' is possibly 'undefined' or 'user.information' is possibly 'undefined' because we have made those properties "optional" on the UserState.

   

   To solve this problem, a better practice is to switch to discriminating unions by extracting one type into multiple types by recognizing the states your variable can be in. In our case, if we have three different states that it can be in, it's a good practice to create three different individual types for each one of them. Here's how we can do it:

   

   Each type Loading, Success, and Error contains only the properties they require without making them optional on the object, and each type contains a common key called state which contains different values that the user can be in. When we have one key (in our case state) that contains different values between multiple types (in our case Loading, Success, and Error), and you union them together (in our case UserState), then this is considered as a discriminating union in Typescript. Discriminating unions not only allows us to ensure type safety but also enhances auto-completion (in code editors) and code readability.

4. Not knowing how to type an object properly:

   Another common mistake is not knowing how to type an Object properly. When you know the expected shape of an object, and instead of making it strictly typed, you type it as an Object, then the problem begins:
   Here is an example:

   

   I was able to pass the myDate and myFunction as arguments to the returnObject function even though I typed myObj as an "Object". This is because dates and functions are treated as objects in JavaScript so TS didn't throw errors and allowed me to pass any object I want. To avoid this, one should use the Record type or an indexed type.

   Here's a demonstration:

   

   Now I'm telling it to only allow an Object that has a key with string type with an unknown value. So TypeScript recognizes the type and starts yelling at me for passing the date and function arguments.

   

   Another way to achieve the same thing is to use {[index: string]: unknown} which is also telling the same thing to the compiler i.e., any object having a key with a type string and an unknown value will work perfectly fine for myObj.

Hopefully reading this will equip you with the knowledge to steer clear of those common Typescript pitfalls I mentioned in this article. However, this isn't it, Typescript is a big world, and there's more to uncover! Might publish a Part 2 of the same topic if I manage to resist the urge to procrastinate :P Until then, happy coding!