- So here we have the exact same code from the last video.
And the very first thing I wanna do
is I wanna figure out how can I take
this really long, complex inline type,
extract it out into its own type
which I can actually use all over the place.
For example, if I had a "person2" down here,
I wanna set them equal to some value.
I don't wanna have to copy and paste this type down
and then make sure I update all of these in the same place.
I just wanna use one type where everything is defined.
So in order to do that,
what we can do is we can come up
to the very top of our file.
Generally, at the top of the file is where I like
to define my types, or at the very least,
I like to define them right before they're going to be used.
And what you can do is you can define a type.
And to do that you just type in the word "type"
just like that.
It's just like you would define a constant variable.
We're instead defining a type.
This is something that only works in TypeScript
'cause JavaScript has no type property.
So if you type in the word "type,"
then we can type in the name of our type.
The important thing here to note
is that almost always when you're using TypeScript,
your types are going to be in camel case
where the first letter is capitalized.
This would be a person type.
If for example my type was called "person name,"
it would look like this
where it's camel cased with all capital letters.
The very first one's capitalized.
The second word's capitalized and so on.
This is kind of the opposite of JavaScript
where you leave the first lowercase.
But this is how I would write this in JavaScript.
But if I'm creating a type in TypeScript,
you almost always are gonna be using capital letters
for the very first letter of each word.
Then if you're using a type like this,
all I say is I want my type to equal some value,
just like you would do in JavaScript.
And here is where you put everything
that would come after your colon.
So I'm just gonna copy all of this.
I'm gonna paste it down right here.
And then instead of the actual full type here,
I can just write out what the name of my type variable is.
I've created this type variable "person."
I can define this person as that.
Same thing here.
I can define this as a person as well.
This is going to give me some errors
'cause I don't have a name or anything defined
for this person.
So let's give them a name of Sally and an age of 23.
There we go.
Now I give that a quick save.
You can see we have no errors anywhere.
When I hover over my person, you can see it explains
that this is what my type looks like,
which is the exact same type I had before,
and my person is now set to this person type.
And this is really cool because now I have the ability
to extract this type out.
So for example, if I wanted to add something to this,
for example, I wanted to add some friends,
and the friend is just going to be an array of strings.
So we'll say it's gonna be a string array just like that.
You can now see that I have an error on both of these
'cause both of them are missing that friend's property.
I could just come in here,
say that friend is going to be equal to an empty array.
And same thing here, friends is equal to an empty array.
And now that's going to work just fine.
Another really cool thing about using types
is I can actually use nested objects inside of here.
You can do that in line as well,
but it becomes a huge mess to deal with.
So for example, I could have an address property.
And in this address I could have a street
which is going to be a string.
And now what I can do is I can add in an address
and I can add in a street,
which we'll just say like, "Main st."
There we go.
We can just comment the second person out
so we don't have to worry about those errors.
This is something really important to understand
because almost every time
that you're creating an object type,
for example, this person object type,
you're gonna wanna do it as an actual type variable
instead of doing it inline
just because it makes your code a lot easier to read.
Because this is not too hard to understand.
But if I were to copy this down
and replace this person here like this,
this is much more difficult to understand what is going on,
and I can't reuse it anywhere else,
which is why, again, almost always if you're gonna be doing
a long, complex object type like this,
it makes sense to extract it into a type.
Now the really great thing about a type in TypeScript
is that you can use it with literally anything.
Like I said, all you do is you take
whatever's after the colon,
and you put that right after the equal sign.
So for example, I could say that this
is going to be a number.
Now, if I were to actually set this to a number
by just saying "3" here, for example,
you can see that my person type is set to a number,
so my person here is just a number,
and that's going to work fine.
If I change it to a string, obviously it's going to fail.
So types work by just replacing whatever is after the colon
with the actual type name
and then taking what used to be after that colon
and putting it after the equal sign for the type.
It's relatively straightforward to create.
Now let's go back to when we had an actual person object,
and we're gonna talk about interfaces next
because interfaces are nearly identical to types,
but there are a few minor differences
you need to understand.
So to change something to an interface,
instead of using type,
we're just gonna say "interface" here.
So we'll say "interface" like that.
And we actually remove the equal sign.
And the reason we do that
is because interfaces can only be used with objects.
It must be used with something
that is some type of object type.
In our case we have this object
that has a name and age and so on.
So that's how an interface works.
But the one downside to this
is there's no way for me to set this interface to a number
because it only works with objects.
Like, I can't just say "number" here,
and I can't say equal number.
None of those are gonna work.
It must be used with an object type.
The only difference when you create them
is that you use the word "interface" instead of "type,"
and you don't have an equal sign anymore
because you're not actually setting it to something.
You're just defining this interface in line like this.
Now other than that, when you actually use the two,
they work exactly the same.
So it doesn't matter if something's an interface or a type.
When you actually set it to a variable like this,
this person is set to this person type,
it doesn't matter because it's going to work
exactly the same.
You don't have to worry about the differences
between the two when you're using them.
But when you define them, there are some minor differences
like you see here that you need to know about.
And there's some other minor differences
we're gonna talk about later in this course
which aren't super important right now.
Now when it comes to which one to choose,
again, it's entirely personal preference,
but I generally lean more towards using a type
instead of an interface for two reasons.
One, I just like the keyword of "type" better,
and I like the way that you can extend types and so on,
which we'll cover later in this course,
a little bit better than interfaces.
But secondly, and probably most importantly,
is a type is much more flexible
because I don't have to just use objects.
I can set it to something like a number instead,
and that's, again, going to work just fine.
That's one reason that I like to use types
instead of interfaces.
But you can use whatever you prefer
because, again, they're both interchangeable,
and you can use them in all of the same places
except for the case where you want to set an interface
to a specific value like a number or string.
That doesn't work.