So I run into this issue when waiting on multiple events I don't initiate.
What I do is create a subclass of promise that exposes these calls.
Not saying that's the ideal way to do it, but solvable in userland and
without modifying the base class.
On Thursday, July 19, 2018, Isiah Meadows <isiahmead...@gmail.com> wrote:
> Sometimes, it's *very* convenient to have those `resolve`/`reject`
> functions as separate functions. However, when logic gets complex
> enough and you need to send them elsewhere, save a continuation, etc.,
> it'd be much more convenient to just have a capability object exposed
> more directly rather than go through the overhead and boilerplate of
> going through the constructor with all its callback stuff and
> everything.
>
> It's surprisingly not as uncommon as you'd expect for me to do this:
>
> ```js
> let resolve, reject
> let promise = new Promise((res, rej) => {
> resolve = res
> reject = rej
> })
> ```
>
> But doing this repeatedly gets *old*, especially when you've had to
> write it several dozen times already. And it comes up frequently when
> you're writing lower-level async utilities that require saving promise
> state and resolving it in a way that's decoupled from the promise
> itself.
>
> -----
>
> So here's what I propose:
>
> - `Promise.newCapability()` - This basically returns the result of
> [this][1], just wrapped in a suitable object whose prototype is
> %PromiseCapabilityPrototype% (internal, no direct constructor). It's
> subclass-safe, so you can do it with subclasses as appropriate, too.
> - `capability.resolve(value)` - This invokes the implicit resolver
> created for it, spec'd as [[Resolve]].
> - `capability.reject(value)` - This invokes the implicit rejector
> created for it, spec'd as [[Reject]].
> - `capability.promise` - This returns the newly created promise.
>
> Yes, this is effectively a deferred API, but revealing constructors
> are a bit too rigid and wasteful for some use cases.
>
> [1]: https://tc39.github.io/ecma262/#sec-newpromisecapability
>
> -----
>
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
