For code that high level, I don't even usually deal with promises in
the first place except when fetching data, saving data, and awaiting
renders and transforms (sometimes). Raw event handlers are good enough
for pretty much everything else, and when they aren't, you're almost
certainly dealing with a stream or similar specialized data type that
isn't a promise.
Either way, deferreds are the worst abstraction to use here, and you
won't even likely see it much in Java code at this level (and
deferreds is really only what Java *has*).
-----
Isiah Meadows
m...@isiahmeadows.com
www.isiahmeadows.com
On Fri, Jul 20, 2018 at 12:27 AM, kai zhu <kaizhu...@gmail.com> wrote:
> my use-case is the exact opposite. in integration-level javascript,
> its impractical to have independent rejectors/error-handlers for
> dozens of integrated-components. its much easier to debug/refactor
> integration-code with a single, universal rejector/error-handler (all
> it does is log the error-stack and return a 404/500 to the
> server-request, or crash the app if client-side).
>
> on server-side, you can't do much except 404/500 if the db-request
> times-out, JSON.parse fails, etc.
>
> on client-side, crashing the app (and notifying user an error occured,
> and retry the request) is pretty much the only thing you can do when
> the server 404/500's.
>
> On 7/20/18, Bob Myers <r...@gol.com> wrote:
>> I've used this pattern exactly twice in the large-scale app I'm working on
>> now.
>> One of those I was able to eliminate after I thought harder about the
>> problem.
>> The other I eventually replaced with the following kind of pattern:
>>
>> ```
>> function createPromise(resolver, rejector) {
>> return new Promise((resolve, reject) {
>> resolver.then(resolve);
>> rejector.then(reject);
>> });
>> }
>> ```
>>
>> Obviously the way this works it that to create a promise "controllable"
>> from "the outside",
>> you create your own resolver and rejector promises to pass to
>> `createPromise`,
>> such that they trigger when you need them to.
>> To put it a different way, instead of getting back and passing around
>> deferred-like objects,
>> which seems to be a massive anti-pattern to me,
>> the client creates their own promise-controlling promises designed to
>> trigger at the right time.
>>
>> Bob
>>
>> On Fri, Jul 20, 2018 at 9:07 AM Jordan Harband <ljh...@gmail.com> wrote:
>>
>>> I don't think the Deferred pattern is a good primitive to have in the
>>> language, and it's a pretty trivial primitive to write yourself if you
>>> need
>>> it.
>>>
>>> On Thu, Jul 19, 2018 at 6:13 PM, 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
>>>
>>
> _______________________________________________
> 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
