If we want to be able to modify the state of a promise from outside the constructor, we can use the Promise.withResolvers method to get access to the promise, and its resolve
and reject
functions.
[00:00] Create a new promise using the promise constructor. The promise constructor accepts one parameter which is a callback which will be executed synchronously, and the callback would get injected to other callbacks, which is the resolve and the reject [00:19] function. A newly created promise is in pending state, which means it's neither fulfilled nor rejected yet. And the first function out of these 2 to be called would settle down the state of the promise. So if resolve was called, then the promise would fulfill unless it was called with [00:39] an error, then it would reject. Or if reject was called, then the promise would get rejected. So in some situations, especially in tests, what we would like to do is to modify the state of the promise from outside of the constructor. For instance, when an event took place such as there was [00:59] a user interaction like a button on click, whatever. And we would like the promise to get resolved or to fulfill, reject, or to settle in any other way. The problem, however, is that we don't have access to the resolve callback from within the constructor. So the only hack [01:19] to achieve this goal so far was to create 2 additional variables which would basically get the reference to what resolve and reject were inside the constructor. So what people used to do would basically assign to res what resolve used to be and assign to reg what reject used [01:39] to be, which is clearly a abstraction leak. So this would work in this case. However, the new approach is that we can use a slightly different approach to create a new promise, and that would be to use the promise dot with resolvers. [01:58] So a new promise which we're going to create is a promise dot with resolvers function which is going to return us what is the promise itself but also what is the resolve and the reject callback. And this way, we don't need to do any dirty [02:18] workarounds. We have immediately the access to the resolve and reject callbacks of the promise.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!