{"id":2530,"date":"2024-06-05T07:54:26","date_gmt":"2024-06-05T13:54:26","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=2530"},"modified":"2024-06-05T07:54:27","modified_gmt":"2024-06-05T13:54:27","slug":"control-javascript-promises-from-anywhere-using-promise-withresolvers","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/control-javascript-promises-from-anywhere-using-promise-withresolvers\/","title":{"rendered":"Control JavaScript Promises from Anywhere Using Promise.withResolvers()"},"content":{"rendered":"\n

Promises in JavaScript have always had a firm grip on their own destiny. The point at which one resolves or rejects (or, more colloquially, \u201csettles\u201d) is up to the executor function provided when the promise is constructed. A simple example:<\/p>\n\n\n

const<\/span> promise = new<\/span> Promise<\/span>((resolve, reject<\/span>) =><\/span> {\n  setTimeout(()<\/span> =><\/span> {\n    if<\/span>(Math<\/span>.random() < 0.5<\/span>) {\n      resolve(\"Resolved!\"<\/span>)      \n    } else<\/span> {\n      reject(\"Rejected!\"<\/span>);\n    }\n  }, 1000<\/span>);\n});\n\npromise\n  .then((resolvedValue<\/span>) =><\/span> {\n    console<\/span>.log(resolvedValue);\n  })\n  .catch((rejectedValue<\/span>) =><\/span> {\n    console<\/span>.error(rejectedValue);\n  });<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
The design of this API impacts how we structure asynchronous code. If you\u2019re using a promise, you need to be OK with it owning the execution of that code.<\/p>\n\n\n\n
Most of the time, that model is fine. But occasionally, there are cases when it would be nice to control a promise remotely, resolving or rejecting it from\u00a0outside<\/em>\u00a0the constructor. I was going to use \u201cremote detonation\u201d as a metaphor here, but hopefully your code is doing something less… destructive. So let\u2019s go with this instead: you hired an accountant to do your taxes. They could follow you around, crunching numbers as you go about your day, and they let you know when they are finished. Or, they could do it all from their office across town and ping you with the results. The latter is what I\u2019m getting at here.<\/p>\n\n\n\n
Typically, this sort of thing has been accomplished by reassigning variables from an outer scope and then using them when needed. Building on that example from earlier, this is what that outer scope method is like:<\/p>\n\n\n
let<\/span> outerResolve;\nlet<\/span> outerReject;\n\nconst<\/span> promise = new<\/span> Promise<\/span>((resolve, reject<\/span>) =><\/span> {\n  outerResolve = resolve;\n  outerReject = reject;\n});\n\n\/\/ Settled from _outside_ the promise!<\/span>\nsetTimeout(()<\/span> =><\/span> {\n  if<\/span> (Math<\/span>.random() < 0.5<\/span>) {\n    outerResolve(\"Resolved!\"<\/span>)      \n  } else<\/span> {\n    outerReject(\"Rejected!\"<\/span>);\n  }\n}, 1000<\/span>);\n\npromise\n  .then((resolvedValue<\/span>) =><\/span> {\n    console<\/span>.log(resolvedValue);\n  })\n  .catch((rejectedValue<\/span>) =><\/span> {\n    console<\/span>.error(rejectedValue);\n  });<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
It gets the job done, but it feels a little ergonomically off, particularly since we need to declare variables in a broader scope, only for them to be reassigned later on.<\/p>\n\n\n\n
A More Flexible Way to Settle Promises<\/h2>\n\n\n\n
The new Promise.withResolvers()<\/code> method makes remote promise settlement much more concise<\/a>. The method returns an object with three properties: a function for resolving, a function for rejecting, and a fresh promise. Those properties can be easily destructured and made ready for action:<\/p>\n\n\n
const<\/span> { promise, resolve, reject } = Promise<\/span>.withResolvers();\n<\/span><\/mark>\n<\/span><\/span>setTimeout(()<\/span> =><\/span> {\n<\/span><\/span>  if<\/span> (Math<\/span>.random() < 0.5<\/span>) {\n<\/span><\/span>    resolve('Resolved!'<\/span>);\n<\/span><\/span>  } else<\/span> {\n<\/span><\/span>    reject('Rejected!'<\/span>);\n<\/span><\/span>  }\n<\/span><\/span>}, 1000<\/span>);\n<\/span><\/span>\n<\/span><\/span>promise\n<\/span><\/span>  .then((resolvedValue<\/span>) =><\/span> {\n<\/span><\/span>    console<\/span>.log(resolvedValue);\n<\/span><\/span>  })\n<\/span><\/span>  .catch((rejectedValue<\/span>) =><\/span> {\n<\/span><\/span>    console<\/span>.error(rejectedValue);\n<\/span><\/span>  });\n<\/span><\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Since they come from the same object, the resolve()<\/code> and reject()<\/code> functions are bound to that particular promise, meaning they can be called wherever you like. You\u2019re no longer tied to a constructor, and there\u2019s no need to reassign variables from a different scope.<\/p>\n\n\n\n
Exploring Some Examples<\/h2>\n\n\n\n
It\u2019s a simple feature, but one that can breathe fresh air into how you design some of your asynchronous code. Let\u2019s look at a few examples.<\/p>\n\n\n\n
Slimming Down Promise Construction<\/strong><\/h3>\n\n\n\n
Let\u2019s say we\u2019re triggering a job managed by a web worker for some resource-heavy processing. When a job begins, we want to represent it with a promise, and then handle the outcome based on its success. To determine that outcome, we\u2019re listening for three events:\u00a0message<\/code>,\u00a0error<\/code>, and\u00a0messageerror<\/code>. Using a traditional promise, that\u2019d mean wiring up something like this:<\/p>\n\n\n
const<\/span> worker = new<\/span> Worker(\"\/path\/to\/worker.js\"<\/span>);\n\nfunction<\/span> triggerJob<\/span>(<\/span>) <\/span>{\n  return<\/span> new<\/span> Promise<\/span>((resolve, reject<\/span>) =><\/span> {\n      worker.postMessage(\"begin job\"<\/span>);\n  \n      worker.addEventListener('message'<\/span>, function<\/span> (e<\/span>) <\/span>{\n        resolve(e.data);\n      });\n  \n      worker.addEventListener('error'<\/span>, function<\/span> (e<\/span>) <\/span>{\n         reject(e.data);\n      });\n  \n      worker.addEventListener('messageerror'<\/span>, function<\/span>(e<\/span>) <\/span>{\n         reject(e.data);\n      });\n  });\n}\n\ntriggerJob()\n  .then((result<\/span>) =><\/span> {\n    console<\/span>.log(\"Success!\"<\/span>);\n  })\n  .catch((reason<\/span>) =><\/span> {\n    console<\/span>.error(\"Failed!\"<\/span>);\n  });<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
That\u2019ll work, but we\u2019re stuffing a lot<\/em> into the promise itself. The code becomes a more laborious to read, and you\u2019re bloating the responsibility of the triggerJob()<\/code> function (there\u2019s more than just \u201ctriggering\u201d going on here).<\/p>\n\n\n\n
But with Promise.withResolvers()<\/code> we have more options for tidying this up:<\/p>\n\n\n
const<\/span> worker = new<\/span> Worker(\"\/path\/to\/worker.js\"<\/span>);\n\nfunction<\/span> triggerJob<\/span>(<\/span>) <\/span>{\n  worker.postMessage(\"begin job\"<\/span>);\n  \n  return<\/span> Promise<\/span>.withResolvers();\n}\n\nfunction<\/span> listenForCompletion<\/span>({ resolve, reject, promise }<\/span>) <\/span>{\n  worker.addEventListener('message'<\/span>, function<\/span> (e<\/span>) <\/span>{\n    resolve(e.data);\n  });\n\n  worker.addEventListener('error'<\/span>, function<\/span> (e<\/span>) <\/span>{\n     reject(e.data);\n  });\n\n  worker.addEventListener('messageerror'<\/span>, function<\/span>(e<\/span>) <\/span>{\n     reject(e.data);\n  });\n  \n  return<\/span> promise;\n}\n\nconst<\/span> job = triggerJob();\n\nlistenForCompletion(job)\n  .then((result<\/span>) =><\/span> {\n    console<\/span>.log(\"Success!\"<\/span>);\n  })\n  .catch((reason<\/span>) =><\/span> {\n    console<\/span>.error(\"Failed!\"<\/span>);\n  })<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
This time, triggerJob()<\/code> really is just triggering the job<\/em>, and there\u2019s no constructor stuffing going on. Unit testing is likely easier too, since the functions are more narrow in purpose with fewer side effects.<\/p>\n\n\n\n
Waiting for User Action<\/strong><\/h3>\n\n\n\n
This feature can also make handling user input more interesting. Let\u2019s say we have a\u00a0<dialog><\/code>\u00a0prompting a user to review a new blog comment. When the user opens the dialog, \u201capprove\u201d and \u201creject\u201d buttons appear. Without using any promises, handling those button clicks might look like this:<\/p>\n\n\n
reviewButton.addEventListener('click'<\/span>, () => dialog.show());\n\nrejectButton.addEventListener('click'<\/span>, () => {\n  \/\/ handle rejection<\/span>\n  dialog.close();\n});\n\napproveButton.addEventListener('click'<\/span>, () => {\n  \/\/ handle approval <\/span>\n  dialog.close();\n});<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Again, it works. But we can centralize some of that event handling using a promise, while keeping our code relatively flat:<\/p>\n\n\n
const<\/span> { promise, resolve, reject } = Promise<\/span>.withResolvers();\n\nreviewButton.addEventListener('click'<\/span>, () => dialog.show());\nrejectButton.addEventListener('click'<\/span>, reject);\napproveButton.addEventListener('click'<\/span>, resolve);\n\npromise\n  .then(()<\/span> =><\/span> {\n    \/\/ handle approval<\/span>\n  })\n  .catch(()<\/span> =><\/span> {\n    \/\/ handle rejection<\/span>\n  })\n  .finally(()<\/span> =><\/span> {\n    dialog.close();\n  });\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Here\u2019s how more fleshed-out implementation might look:<\/p>\n\n\n\n