There's one more thing we're going to do inside of our custom listener right now instead of on message.
We are referencing properties on this data argument that we know do not exist.
So we want to somehow get typescript to complain to us and say name doesn't exist and cost does not
exist to do so we're gonna change the type of data right here away from any.
We're going to say that the type of data coming into on message is going to be equal to the type of
ticket created events data property.
Remember inside of ticket create event as an interface.
We said that this thing was going to have some data that was going to be an idea a title and a price.
What's more inside of base listener.
So here's based listener we said that whenever we made use of listener we were going to provide some
type argument to it.
And we said that the first argument to on message was going to be equal to that type.
Arguments data.
So in our case the type argument to listener is ticket created event.
So we are essentially saying that the first argument to data right here is that it is an object that's
going to have an idea a title in a price
so we need to update this type annotation right here from any to instead reference that data off of
the ticket created event interface.
Long story short we're going to place any with ticket created events at data like so this is not going
to enforce typescript or get typescript to enforce some type checking on the properties we try to access
on this data argument so we can no longer access these properties that don't actually exist like name
and cost but we can't access properties that do exist such as I.D. and you'll even notice I'm getting
that nice autocomplete now.
Title and price it's now tied to gripped is going to yell at us anytime we try to access properties
that don't exist which is exactly what we wanted.
Now you might look at this and say Steven is this actually doing any type checking.
How were we able to replace any with this and get everything working.
Well take a look at this.
Let me show you what our greatest fear is our greatest fear is that we might accidentally define some
interface such as fake data and say this is something that has a name that's a string and a cost that
is a number and we might accidentally think that this data argument is a type fake data.
So this would be an example where we make a typo or something like that.
We do too much copy pasting and we apply an incorrect annotation to data if we try to put that on.
We're then gonna get a big error specifically around on message.
So remember we are extending this listener base class typescript is going to look at the data portion
of this ticket created event interface and it's going to make sure that we receive the first argument
two on message as that data or the data portion of that interface.
And so if we try to apply any other type to that argument we're gonna end up with an error.
So I'd say that this is working as expected typescript is making sure that we always put it in the correct
type for this data argument.
So we must put in ticket created event data like so OK so that is pretty much it.
Now I know the changes we've made probably seem really confusing.
They might have seemed pointless but the whole point here is that now we have reduced the number of
times that we referred to plain strings inside of our listener.
And we also have something to make sure that we can only refer to the correct properties inside of this
incoming piece of data from Nat streaming server.
So this is going to dramatically reduce the possibility of us making Typos misspelling property names
or anything like that.
The other thing you might be kind of confused about is what portions of our code inside of here are
going to be written inside of our individual services versus say the common module.
Let's take a quick pause right here and start to address that question in the next video.