Probably one of the most debated types in Typescript is the any type. Some abuse it, some tell you to use it as little as possible. How does this work?
Imagine that we need to specify the type of a variable but we don't know exactly what that variable will hold when writing our code. These values may be dynamic (they might come from a 3rd party library, for example). In this case, the best approach would be not to check the type of the variable (half true, since we'are actually using a type to specify that we expect whatever and we're fine with it). We can do so by using the any type and let the variables to be dealt with at compile time. The any type doesn't look any different from the others and we write it like this:
This is also very useful when we work with arrays and we don't know the types of all its elements. To avoid issues we can do something like this:
Notice that in the first example, I specified I want an array of type number so when trying to push a string to it, I got an error. The second example passes successfully.
Image source: Christina Morillo/ @divinetechygirl on Pexels
Top comments (8)
More often than not, the
anytype is used to denote some form of an object dictionary. For third-party libraries, this may be the configuration object and whatnot.In those cases, I strongly advocate for the use of the Record<K, V> utility type. It's basically a wrapper over objects with index signatures, but it provides a greater level of type safety than a mere
anytype.I can, for example, define a dictionary of string key-value pairs as
Record<string, string>, which is definitely safer thanany. For an extra level of protection, one can also useRecord<string, string|undefined>instead in order to enforce null checks.The
anytype should always be a last resort. Ideally, it shouldn't even be an option. In practice? Maybe not so.If all else fails:
anyI think
anyis a lot like the default JavaScript type. Can be anything, and become anything. I love TypeScript as much as anyone. But I'll say, to eliminate some of its complaining and still get more of what I want than what it wants, I have to decorate withany. Viva la any.I understand what you mean. There are, of course, situations when you know better what you want to do with the code. I personally prefer not to use it at all when I do not know a type, since it defeats the purpose of Typescript. At work I am using it together with Eslint so I can't really put it in my code at all :).
Exactly. I think almost anything is better than
any.In the example above we could go from
number[]to(number | string)[], instead of resorting toany[]. Or generics, depending on the case.I think it is worth mentioning that where possible, use of
anyshould be avoided. Typescript 3.0 introduced more safe replacement ofanycalledunknown:unknown is the type-safe counterpart of any. 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.docs about it
True. This is the subject of my next actually :). Thx for mentioning it.
Sometimes I have to use 3rd party libraries with no definition files. For that I use any, it works well but there's no intellisense.