Cover image for Typescript - why to use "unknown" instead of "any"

Typescript - why to use "unknown" instead of "any"

cilvako profile image Silvia Bogdan ・2 min read

As I was saying in my last post, I am trying to avoid using the any type as much as possible. Although I understand the need for skipping type checks, I think using any defeats the whole purpose of Typescript. Luckily, at work I am also using Eslint so unless I disable some specific rules, I can't integrate any in my code.

If you really need to skip type checking, you can use something that Typescript 3.0 introduced: the unknown type. Unlike any, unknown is safer to use in the sense that before actually doing something with data of this type, we must do some sort of checking, whereas any has no restrictions.

Anything is assignable to unknown, but unknown isn't assignable to anything but itself and any without a type assertion or a control flow based narrowing. Likewise, no operations are permitted on an unknown without first asserting or narrowing to a more specific type.

What does that really mean? Let's take the examples bellow:

Alt Text

We see we can assign anything to a variable of type unknown (I used just a few types to point this out). Now let's see what happens when we try to reassign unknown to something that's not any or unknown:

Alt Text

Notice the following: we can assign whatever we want to variables of types any and unknown. We can only reassign the any type variable to whatever we want (in this case, a variable of type number). Trying to reassign unknown to a variable of type string or number will throw an error (as mentioned, it can only be reassigned to any or unknown).

On their own, variables of type unknown are not very useful but when performing extra checks, they can be quite powerful. I am going to use an example in comparison with the any type:

Alt Text

Looking at the code above, we have two variables, one of type any, one of type unknown. When trying to run the .map() method on variable_of_any_type, the editor doesn't complain, although it doesn't know if the variable is indeed of type array (and as we can see, it's not). We won't spot this until after compiling time when we'll get an error saying Uncaught TypeError: variable_of_any_type.map is not a function.

When trying to do the same thing with the variable of type unknown, the editor complains and says Object is of type 'unknown'.. This means that it still doesn't know if it's an array so we must make an extra check. We do that on the next lines, we see that variable_of_unknown_type is indeed an array, therefore we can perform the .map() function on it.

Image source: ThisisEngineering RAEng/ @thisisengineering on Unsplash

Posted on Jun 2 by:

cilvako profile

Silvia Bogdan


Front-end developer by day, front-end developer by night. My dog is my biggest supporter.


markdown guide

unknown is just pessimistic 'any' 🙈. With any , ts is like "maybe it is of type array, who knows?", and with unknown it is like "dude, I am not taking any risks 😇".


Hehe, nice analogy :).


Nice. Did not know that feature!


So it was unknown for you???

ok I'll leave myself


For situations where defining the type is not possible, I'd like to use the lazy gradual typing. Meaning, I have a global type alias TODO that's the same as any.

declare type TODO = any;

While it's just a "hack", I do like it and it does come in handy from time to time. Some details.

However, the unknown solution you proposed seems much better overall.


Never thought about it, nice :D. Does it do anything else besides tricking the compiler?


I've ran across unknown when interacting with some libs but never understood what it meant in comparison to any. Now I know thanks!


I've rarely seen it in the wild too, I know what you mean. Glad that it helped :).


Thanks for the lesson. Your examples made this easy to understand, and I'm now motivated to use unknown the next time I start to reach for any! 🚸


Yes, why not? We indeed need to make some extra checks but since it's safer I believe it's worth it. Thank you for your input!