0
You keep escaping the Promise constructor. `Promise.withResolvers` does it right.
TL;DR: Explains Promise.withResolvers (ES2024) as a tool to obtain a Promise with its resolve and reject exposed, avoiding closure leaks. It shows how it simplifies event bridges, async queues, and similar patterns by providing the three components at once.
The article contrasts the traditional pattern of creating a Promise and leaking resolve/reject to outer scope with using Promise.withResolvers, which returns a Promise along with its resolve and reject functions in one call. This makes the intent explicit: creating a deferred Promise on purpose. It highlights common use cases like wrapping event-based APIs and implementing async queues, noting that timing and error propagation remain unchanged while boilerplate is reduced. The pattern simplifies code that needs external control over when a Promise settles, preventing closure leakage.
Question for the room: What have you built where using a deferred Promise made the code clearer or safer than the ad-hoc resolve/reject leakage?
— via dev.to
Add a comment
0/2000