Our application is now future complete, but I want to mention one last thing around interfaces.
Just a second ago, we added in a new requirement to our interface, we said that in order to be considered
to be matchable, an object had to have a marker content method that returns a string.
When we added in that additional requirement right there, we saw Eyre's pop up inside of our index
doctor's file, specifically where we were passing in user and company to add marker.
I want to try adding in a new property to interface, matchable back inside a custom map and just see
Eyre's pop up again.
So inside of custom map, I'm going to say that anything that wants to be considered to be makeable
has to also have.
How about a color property that is a string like so.
Now, as soon as I add that in, I'll see my index file light up.
If I open that once again, I will see areas around user and company.
So the discussion I want to have here is around where we see error messages.
Remember, the entire goal of TypeScript is to help us find errors in our code.
And so part of that process is making sure that typescript can point us in the right direction and help
us find like the root source of an error.
So in this case, we added in a new requirement to an interface and we're seeing an error appear where
we actually try to pass in some value to this function.
Now, I'm going to suggest that maybe this is not the best place to see this error message.
Think about what we would have to do to fix this air.
At the end of the day, if we want to make this go away, we have to open up our definition for a user
like the user class and the company class and modify those classes in both those classes.
We would have to add in a new property of color to both them.
So because we'd have to open up those class definitions, sing the air here is not super useful, it
is useful to see an error, absolutely.
But it's not really pointing us to the exact location of where we should go to fix this problem.
So I want to tell you how we can add in a little bit more code to help TypeScript point us in the correct
direction.
Here's what we're going to do inside of custom map.
I'm going to add in an expert statement for the interface that we just added.
So we now have export interface makeable.
So this is going to make the interface, we can import this into other files and refer to this as a
separate type.
So now I'm going to go back over to user notes and at the top I'm going to import that interface, so
I'm going to import matchable.
Custom map.
And then inside of here, I'm going to add in right after my class definition, I'm going to say implements
matchable.
So what this does right here is it tells TypeScript we want to make sure that a instance of class user,
like a user that we create satisfies all the properties required by the m'appelle interface.
This sets up a very direct dependency between our user class and the custom map class or technically
the custom map file, I suppose.
So we've now declared our intention to typescript.
We are saying we want every user we create to satisfy that interface because we eventually want users
to be an argument to that ad marker function.
So by adding in implements makeable right here, we are telling TypeScript, help us, help us, make
sure the user is implemented correctly, help us make sure that user has all the properties specified
by matchable.
If we now hover over yuzu, you'll see that it says, OK, property color is missing on class user,
but it's required by that interface.
So now we have a additional error message inside of here that can help us pinpoint the source of the
error in our application.
Right now, we have something that says very specifically, hey, your class user is not implemented
correctly.
So we're still seeing an error message, just like we were saying before, inside of Index Dotty's.
But now the difference is that TypeScript is helping us point out the true source of the error.
It's helping us understand that if we want this error to go away, we have to update our user class
definition.
So as you might guess, we could fix this up by adding in a color property that is a string and I'll
initialize it as like, you know, red or something like that right there as well.
And as soon as I add that in, air goes away and the number of errors inside of index starts goes down
to one.
So, again, the entire idea behind this implements clause right here is we are telling TypeScript,
help us satisfy this interface.
We want to make sure that user can be considered to be acceptable.
And so TypeScript is going to do some additional checking of our class and make sure we have all the
correct properties.
You do not have to do this.
This is not required at all.
The reason we would decide to add in this implements clause right here to a class is so that if we fail
to properly implement an interface, typescript can point us to the true source of the error.
Our definition of the class, as opposed to when we try to pass a value or an instance of that class
into a given function.
So if we wanted to, we could go through the same process with the company as well inside of company
Dotty's, we could add in an import statement for matchable.
From custom map.
And then I'll say implements.
M'appelle.
And now, once again, we get an air on company and it tells us we have to have color that is a string,
but we did not provide it.
So if we add in color, that is a string and I'll just say red like so right there on the same line
here goes away and we're back to be in perfect.
All right, so again, 100 percent optional, totally up to you, you will see some projects that use
this implements clause extensively to make sure that it's really clear to TypeScript and even other
engineers that we are trying to make sure that class company satisfies that interface.
If you don't put it in, no problem.
The only thing it's going to do is help typescript help you and help under the other engineers.
Understand what you are trying to do.
OK, so quick pause right here and we'll wrap up this application for real this time in the next video.