Now we're almost done,
but there is one last feature
which you must know as a developer when working
with async code and Promises, and that's important.
This concept now only applies to Promises.
Promises already allow us
to write code a little bit more structured
than having multiple callback functions
that potentially might be nested into each other.
Still, we have to write these extra Then methods.
And now let's assume we have a function.
Like this readFile function here
that performs only one long taking asynchronous operation,
or maybe multiple operations stats depend on each other,
but not multiple operations that should be started
at the same point of time.
If that's the case, if we only have one operation,
or if we have dependent operations,
then we still might have some async code
because maybe the package,
we're using at the operation we're performing,
doesn't give us async version of the method
as readFile did before.
There we always had readFileSync as an alternative,
but that's pretty much an exception.
Most packages don't give us such a sync alternative
when doing some async work,
and therefore we might be stuck with using a promise
or a callback function.
Even though we might know that the code,
after reading the file,
should only execute once that's done.
So we don't want to execute it earlier.
Well, of course we can then move that code here
into this Then block,
but still we have to write all that extra Then logic,
and we have to deal with those callback functions.
In scenarios like this, you can simplify your code
with a feature called 'async await'.
Now, what is that?
With that feature, you can turn a function
into a so-called async function
by adding the async keyword in front of it.
Once you do that,
this function will automatically return a promise
without you explicitly returning one.
I have no return statement in this function
and yet at readFile,
this function will return a promise now
because of async.
Now the async keyword, however, unlocks one other key word,
which we can now use inside of that async function.
And that's the await keyword.
We can add that keyword in front of any method
that returns a promise.
Like readFile does here now.
When we do that, when we do add a weight
we can get rid of Then,
and instead store that result in fileData.
Whoops,
in that fileData variable, either find here.
Just as I did it before.
Even though that's not readFile sync,
but readFile which returns a promise.
But under the hood, when using async await,
JavaScript will add Then to that promise for you,
and it will provide the value
which you would otherwise get here as a parameter value
in this function that's passed to Then,
to this variable or constant here.
So JavaScript will give you that value
as a return value here
just as if this would be asynchronous operation,
even though it isn't.
But it's transformed under the hood,
behind the scene so to say.
Therefore,
you can then get rid of Then here,
and just execute your other code
in the very next lines thereafter,
and code execution will stop until this line here.
Line 15 is done
before it advances to the next lines.
And let me get rid of this part here now.
Now it is might sound like a step back
after all we started using async code
so that we can execute multiple operations
at the same time.
But as I mentioned before,
if you don't have that use case
and still you are using some operation
that forces you to use a promise,
then you can simplify your code again
with async await like that.
Now it looks like synchronous code,
but under the hood,
that's important,
it is still translated to this Then version of the code.
So to that version you saw a couple of minutes ago.
But to us as a developer,
this code is now easier to read and write,
and it looks like synchronous code to us,
even though under the hood, it's still asynchronous.
This code here in the end is just put into a Then block
into a when method called and the anonymous function
that's passed to then automatically by Java script.
That's how you can think about that.
And if you now want to handle errors again,
since this now again looks like synchronous code.
You can again use Try Catch as before
that did not work on the asynchronous code before
with Callbacks or Promises.
But when you start using Async Await,
then Try Catch is available again.
So that's how you can then handle
that error you might be getting.
As a side note if you want to get access
to the error object,
that's produced automatically by a readFile
in case things go wrong.
You can add a parameter.
So to say, after a Catch and that will then be available
in this Catch block.
And that will be that error object that is produced
by a readFile.
That would have been available here before as well
When we used readFileSync,
and it's now available again when using async await.
And that's now the last concept related to async code.
It allows us to go back to a style
that looks like synchronous code,
even though we're still having some async operation.
And async await can be very useful
if you want to have that more simplified code,
And you're fine with not starting multiple async operations
at the same time,
because that won't be possible
because,
as mentioned,
Await, now in the end blocks code execution, again,
until this is done.
But if you don't need to start multiple operations
at the same time, then this is a simplification
that can be useful.