RE: Concerns about DOMRequest

Hi,

For the record, I also agree that adding a then() method to DOMRequest would result in shorter and much more readable code.

Another question I have related to DOMRequest is: Where should it be specified?
For now, I have a DOMRequest clone ("AlarmRequest") in the Alarm draft. Since, then I saw it is part of RunTime proposal(s). It really needs to be specified in one place so that all our SysApps API specifications can reuse it but I'm not sure the RunTime specification is the right place for it.

Kr,
Christophe Dumez.
________________________________________
From: Jonas Sicking [jonas@sicking.cc]
Sent: Friday, February 15, 2013 07:08
To: Marcos Caceres
Cc: Anne van Kesteren; Mounir Lamouri; public-sysapps@w3.org; Alex Russell
Subject: Re: Concerns about DOMRequest

On Thu, Feb 14, 2013 at 4:35 AM, Marcos Caceres <w3c@marcosc.com> wrote:
>
>
>
> On Thursday, 14 February 2013 at 11:17, Anne van Kesteren wrote:
>
>> On Wed, Feb 13, 2013 at 8:27 PM, Marcos Caceres <w3c@marcosc.com (mailto:w3c@marcosc.com)> wrote:
>> > It would still really suck if you added .then() but still required everything to be wrapped in a function.
>>
>> What do you mean by this?
>
> In IDB, the design of the API forces a developer to do everything synchronously, even though the IDB operation is async in the background (you have to start an operation before you can set listeners on it - so developer are forced to do everything in one go inside a function). See the following, for example:
> http://www.html5rocks.com/en/tutorials/indexeddb/todo/#toc-step2

This is simply not accurate. DOMRequest doesn't force you to do
anything synchronously that DOMFuture/Promises doesn't.
DOMFuture/Promises provides the .then function which is *very* nice
syntax sugar for handling asyncronous callbacks, especially when you
need to nest multiple asynchronous actions. But it doesn't change
anything about when any actions need to be taken.

With DOMRequest the syntax is

req = doSomeAsyncThing();
req.onsuccess = successHandler;
req.onerror = errorHandler;

or, if you want to nest async callbacks:

req = doFirstAsyncAction();
req.onsuccess = function(e) {
  firstSuccessHandler(e);
  var req2 = doSecondAsyncAction();
  req2.onsuccess = secondSuccessHandler;
  req2.onerror = errorHandler;
}
req.onerror = errorHandler;


If you don't want to set up your success handler immediately, with
DOMRequest you'd do something like:

req = doAsyncAction();
doSometimeLater(function() {
  if (req.readyState == "done") {
    successHandler(req.result);
  }
  else {
    req.addEventListener("success", function(e) {
      successHandler(req.result);
    }
  }
}


The equivalent snippets using DOMFuture/Promises would be something like:

doSomeAsyncThing().then(successHandler, errorHandler);

Nest async callbacks:

doFirstAsyncAction().then(firstSuccessHandler)
.then(doSecondAsyncAction, errorHandler)

Set up your success handler later:

future = doAsyncAction();
doSometimeLater(function() {
  future.then(successHandler);
}


As you can see, the .then function on DOMFuture/Promises certainly
makes the code cleaner and removes a lot of the syntax overhead. But
the capabilities are exactly the same.

This is not to say that the .then function isn't important. It makes a
huge difference. But if you have other problems with DOMRequest then
those concerns likely applies to DOMFuture as well.

/ Jonas

Received on Friday, 15 February 2013 07:23:43 UTC