Promises and Deferreds

[LesJ]

It would be nice to have Promises and Deferreds added to Ext JS.

Promisses are used extensively in jQuery and Dojo. Also, DeftJS uses them as well.

See the sample chapter from the Async JavaScript book which explains why Promises and Deferreds are helpful.

https://leanpub.com/asyncjs

http://samples.leanpub.com/asyncjs-sample.pdf

http://deftjs.org/

[mitchellsimoens]

Way out of scope for 4.x. Personally I have not been sold on the promises vs how things are done today. Like saying, "what's wrong with how it's done currently?"

[LesJ]

Way out of scope for 4.x. Personally I have not been sold on the promises vs how things are done today. Like saying, "what's wrong with how it's done currently?"

The existing Ext JS API is not convenient for some tasks. For example, when you have a set of async tasks, it's not easy to find out when these tasks completed. This is where you would use Ext.when() and Ext.then(). See the Dojo, jQuery or DeftJS implementation.

http://api.jquery.com/jQuery.when/

[debianw]

I agree. Promises pattern help us to clean the code of nested pyramid callbacks.

In asynchronous programing sometimes We end with something like:

doSomething(function(foo){
  foo = processFoo(foo);
  doMoreStuff(foo, function(bar){
    var baz = getBaz(foo);
    stillMore(baz, function(quux){
      gettingPrettyBad(function(widget){
        return widget + baz;
      });
    });
  });
});

Extracted from a link regarding promises:

"Callbacks are a very useful and tremendously powerful tool. They also have some oddities and quirks related to the “this” variable (JavaScript’s context), but that can easily be managed. But worse than managing “this”, callbacks have a much deeper problem relating to code readability and maintainability"

[flanders]

To be honest I do not really see the issue to. Whats the advantage over:

doSomething: function(foo) {
  this.doMoreStuff(foo, this.doEvenMoreStuff);
},

doMoreStuff: function(foo, cb) {
  ...
  cb();
},

doEvenMoreStuff: function(bar) {
  doFinalStuff(bar, this.doReallyFinalStuff);
},

doFinalStuff: function(we, cb) {
  ...
  cb();
},

doReallyFinalStuff: function(bar, cb) {
  ...
  cb();
},

It might be a minor convenience when wanting to act on to events having occured, but then we can do:

onDataStructureReceived: function(structure) {
  ..
  this.structureProcessed = true;
  this.checkReadyToProceed();
},

onDataReceived: function(data) {
  ...
  this.dataProcessed = true;
  this.checkReadyToProceed();
},

checkReadyToProceed: function() {
  if (this.structureProcessed && this.dataProcessed) {
    doStuff();
  }
},

start: function() {
  doAjaxCall(url, onDataStructureReceived);
  doAjaxCall(anotherUrl, onDataReceived);
}

So I see no benefit at all for the sequential case. Actually I find listing all methods to an object and using them where appropiate more readable. I see a few lines of code saved in cases where you want to wait on multiple conditions. However, I feel that a lot of convenience wrappers like this add more unnecessary complexity then yield positive results.

What if I want to act on the first returning call or when I have received 2 out of 3?

[LesJ]

flanders, you assumed that all responses will be successful. This may or may not be the case. If you wanted to handle failures, your workaround code would be quite messy. The code with promisses is much simpler.

Also, keep in mind that promisses can be passed around which aids encapsulation.

[LesJ]

One step closer to moving Futures (nee "Promises") into DOM + JS:

A design for Futures/Promises in DOM

http://lists.w3.org/Archives/Public/...nMar/0200.html