Let's step away from function overloads now and let me introduce one our very neat feature and that
is optional chaining.
Let's say you have an application where you're getting data from a back end and data from a database
or from any source where you don't know with certainty if in an object a certain property is defined.
Let's say we have fetched user data and fetched user data.
Could be an object about a user we fetched there we might have an I.D. we might have a name Max and
we also might expect no property job which is an object which has a title and which then also has a
description.
My own company.
Now if we get data like this of course you can work with it.
Now you might do more complex things but here for a start let's say all I'm doing is I'm actually outputting
the job title here right now if we save Dad with our development server up and running and compilation
running in watch mode I get SEO here.
Now thus far that's not too fancy.
However if we are fetching this from a backend for whatever reason maybe we don't fetch all the data
we need maybe some data is not set at this point in bigger more complex applications use certainly sometimes
work with structured with nested data where you don't know with certainty if some property on an object
is set or if it's maybe on the find.
So here let's say job does not exist here for whatever reason we're not fetching it here of course I
get an error in out hire some complains about this because it knows that there is no job property now.
The problem is it knows for this data it wouldn't know if dead were data we're fetching from some file
that's not controlled from typescript or as I just said if we're maybe fetching this from the back end
and we don't know with certainty which data will be returned.
Now if you wouldn't know whether that's the find or not what we can do in regular javascript is we can
try to access job and if that works we continue and we access title.
This is the javascript way of checking whether something exists before we then dive deeper into debt
potential object and if Dad is on the find this code never runs and hence we have wider runtime error.
Again here types could of course knows that job does not exist but if this would be fetch from some
source for typescript can't look into like the result of a HBP request this would be the secure way
of a widening runtime errors in JavaScript.
Now if this does exist you get the same output as before.
If it does not exist we don't get a runtime error at least with typescript.
You actually got a nicer way of doing that.
You got the optional chaining operator.
You can add a question mark after the thing you're not sure whether it's to find or not.
At least if you're using typescript where you free dots seven or higher here my idea it doesn't like
this but this is a supported syntax.
Then this tells typescript does this exist.
If it does access job and ends here we can all get a question mark and therefore only access title if
job is defined.
Now if we do that I still get an error here if I tried to compile it because typescript still knows
with certainty that job does not exist but if it wouldn't need notepad or if I comment does and this
compiles just fine and all the executes ask before so does optional chaining operator here helps us
safely access nested properties and nested objects in our object data.
And if the thing in front of the question mark is undefined it will not access the thing they're after
and therefore will not flow a runtime error but instead it will just not continue.
So behind the scenes does is basically compile to if check which checks whether Dad exists before it
tries to access this.