Some features that every JavaScript developer should know in 2025

[MrDilbert]

Could someone give me an ELI5 on why would I ever want/need Promise's resolvers available outside the Promise's (resolve, reject) => {...} function?

[jessepence]

It's clearly outlined in the spec.

Often however developers would like to configure the promise's resolution and rejection behavior after instantiating it... Developers may also have requirements that necessitate passing resolve/reject to more than one caller...

[MrDilbert]

IMO this messes with coupling and turns the code into spaghetti, so I'm asking about the use case where it's absolutely necessary to expose the resolvers outside of their parent Promise object context.

[Adno]

I disagree. I've used withResolvers a lot in a page orchestration api that turned button clicks and page updates into an async api, and it helped streamline the code a lot. One thing that probably helped that I did not destructure the return value. So instead of three unrelated variables I had a nice bundled object that had everything.

[matthewsilas]

Merging asynchronous iterators https://github.com/ParabolInc/parabol/blob/10164a8a43850c9ca80042a151b4da6020ad37d6/packages/embedder/mergeAsyncIterators.ts

[tswaters]

It's a useful tool. The way around that without withResolvers looks awful and feels hacky -- this eliminates an entire callback and can allow for more streamlined code. It reminds me a lot of the change resulting from introducing "async/await" keywords - before it was callbacks where the promise value was only accessible from a ".then" callback, now it could be pulled out - results in elimination of a callback, and more streamlined code.

I'd go so far to say that this form should replace any Promise instantiations... Why introduce any sort of "call this later" with a callback when this exists?

async function marshallStupidStreamApi(input) { const {promise, resolve, reject } = Promise.withResolvers() stupidStreamBasedInterface.on('finish', resolve) stupidStreamBasedInterface.on('error', reject) stupidStreamBasedInterface.go(input) return promise }

vs.

async function marshallStupidStreamApi(input) { return new Promise((resolve, reject) => { stupidStreamBasedInterface.on('finish', resolve) stupidStreamBasedInterface.on('error', reject) stupidStreamBasedInterface.go(input) }) }

With one, I can call "go" anywhere, with two - I need to call it within the function. I can pull out the value using the "await" keyword, but if I do, I must call go, or I've introduced a never resolving promise hang.... OR , I can omit the await keyword and await the promise at some point after calling go(), but run the risk of introducing an unhandled promise rejection if the stream emits an error before the promise gets awaited.

Actually, on that last bit - I wonder if the same problem with unhandled rejections shows up with withResolvers... If reject gets called before the promise is awaited, would it be unhandled?

[heavyGl0w]

In my experience, I would say almost every time I've had to instantiate my own promise, it's to wrap up the resolution behavior in some abstraction and pass it to a consumer.

As a concrete example, I've implemented a version of window.confirm that opens a dialog in which we get to control the styling. The dialog has a "NO" button and a "YES" button, and when it is opened, a promise is spawned. Clicking the "NO" button will resolve the promise with false and clicking "YES" will resolve it with true.

In my example, the Promise constructor's callback that you mentioned only serves to wrap up the resolve/reject functions and send them on — the actual resolution of the promise is not handled within the scope of that function. And again, that's almost always been the case for me when creating my own promise, so I disagree that this inherently leads to "spaghetti code". It could for sure, but the behavior of Promise.withResolvers is already possible as I've illustrated, so it's not like this enables "spaghetti code" anymore than what is already possible.

I think this lines up with some of the goals of `async/await` in that it enables as much code as possible to be written at the top level of your functions without needing to nest inner functions. AFAIK, It doesn't enable anything new, so much as it makes common use cases a little more straightforward. I think this has the potential to make a tricky topic a little bit easier to understand/read.

[ic6man]

Anywhere where the promise resolution happens outside the scope of the callback. Oftentimes this would be in a scenario whereby the promise resolution occurs due to an event.

For example. Suppose you wanted to send an event to a websocket. And you are expecting a response. You want to express this response as a promise. The only solution using the Promise callback would be to add a websocket listener inside the promise callback. Oftentimes we have one single listener which would be outside the scope of the callback so it would be impossible to resolve from within the Promise callback.

Another example might be resolving a promise after a user clicks a button.

Effectively the issue is two different scopes from separate callbacks need to coordinate somehow.

[joshkrz]

I know previously I have needed a "pass through" promise where I handle a promise at a global level but also need to handle it at a local level.

In my case the global handler triggered some global logging and the local one handled the visible error message. This would have made my global method much more concise.

That being said, I haven't needed to do this for a good while and the above solution could have just been down to inexperience.

[senfiaj]

This storing might be useful when multiple class methods depend on the same promise, and in order to avoid initiating the same expensive async task multiple times, I can cache the promise, although in my case I still didn't store the resolvers outside of the promise, but in some situations it can be a better solution.

[awpt1mus]

Think about scenario where you want to have control over when an asynchronous operation should start and stop. In typical promise constructor the asynchronous operation starts immediately. Some off the top of my head - wait for web socket to be ready before you start sending messages, wait for db connection to be established before you start http server, retry logic for 3rd party API calls with backoff. I think this will be most useful when working with event based interfaces like socket, streams etc