> Note that when you attach a reaction (through the `.then()` method) to a
> promise that was resolved several minutes ago, the reaction will trigger: you
> have to somewhat stretch you mind in order to call that "reacting to state
> change".
What attaching callbacks through `.then()` really does is to create a new
promise and attach it to the parent promise. The reaction lives in the new
promise, and every new child promise without a parent promise is equivalent to
having a pending parent promise. So when you attach that new promise to a
resolved parent promise, I think it's reasonable to say that, from the
reaction's point of view, the parent promise's state has changed.
> As I understand, promises are ideal for requesting and transmitting data
> without having to care much when the data is available
IMHO, that's promises's goal. How does it archive that? By reacting to parent's
promise state change, which is really just a event. The only thing special
about promises is that when you add event listeners, a new promise containing
those listeners are returned, and the events are only filed once for each
promise. Getting the data is like reading event.data.
> If you use promises for asking for data, "cancelling" is naturally akin to
> "reject with an abort signal as reason".
Yes, looks like akin, but is actually totally different. cancelling sends
signals back to parent, rejecting sends signals down to children. The symmetry
can be misleading. Able to sending signals in both directions greatly
complicates the design of promises with no obvious benefits. What I'm saying is
that to archive the goals that you want from cancelling, you actually don't
need the ability to send signal upwards. You don't need to open that can of
worms.
> The child promise that want to show disinterest should just settle itself
Are you talking about this pattern:
```
let parentPromise = asyncAction();
let cancel;
let tmpPromise = new Promise((res, rej) => {
cancel = () => rej(new AbortError());
});
let childPromise = Promise.race([parentPromise.then(...), tmpPromise]);
childPromise.cancel = cancel;
```
This is still one way communication. So does it mean that you agree promises
should be kept that way?
And basically you are giving promises the ability to resolve / reject
themselves after they are created. Let me rewrite previous example with more
familiar APIs:
```
let parentPromise = asyncAction();
let childPromise = parentPromise.then(...);
childPromise.reject(new AbortError()); // don't care about parent promise,
let's reject the childPromise
```
This also means a grand child might have to differentiate from an abort
rejection from a root promise or an ancestor promise, once you encourage this
pattern.
Also, with the ignoring parent state change design, its possible to make a
promise be interested its parent's state change again after it has shown
disinterest. I don't think it's possible if you expose resolve / reject on
created promises.
> On Aug 8, 2015, at 3:13 AM, Claude Pache <[email protected]> wrote:
>
>
>> Le 6 août 2015 à 04:20, Glen Huang <[email protected]
>> <mailto:[email protected]>> a écrit :
>>
>>> promises are fundamentally about chaining data together, not about
>>> listening for events.
>>
>> IMHO, promises are more about reacting to state change and pass down that
>> reaction. And the reaction I'm proposing to add is "no reaction will be
>> passed down".
>
> Note that when you attach a reaction (through the `.then()` method) to a
> promise that was resolved several minutes ago, the reaction will trigger: you
> have to somewhat stretch you mind in order to call that "reacting to state
> change".
>
> As I understand, promises are ideal for requesting and transmitting data
> without having to care much when the data is available (be it several minutes
> ago or several minutes later) — which would be managing an event. On the
> contrary, a "state change" sounds more like an event.
>
> The way you think of (and use) promises will influence the way you think what
> "cancelling a promise" and similar actions should do. If you use promises for
> asking for data, "cancelling" is naturally akin to "reject with an abort
> signal as reason".
>
> Now concerning your original case: "let child promises show disinterest on
> the result of that action". The child promise that want to show disinterest
> should just settle itself (for example reject itself with an abort signal,
> but the precise outcome may depend on the reason why you want to stop
> listening). That will give an appropriate signal to downstream clients, and
> that will prevent itself from receiving messages from upstream (because a
> promise cannot be settled more than once). — (True, the `.then()` method
> doesn’t produce a promise that could be settled prematurely: you have to
> construct it manually. I leave that as an exercise to the reader.)
>
> —Claude
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
