I know he spent a lot of time talking about annotations and inference, but we've got just one last
little sub topic to discuss, which is objects.
Now, this discussion is going to go a lot more quickly because all we're really discussing here is
how we do stuff like objects structuring, which we kind of saw an example of in argument list just
a second ago.
So let's just flip directly back over to our code editor and talk about how to work with objects around
this annotation stuff.
So instead, my annotations directory, I'm going to make another file called Objects Dots.
And then inside of here, I want to declare a new object called profile.
And this will be a profile for a person.
So maybe they have a name like Alex.
Maybe they have an age like twenty.
And we'll say that this person also has some coordinates like their physical location in the world,
so I'm going to abbreviate that as simply chords.
And then I'll give them a latitude and longitude property inside there.
So we've got a nested object right here.
We've got the latitude and longitude representing this person's physical location in the world.
Now, last thing I want to add to this object is a method, a method that will change the age of this
person.
So obviously we could do something like profile.
That age equals 20, but let's make a separate function just to have a nice function to call.
All right, so one more property will add in here is set age, and rather than defining this as like
a function like so I want to try using the E 2015 syntax for defining a method inside emergent object.
So instead I'll say stage, I'll put my argument list in and then the function body.
So let's try adding in some annotation for this function right here, using the same rules that we just
learned.
So I'm going to put in a age as an argument and then the type of this argument, which will be a number.
If we're just updating this person's age, I don't really expect to return anything from this function,
so I'm going to annotate the return type as being void like so.
So then we can ride out our implementation inside the function, we can say the stage is H.
All right, so that's an example of a function being defined inside of an object with the function annotation
on it.
So let's now try doing a little bit of 2015 de structuring and pulling some different properties out
of this profile object.
So, for example, let's try structuring out the age property right here and figure out what the exact
syntax for that would be.
So, of course, we could do something like consed age is profile that age, like I said, we want to
use these structuring instead.
So instead, I'm going to write out just profile.
And we can do normal structuring like so.
Now, if we really wanted to put a type annotation on here for some reason, like maybe we fall into
one of those three categories that we discussed earlier right here, if we really wanted to put on some
annotation directly onto the variable right here, we could do so by writing out a colon and then the
structure of the profile object.
So we would not just say, oh, this thing is going to have like age.
That is a number.
Instead, we have to list out the structure of profile and the different properties that we want it
to have.
So in this case, we would put down curly braces age and no like so.
So notice how this seems to kind of like violate the rules of annotations, previously when we were
talking about variable annotations, we had said, oh yeah, we just put the type of the variable or
the type of value that we're going to assign to this variable.
So we're creating a variable right here called H.
And so you might think that we only have to label it with the type that age is going to refer to, which
would be, no, that's not the case.
If we want to use D structuring, we have to write out the expected structure of profile over here on
the right hand side.
So I expect this value right here to have a structure that is an object with an H property that is a
No.
It's now to make things just a little bit more complicated.
Let's try also structuring out our latitude and longitude as well.
So this is going to be some nasty stuff, but it'll be some pretty good practice.
So we would write out one set of curly braces.
We would say, look at the courts property.
And then tried to pull out latitude and longitude out of there, and we want to get all that from the
profile object like so.
OK, so we were just doing plain destruction with an out in annotation, that is what it would look
like to be just identical to the normal E 2015 Syntex.
But once again, if we fell into one of these conditions where we had to put in an annotation, all
we would have to do is once again kind of mirror the object structure that we expect profile to be.
So it's going to be a little bit nasty here.
Right after the destruction we can put in a colon, then we'll start to describe the structure of the
profile object.
So I'll put a set of curly braces.
I'm going to say that this thing is going to have a prop. cords.
That's going to be an object.
And inside of that inner object, we've got a flat property that is a No.
And an LNG property that is a number as well as the really long line, so I'm going to save the file
really quickly just to get it to reformat so you can see the whole line in total.
So once again, kind of unexpectedly, we do not just list out the expected type of LAT and long, and
I think this example right here will give you a better idea of why that is.
If we consider backup here, if we had only put no well, what would happen if we wanted to structure
multiple properties and also pull out, say, this person's name as well, which was the string, if
this was the case, is no referring to the type of age or name.
So this is why we have to kind of double up on the structure whenever we are doing the restructuring.
So age is a number and name would be a string.
We have to label the type of all the different properties coming out of that object.
On this case, you'll notice I've got a little air here around name that's really fine, it's just because
the way my project is structured, chances are you see an air here as well that says something like
name was also declared.
If you see that totally fine, you can't ignore it.
All right, so that's around objects, like I said, I just wanted to very quickly talk about structuring
around objects and what annotations for them look like and also how we talk in function declarations
inside are there as well with some annotations.
OK, so that's pretty much it on type annotations and type inference, so we've gone over several plain
definitions, went over some examples.
We spoke about why we care about these remembers because we want to make sure TypeScript is aware the
type of all the variables we work with.
And we also discussed when we were going to use annotations and when we're going to fall back to inference.
Whenever working with functions, we're going to rely upon annotations 100 percent of the time for both
arguments and return types.
When we're working with variables, we're going to rely upon type inference as much as we possibly can
unless we are relying upon or in one of these three scenarios right here.
All right, so now that we've got through a lot of this kind of boring stuff, let's take a quick pause
right here and continue on our next subject in the next video.