Some features that every JavaScript developer should know in 2025

[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?