If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Implement the Future API

RESOLVED DUPLICATE of bug 856410

Status

()

Core
DOM: Core & HTML
RESOLVED DUPLICATE of bug 856410
5 years ago
5 years ago

People

(Reporter: David Bruant, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
Promise-like constucts.
Draft spec currently at https://github.com/slightlyoff/DOMFuture/blob/master/DOMFuture.idl
Status: NEW → UNCONFIRMED
Ever confirmed: false
OS: Linux → All
Hardware: x86 → All
Version: unspecified → Trunk
(Reporter)

Comment 1

5 years ago
Interesting conversation happening on issue #19 [1]

Mounir:
"We might move away from DOMRequest if there is a very good proposal that beats DOMRequest."

A pending question is:
What would be the criteria for a good DOMRequest replacement?
It seems that DOMRequests are already close to promises/futures, so anything that looks like promises/futures will look like DOMRequests.

Delta from DOMRequests to the proposed Future:
1) DOMRequest have to be construct-able by user code (which includes the accept/reject callback mechanism)
2) Add chainable then/catch/done (done is necessary to stop the chain)
3) Add the state attribute
4) Add a combination mechanism for DOMRequest synchronisation [2]
5) get rid of the onsuccess/onerror (to not encourage bad patterns)

On the Mozilla side, an important question is whether this amount of make-up is sufficient to justify changing the name from DOMRequest to something more "correct" or "idiomatic" like /future/.


[1] https://github.com/slightlyoff/DOMFuture/issues/19
[2] https://github.com/slightlyoff/DOMFuture/issues/16
Depends on: 839838
(In reply to David Bruant from comment #1)
> Interesting conversation happening on issue #19 [1]
> 
> Mounir:
> "We might move away from DOMRequest if there is a very good proposal that
> beats DOMRequest."
> 
> A pending question is:
> What would be the criteria for a good DOMRequest replacement?
> It seems that DOMRequests are already close to promises/futures, so anything
> that looks like promises/futures will look like DOMRequests.
> 
> Delta from DOMRequests to the proposed Future:
> 1) DOMRequest have to be construct-able by user code (which includes the
> accept/reject callback mechanism)

Nothing prevents DOMRequest to do that but I wouldn't make this a priority because I believe we need the "consumer" to not be able to call .accept() on the Future. A design that might work would be to have a "service" that returns some kind of object like FutureProxy that would have those methods. FutureProxy could have a .get() method to return a Future object. Then, .accept() or .reject() on the proxy would make all the returned futures to be accepted/rejected.

> 2) Add chainable then/catch/done (done is necessary to stop the chain)

.done() is in no way mandatory. It's just a syntax sugar to make it more readable. We already have a bug to implement .then().

> 3) Add the state attribute

DOMRequest already have .readyState which can be { "pending", "done" }. The only difference is that DOMFuture allows the state to be "accepted" or "rejected". Our thought was that "accepted"/"rejected" information would be found by checking the .result.

> 4) Add a combination mechanism for DOMRequest synchronisation [2]

You mean something like .when(). We talked about that with Alex and Jonas and we should be able to use WebIDL variadics to implement this.

> 5) get rid of the onsuccess/onerror (to not encourage bad patterns)

I asked Alex and according to what he told me, DOMFuture will have that mechanism.

> On the Mozilla side, an important question is whether this amount of make-up
> is sufficient to justify changing the name from DOMRequest to something more
> "correct" or "idiomatic" like /future/.

DOMRequest -> DOMFuture isn't important. It's unlikely that some code out there checks the interface name. I would be glad to change the name to DOMPromise or DOMFuture. We talked about that with Jonas a few months ago actually.
However, the bothering part is changing all attributes name because it breaks retro-compatibility for not much win.
(Reporter)

Comment 3

5 years ago
(In reply to Mounir Lamouri (:mounir) from comment #2)
> (In reply to David Bruant from comment #1)
> > Interesting conversation happening on issue #19 [1]
> > 
> > Mounir:
> > "We might move away from DOMRequest if there is a very good proposal that
> > beats DOMRequest."
> > 
> > A pending question is:
> > What would be the criteria for a good DOMRequest replacement?
> > It seems that DOMRequests are already close to promises/futures, so anything
> > that looks like promises/futures will look like DOMRequests.
> > 
> > Delta from DOMRequests to the proposed Future:
> > 1) DOMRequest have to be construct-able by user code (which includes the
> > accept/reject callback mechanism)
> 
> Nothing prevents DOMRequest to do that but I wouldn't make this a priority
> because I believe we need the "consumer" to not be able to call .accept() on
> the Future.
That's an important feature indeed. DOMFuture solves this problem by being constructable with a function:

  var f = new DOMFuture(function(r){
    if(sun.shine())
      r.accept("sun");
    else
      setTimeout(r.reject.bind(r, "raaaiin!!"), 1000)
  })

> A design that might work would be to have a "service" that
> returns some kind of object like FutureProxy that would have those methods.
> FutureProxy could have a .get() method to return a Future object. Then,
> .accept() or .reject() on the proxy would make all the returned futures to
> be accepted/rejected.
That's what the Q library does. Their Deferred are your FutureProxy.
I don't care either way (callback mess of the current Future proposal or Deferred/FutureProxy) so long that scripts can create futures.

> > 2) Add chainable then/catch/done (done is necessary to stop the chain)
> 
> .done() is in no way mandatory. It's just a syntax sugar to make it more
> readable. We already have a bug to implement .then().
Unlike then, done doesn't return a Future. That's very important for debugging async code.
If you're doing a chain of .then, the devtools can't know when you've forgotten to deal with an error. Adding a .done ends a promise chain and if the last promise contain an unhandled error, devtools can know about it and report it. Without .done, devtools would have to rely on bad heuristics like when a promise has been GC'ed, etc.
I do believe .done is mandatory to make the async debugging experience much better.


> > 3) Add the state attribute
> 
> DOMRequest already have .readyState which can be { "pending", "done" }. The
> only difference is that DOMFuture allows the state to be "accepted" or
> "rejected". Our thought was that "accepted"/"rejected" information would be
> found by checking the .result.
What if the result is undefined?
If DOMContentLoaded was a future, its "result" would likely be undefined. Other cases exist like a future that gets resolved after some time.
If you can get a way to define the result property or not, that could work. The test would be ("result" in DOMFuture), but checking the value doesn't work.


> > 4) Add a combination mechanism for DOMRequest synchronisation [2]
> 
> You mean something like .when().
I'm don't know what you're referring to. I was meaning something like Q.all from the Q library: https://github.com/kriskowal/q/wiki/API-Reference

> We talked about that with Alex and Jonas
> and we should be able to use WebIDL variadics to implement this.
Can you provide more details of how it would look like?


> > 5) get rid of the onsuccess/onerror (to not encourage bad patterns)
> 
> I asked Alex and according to what he told me, DOMFuture will have that
> mechanism.
By "that mechanism", do you refer to events or the specific onsuccess/onerror properties?

Comment 4

5 years ago
Marking this older bug as a duplicate as it contains a lot of noise the DOMFuture project resolved.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 856410
You need to log in before you can comment on or make changes to this bug.