Re: Concerns about DOMRequest

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.  

[1] https://mail.mozilla.org/pipermail/es-discuss/2012-November/026188.html

-- 
Marcos Caceres
http://datadriven.com.au

Received on Monday, 18 February 2013 15:16:16 UTC