In this video, we're going to try to condense down our or marker method and add company marker into
one single method instead.
So we're going to first try one approach that is going to look like it's going to work out pretty well,
but it's going to have a distinct downside.
Well, then finally refactor into the final good approach that we're going to stick with for this application
and just about all the future applications we work on as well.
So to get started, I'm going to find ad company marker right here and I'm just going to comment out
the entire thing.
We're going to eventually delete this, but I want to just leave the code around for right now just
so we can refer back to it if we need to refer to any of the code inside their.
And I'm going to focus on add user marker instead to make this method a little bit more generic and
indicate that it will work for both the company and a user.
I'm going to change the name to be only add marker like so.
So here's approach number one to solving our problem.
I'm going to change the argument typewrite here to say that we can pass in an instance of a user or
a company.
Remember, that is what that little pipe operator means.
And again, that is the character right above the enter key on your keyboard.
You'll probably have to hit shift and then, like, backslash to get that thing.
Now, we might want to update the argument name as well really quickly, so I'm going to change the
argument name to something like matchable to indicate that this is something that can be mapped or like
placed on the map as a marker.
And maybe that argument name doesn't make a lot of sense, but I think it will work out for now.
OK, so let's talk about exactly what this or operator does right here.
We said previously we took a quick glance at this and we just said this means or matchable can be or
this argument can be either an instance of a user or a company.
But what does that really do?
It's a quick diagram back over here.
All right, so in this diagram, we've got an instance of a company in an instance of a user, and then
I listed out all the different properties that a company has and all the different properties that a
user has along with their respective types.
Anytime that we use an OR operator on an argument, here's what is happening behind the scenes on that
argument that we get access to inside of this method, TypeScript is going to do a little powering down
operation to limit the number of properties that we can actually reference on unmatchable.
So any time we use this or operator type script is going to take a look at the two different types and
it's going to say you can only refer to properties on that argument if they exist in both of these different
types.
So TypeScript is going to look at company, it's going to look at the property name, company name right
here, remember, that's one of the properties that company has.
TypeScript is then going to say, OK, does user have a company name?
Nope, it sure doesn't.
So we are not allowed to refer to company name off of this argument right here.
TypeScript is then going to look at catchphrase, does user have a catchphrase?
Nope.
OK, we are not allowed to refer to that.
And finally, it's going to go on to location and say, OK, does user have a location?
Yup, it does.
And is it its type a object that has allowed to monitor that are both numbers?
Yep, sure is.
OK, we are allowed to refer to location on that argument.
TypeScript is then going to take a look at the user type and iterate through all of these things properties
as well.
It's going to say, OK, does company have a name?
No, it doesn't.
OK, we are not allowed to refer to that property.
Does company have a location?
Yep, it does.
OK, we're allowed to refer to that.
So the result of this or operator right here is that TypeScript is going to limit the number of properties
that we can refer to on this m'appelle thing.
And you can actually see that in action very easily by writing out matchable.
OK, Map Knuble, sorry, I got one of those these MacBook pros that is like double typing characters
right now.
Anyways, if you rent right out makeable and then a dot will list out all the different properties that
you are safe to refer to.
And so you'll notice that the only property we can refer to here is location, because that's the only
commonality between user and company.
So that's why we are allowed to refer to matchable location, let down here and the same thing for the
longitude as well.
But if we had to refer to, say, a user's name or a company's company name, we would not be allowed
to.
All right, so this actually kind of works out pretty well for us, right, because the only thing we
really care about is a common property between user and company.
We only care about location and location longitude.
So this definitely does work out for us.
However, I would suggest that there is still a big downside to this approach.
This code works, but it's not perfect.
And here's why.
Let's start to think about what would happen at some point in time in the future.
Where's my diagram?
Here we go.
So let's think about what would happen in the future if we started to have other things that we want
to map on our map or show as a marker on the map.
Right now, we just have user and company.
But what if we also had something like.
I don't know.
Would be something else we want to show on a map, how about like how about like a customization of
a company, maybe like a car lot, a place that sells cars.
And so we would make a new class called car lot.
Maybe we also want to show something that's like maybe a park.
So maybe we have a new thing called Harcourts.
We've got to have a class called Park and so on.
For every one of these new things that we want to show on our map, we would have to add on an additional
import statement into sports.
So I'd have to import park, I would have to import carlot and so on.
And for every one of these additional things we might want to map, we're going to have to add in an
additional or case to our method.
So add markhor.
Matchable can be a user or a company or a park or a car lot or whatever else.
And I think you get the idea here.
So every time we want to expand this repertoire of things we can map, we're going to have to do a lot
of adding on here.
And if there's eventually, like 30 things we want to map, well, we would have a really huge method
signature.
So this is not really a great approach right now, number one, because it's not super scalable, and
number two, because it's introducing a very tight coupling between our map class and every other class
we have in our application that we want to show on the map.
So, like I said, this is an OK solution.
It is a solution, it would work, but I still don't think this is the best way of going.
So let's take one more quick pause.
We can come back to next video and finally go to the real solution for this problem.
So I'll see you in just a minute.