- Now in this course so far
we've talked a little bit about
when TypeScript just assumes a variable
can be any type at all.
For example, if I define the variable A,
and I don't give it a default value
and I don't give it any type information,
it just assumes that A can be anything.
So I could set it to a number here,
I could set it to a string,
it's going to work just fine
'cause TypeScript says, "I don't know what this is.
It could be literally anything."
And TypeScript actually has a specific type for that
and that is called the any type.
As you can see inside of here,
if I hover over this,
this is inferred as the type any.
And I could manually type this as any as well
by writing out any like this.
And that's going to mark this as an any variable.
So even if I give it a value of four, for example,
it still says that this can be anything.
So it doesn't matter what I assign it to,
whether it's an object, an array,
a number, a string, it doesn't matter,
TypeScript says this could be anything.
Now the great thing about this
is it means you can just write your code
like normal JavaScript,
'cause JavaScript, every variable is any type by default.
But obviously the downside is you lose
pretty much all of the benefits
of TypeScript when you use any.
For example, I no longer have any auto complete
because it doesn't know what this is.
It doesn't know is it a string, is it a number,
is it a Boolean, is it an array
is it an object, is it a date?
It has no idea.
So you can't get any auto complete
and you really don't get any error protection as well
because again, TypeScript doesn't know what this is.
so it can't prevent errors,
'cause it doesn't know what it's trying to prevent.
So really any is a bad idea.
And most often when you're writing out code
if you're writing any like this,
that's generally a code smell
and something that you should not do in your code.
You almost always want to remove anys
anywhere that they show up inside of your code.
Now for the most part,
you probably won't run into problems
with any showing up in your code,
unless you obviously manually add them yourselves
or you're creating a variable
without actually giving it a value
or you give it a default value
of like null or undefined,
which in that case
it's always going to be a default value type of any here.
But the other scenarios where you may run
into any that you need to be aware of,
is if you use json.parse,
you pass at some string.
The actual return of json.parse is going to be any,
for example if I say const A is equal to that
and I hover over this,
you can see it has a type of any.
And that's just because TypeScript
doesn't know what the object
or value being returned from json.parse is.
It could literally be anything at all.
So it just needs to be able to account
for all of those different things.
Same thing if you make a fetch request,
if I make a fetch request to some URL
and then I want to get my data back,
so I say res.json,
now I have my data here that I can use.
So we'll get data,
oops, make sure I clean up my code a little bit.
There we go.
And if I go over this data,
you can see that this is again a type of any,
because it doesn't know what the data
being returned from your API is.
It could be JSON,
it could be something entirely different.
It has no idea.
It could be unknown, undefined,
doesn't know, so it just defaults the type two any.
So that's something that's really important
to make sure you understand
because you may be using fetch inside your code base.
You may have this data variable that you start
accessing different properties on.
And before you know it you realize
that you're not getting
the error protection that you need,
'cause this is inferred as a type of any,
which pretty much when you use any,
it just shuts down TypeScript
for anything that uses that variable
or piece of code that you've typed as any
because it just doesn't know what to do.
Overall, my advice is to never use any,
unless you're in the process of maybe converting
a JavaScript project over to a TypeScript project,
which I'll cover much later in this course.
But pretty much
if you're writing TypeScript code from scratch,
there's almost no use case
that you would want to use any in
because it just essentially shuts down using TypeScript
and gets rid of all the benefits of using TypeScript.