Avoiding Costly Mistakes: Unraveling the 'unknown' Type in TypeScript

I want to shed light on an essential TypeScript feature: the 'unknown' type. Drawing from my own experience, I'll share a mistake I made in the past that resulted in countless hours of frustration. By understanding and utilizing the 'unknown' type effectively, you can avoid repeating the same error and save valuable development time.

Have you encountered situations where you needed to handle values of unknown types?

Consider the following code snippet:

declare const foo: Foo;
let barAny = foo as any as Bar;        

To improve the code and reduce potential risks, I recommend the following:

let barUnk = foo as unknown as Bar;        

Both forms achieve the same result, but opting for the unknown type reduces the risk associated with potential code refactoring.

Let me give you an example why the first approach is problematic

If your teammate accidentally removes the Bar type from the code snippet during refactoring, the resulting code would look like this:

If your teammate accidentally removes the Bar type from the code snippet during refactoring, the resulting code would look like this:

let barAny = foo as any;        

At first glance, everything might seem fine because the code will continue to work without any errors. However, this situation is not desirable. In the future, if you intend to update or modify the Bar type, the code snippet using any will not raise any alarms, as any essentially bypasses type checking.

On the other hand, if your teammate mistakenly removes Bar from the code and you have it defined as unknown instead:

let barAny = foo as unknown;        

TypeScript will immediately detect the error, highlighting the need for a type assertion. By using unknown, TypeScript ensures that you explicitly acknowledge the uncertainty of the type and reminds you to perform appropriate type checking or assertions before using the value.

Summary

In summary, utilizing unknown instead of any in such cases provides an added layer of safety and helps catch potential errors during development. It encourages you and your team to actively handle type assertions and maintain type safety throughout your codebase.