Now, you'll see here that I copied the source code from the previous episode, episode 9, where we built a countdown component. I'd like to talk a bit more about asynchronous functions. So let's take a look at our test here. Now, you'll see in some cases, we set up this assertOnNextTick helper function, because we realized in some situations, before we could perform an assertion, like I expect to see 9 seconds on the page, so to speak, we actually had to wait for Vue to perform its next tick. So to bulk update or repaint the DOM. So we have an asynchronous act there.

So to bulk update or repaint the DOM. So we have an asynchronous act there. And then also we realized, well, if we have any code within the callback to nextTick, Vue is actually going to snatch that up. So it will intercept the exception and screw everything up for Mocha, because Mocha then never has the chance to catch it on its own. And we talked about all of this in the last episode, so definitely give that a watch if you haven't. So here's what we did. We added this little helper function, and we said,

So here's what we did. We added this little helper function, and we said, all right, for our VM, for our Vue instance, basically, on your nextTick, I'm going to run my own try catch here, so that if there is an exception with my, excuse me, with my assertion, then I'm going to be the very first one to catch it. I don't want it to bubble up to Vue's nextTick function. I'm going to be responsible for that. And that way, I can manually call Mocha's done function and pass through the error. Otherwise, we can just resolve like normal.

And that way, I can manually call Mocha's done function and pass through the error. Otherwise, we can just resolve like normal. Okay, so this is great. However, there's another option we could consider as well, and Joseph pointed that out to me. So great lesson, instead of passing done around, Mocha lets you return a promise. So this allows us to use the new async await functionality. And you'll notice, if we take this approach, we're no longer bound to that awkward thing where Vue's nextTick function is swallowing up any exception or error that might be thrown.

we're no longer bound to that awkward thing where Vue's nextTick function is swallowing up any exception or error that might be thrown. So let's see what that might look like, and then we'll dig in a bit further, because it's very possible that these two keywords, async and await, are new to you. So don't worry, we'll talk about that in a minute. Okay, so let's scroll up and let's just choose any one here. Let's work on this one for the time being. It reduces the countdown every second. Okay, so if I run npm test, and let's bring this down, hide the sidebar, it's passing at the moment.

Okay, so if I run npm test, and let's bring this down, hide the sidebar, it's passing at the moment. However, if we were to get rid of that assert on nextTick, well, of course, it's not going to pass, right? Because it hasn't performed the nextTick. It hasn't bulk updated the DOM, so everything fails. It still says 10 instead of 9. Okay, so what we're going to do now is get rid of done entirely, and we're going to declare this as an asynchronous function. Then, if we want to say, if we go back down here,

We could go to all of these. We'll do one or two more together. So this will be in a sync function. And then, we'll say, await wrapper.vm.nextTick. Or, by the way, you can await Vue.nextTick if you have imported Vue. Both will work just fine. OK, but anyways, we could do this, run our test, and we still get green. OK, so now, what I'm going to do behind the scenes, because you don't want to watch this, I will get rid of this entirely.

Everything's passing. And once again, if we scan this page, you'll see that we're using async and await in each location. Excellent. But now, I bet you're still potentially confused about this async await. If this is new terminology to you, let's take a look together. Let's take a look together. So I'm going to look for mocha async. OK, so we'll see here, this is the way I originally learned how to test asynchronous code. So we accept our done function, and then if we perform an asynchronous act,

We then await for the asynchronous operation to complete, and then we perform our assertion. But again, still maybe a little confusing. What does this keyword actually do? We'll take a look. Let's go to the console. So let's imagine that we have a silly little function like say, that will accept a message, and then we will return the message. That's it. So of course, we can do say('hello').

And if we run it, we now see hello. So because this returned a Promise, we can then call .then and .catch. And the way it works is when you have an async function, let's clear the screen and draw that up one more time. Okay, so what you return from this function here will be passed when the promise resolves, and it will do that immediately when you return. However, if at any point you have an error or you throw an exception, well, that's when you can use promise.catch. So let's imagine here, we'll define it again,

well, that's when you can use promise.catch. So let's imagine here, we'll define it again, but now I'm going to throw some problem with speaking. Okay, so now we're going to throw an Exception, which means I can't say hello. I can't do this. It's not going to pick up on it because we have an uncaught Exception from our promise. So instead, I could say right here, say hello, catch any error or exception that might be thrown,

and then we will continue on. So now this should be a lot more obvious. We can say, okay, we've added this async keyword, so we know this function will now return a promise. And as it turns out, Mocha offers support for when you return a promise here. Next, our await keyword, well, when we call nextTick on the viewModel and we don't give it a callback here, that's going to return a promise itself. So we are basically saying pause until the resolution of this returned promise.

So that basically wraps up the lesson. The only other quick point that Joseph brought up that we will review is that when a component is destroyed, we also need to make sure to manually kill the timer. So if we were to take a look at countdown.review, yes, we kill the timer once it is complete, but we should also listen for when the component is destroyed and then clear the interval. So I do need to have access to our interval. Why don't we store that here?