DEV Community

Cover image for The company of any in Typescript
Agustin Vazquez
Agustin Vazquez

Posted on

The company of any in Typescript

I'm sure that you sometime have listen "oh, you don't have to use any type, it's a bad practice" and it's ok, in the better case you don't have to use it.

But the problem with this phrase it's when the people that be starting with typescript listen it says "hmm ok, so i have to stop using any because it's bad and if i'm use it i'm bad" and dont be true!

So, i dont expect that you use any instead of types, you must keep googling types and trying, but in some moments it's ok use any.

Type inference

A little concept that you must know it's the type inference that have typescript. That means if it's possible Typescript take the type of variables from their declaration and it cant be changed.
For example:

let foo = 'bar'
Enter fullscreen mode Exit fullscreen mode

It's look like javascript, but if we are using typescript it assume that the type of foo it's string, and then you can't assign a non-string value.

So good, thanks typescript <3 but the problem come when typescript cant assume the value of some declaration, like function params.

noImplicitAny rule

Probably if you tested Typescript you faced some error like Parameter 'yourParam' implicitly has an 'any' type.

That occurs because generally by default in our tsconfig.json we have the compilerOption noImplicitAny and that say when typescript cannot infer a type, and you don't declare it, typescript throw this error.

That it's like a friendly reminder that you're using Typescript and dont Javascript, like "hey! i'm Typescript if you dont put a type for that i assume it's any, but you have to made explicitly".

And in this moment devs that starting with typescript says "i can't use any, because it's bad, i have to google it and find the correct type" and it's nice! it's the only way to learn about typescript, practice.

When any and what say to us

The problem comes when you have to type some complex things, like make a interface for Props, or typing a callback function, or typing a interface that have on prop that be a callback function(?).
And you're recently starting with typescript and it's like:

Me: omg typescript is asking me for a type, but i don't know
Typescript: hey, use any ๐Ÿ˜ˆ
Me: any = bad, i can't

If you not dominate typescript basic types yet can be stressful treat to type all. I think that the progress to learn typescript must be progressive, and here comes any type.

It's ok using any to type something that you dont know what exactly type you have to use here, and it's part of a learning proccess in which you learn where to put types. You'll be conscious that when you put any you're saying "it's is of some type, but i'm not sure which".

The company of any

I think in any as a company, i use it to my favor, and i think two situations:

When we are starting with typescript

Like said up, typescript path it's a progressive path, you not have to know all of typescript when you're starting. Go step by step.

If something takes a lot of time and stress to know how type it's needed here use any and then, after some time, you can go back here and try again with more knowledges.

For example:
if you're starting with primitive types and front of and object that have more properties inside it can be complex to type. But if you use any, after a time, when you know all primitive types can be more easily to understand interface concept, and you can create one and use it to replace the any.

When we are learning something new

One point that you have to know it's that the popular libraries have support to typescript and export their types. From popular frameworks like React to a lot of npm packages.

And when you want to combinate a library with typescript you're not using library ๐Ÿค typescript, you're using library with typescript. That's means that you're using the typescript plus, the power of that library AND the types that the library exports to you.

Explained: In some places typescript ask you a type, and maybe you dont know, because it's something for the library and if you're recently going into this library maybe it be difficult to know the type, ant here you can use any. I'm sure that when you dominate the library must be more easily to know this library-types.

React exports a type called ReactNode and you can use it for type a prop that be rendered as a children to a component.

Supose that we can make a Button Component, that receive any children, a text, an icon, or some component to render inside. This Button in Javascript looks like:

function Button({children, ...restOfProps}){
  return (
    <button {...restOfProps}>{children}</button>
Enter fullscreen mode Exit fullscreen mode

But in Typescript we have to type the props, and here we focus on children, ignore restOfProps. And you can start by creating and interface for the props, typing the restOfProps with primitive types, but in a moment you have to assign a type for the children prop and feced with that:

interface Props {
  // ...restOfProps types
  children: ?
Enter fullscreen mode Exit fullscreen mode

And for this particular case the response it's use React.ReactNode but this this pass in many situations and if you face with a similar situation you can use any and then go back and investigate what type goes here.


You not let any types in you app, in the better case you have to use typescript advantages and type the most that you cant. But any it's like a // TODO:, when i have the type most clear, or have most time i go back and add a type.

My personal rule about it's to if I know the type i put here to not let a lot of types to the end, but if I mading something that i down know the type or it's are abstract and not sure about what params are needed I put any and continue the important part: solve the logic problem. And then, after you're ended the part of code you must have clear what types you need here, and be more easily add types.

Too, any it's like a compromise, you can use it, but you be concious about then you will come back later to remove it. It's a resource for making TypeScript learning / development more flexible.

Extra links:

Type inference
compilerOptions: noImplicitAny

Thanks for reading, it's my first article in english so feel free to make me corrections about it, or let your opinion about any. This it's just my opinion ๐Ÿค“

Top comments (0)