The Promise Constructor within JavaScript assumes that we are going to do our asynchronous work within the constructor callback, but sometimes you want to give the promise to one party so that they can follow the async chain and then give the resolvers to another party so that they can decide the fate of the promise. This is where the Wi Resolver function comes into play. So let's take a look. This example demonstrates the basic structure of a modern JavaScript promise. We have the Promise Constructor where we get the resolve and the reject methods, which can be used to determine the fate of the promise. And within the callback, we choose to carry out the work

that will eventually resolve or reject the promise. Now let's take a look at how we can potentially move the work out of the Promise Constructor. If we create variables outside of the Promise Constructor to store the resolve and the reject methods, we can set them up by using the values that are provided to the constructor callback. And this allows us to do the work outside of the Promise constructor and then use the resolve and the reject methods. Now this quote is definitely more robust in the quote that we saw previously, but fortunately it can be simplified thanks to the Promise with resolvers method that exists within modern JavaScript.

Now let's do a quick recap between the Promise constructive version versus the Promise With resolvers version, with the Promise Construction version, the work is being done within the Promise constructor callback versus with resolvers where we have the ability to determine the fate of the promise outside of the callback. The work can be carried out independent of the promise. Now that you have an understanding of what the pattern looks like and how it allows you to move the resolution logic outside of the promise constructor, let's take a look at the practical application. Consider a simple class that will only

call a provided callback. After end calls, we start off by tracking the count as zero. Within the constructor, we take the number of calls after which we will invoke the end callback, and then within the call function, we increment the count. And if it is a factor of the provided end, then we invoke the provided end callback. This is a pretty simple class with some pretty simple requirements, so let's try to use it within an async function. We set up an instance that will call a provided callback after every three invocations. Next, we set up an interval that will invoke the call method

after every second, and we have a very simple async requirement that after the third call, we should clear the interval and exit the program. I encourage you to pause the video at this point and think of a possible solution. Now, the solution to this problem is actually quite simple. We need an async resolution to happen over here to resolve a promise over here, and we can get these two pieces of the puzzle using the with resolvers method. We resolve the promise within the callback, and then we simply AWAI the promise to ensure

that the execution continues after the promise has been resolved. And once the promise is resolved, we can clear the interval. Now, this isn't the only solution To this problem, however, it does demonstrate how you can easily separate the promise and its resolvers if you are ever forced into a situation where they need to be used in different portions of the code base. One final thing worth mentioning is that with resolvers allows you to defer the resolution of the promise to some party outside of the promise constructor, which is the reason why it was traditionally called the deferred promise pattern.

The term deferred promise is not something that you should need to worry about anymore, but some old developers like me might still use that term, so it's good to know. As always, thank you for joining me and I'll see you in the next one.