Re: Concerns about DOMRequest

On Mon, Feb 18, 2013 at 7:15 AM, Marcos Caceres <w3c@marcosc.com> wrote:
>
>
>
> On Monday, 18 February 2013 at 09:50, Kenneth Rohde Christiansen wrote:
>
>> Hi there,
>>
>> > Examples Jonas showed using DOMFuture could just work with DOMRequest if
>> > we add this .then() method.
>> >
>> > Also, we could imagine stuff like:
>> > getSomeData().then(function(data) {
>> > return getDataRelatedToThoseData(data);
>> > }).then(function(data) {
>> > show(data);
>> > });
>> >
>> > I have a patch for Gecko implementing that.
>>
>> I like this pattern. It also seems closer to what MS are using in
>> their Windows 8 JS APIs.
>>
>
>
> Not that just adding .then() does not address other issues with the API. David Braunt articulated this best in [1]:
>
> "In my opinion, one of the most absurd example is the DOMRequest thing which
> looks like:
> {
> readonly attribute DOMString readyState; // "processing" or "done"
> readonly attribute DOMError? error;
> attribute EventListener onsuccess;
> attribute EventListener onerror;
> attribute readonly any? result;
> };
>
> Read it carefully and you'll realize this is actually a promise... but
> it has this absurd thing that it has to have both an error and result
> field while only one is actually field at any given point.
>
> Also, these APIs and JavaScript as it they are won't support promise
> chainability and the excellent error forwarding that comes with it
> off-the-shelf. Also, the lack of a built-in Q.all really doesn't promote
> good code when it comes to event synchronization.
> Oh yes, of course, you can always build a promise library on top of the
> current APIs, blablabla... and waste battery with these libraries [3].
> "
>
> This "absurdity" is prevalent in all currently proposed SysApps APIs based on the DOMRequest pattern. As such, they will all need to be reworked to some degree.

You should look at the DOMFuture API, which is currently the closest
thing we have to a proposal for a standardized promise. It's just a
DOMRequest with a .then function as well as some bikeshed naming
issues ("value" instead of "result" etc).

Keeping .result and .error separate is just good API design. Sure, we
could stuff any errors into the .result property, but that makes it
harder and more error prone for people to check if the promise
succeeded or failed. I.e. you'd have to look at a separate .state or
boolean .failed property to see if the .result contains a success or
error value.

There's definitely a lack of a Q.all function. That needs to be added.
But it's not clear that that would go directly on the
DOMRequest/DOMFuture interface.

Of course, saying that "DOMRequest is just a promise without a .then
function" is a bit of a simplification giving that most promise
libraries are literally just a .then function. That doesn't change the
fact that DOMRequest is a good stand-in until we have a standardized
promise though. If you are eager to see a standardized promise I
suggest you contribute to DOMFuture, which David Braunt has been
doing, or otherwise bring a promise proposal to an appropriate W3C WG.

/ Jonas

Received on Monday, 18 February 2013 16:21:13 UTC