1. #1
    Touch Premium Member
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    1,180
    Vote Rating
    102
    LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light

      0  

    Default Promises and Deferreds

    Promises and Deferreds


    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/

  2. #2
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    35,668
    Vote Rating
    746
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    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?"
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  3. #3
    Touch Premium Member
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    1,180
    Vote Rating
    102
    LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light

      0  

    Default


    Quote Originally Posted by mitchellsimoens View Post
    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/
    Last edited by LesJ; 5 Nov 2012 at 6:39 AM. Reason: add deftJS reference

  4. #4
    Sencha User debianw's Avatar
    Join Date
    Mar 2012
    Location
    Costa Rica
    Posts
    48
    Vote Rating
    1
    debianw is on a distinguished road

      0  

    Default


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

    In asynchronous programing sometimes We end with something like:
    Code:
    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"

  5. #5
    Sencha User
    Join Date
    Dec 2009
    Location
    Enschede, The Netherlands
    Posts
    327
    Vote Rating
    13
    flanders will become famous soon enough

      0  

    Default


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

    Code:
    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:

    Code:
    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?

  6. #6
    Touch Premium Member
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    1,180
    Vote Rating
    102
    LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light

      0  

    Default


    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.

  7. #7
    Sencha User
    Join Date
    Dec 2009
    Location
    Enschede, The Netherlands
    Posts
    327
    Vote Rating
    13
    flanders will become famous soon enough

      0  

    Default


    Hmmmz, thats a fairly strong point :P I'll ponder on it.

    But still (I love to start a line like this as a much disliked housemate used to do it all the time)...

    But still, I wonder if it would be wise to add many utility/handy methods/approaches/patterns. Just my 2 cents

  8. #8
    Touch Premium Member
    Join Date
    Nov 2009
    Location
    London
    Posts
    49
    Vote Rating
    6
    mattgoldspink is on a distinguished road

      0  

    Default


    Hey all,

    I'm gonna chime in here and say that I used to be someone who used callbacks (it was all I knew) and then I tried switching to Promise's and a few days was pretty much sold on them being a better way to write async code than callbacks. I've written up a blog post comparing the two approaches from a Sencha perspective here:

    http://www.mattgoldspink.co.uk/2013/...-sencha-touch/

    Hopefully the code examples will resonate with people and they can see the benefits of promises vs callbacks.

    Having had a brief discussion on twitter and in person with a few people I was of the opinion that perhaps Sencha should offer a promises approach in addition to the callback approach (the @sencha twitter account recommended I post here to contribute to the discussion).

    However I'm now of the opinion that there is no easy way to add them in back compat way. For example Ext.Ajax.request() is a prime candidate for using promises, but it already returns a request object, therefore to introduce promises you'd need to either change that are start interesting Ext.Ajax.requestWithPromise() methods all over the place and that just seems messy.

    Personally I'm quite happy wrapping calls to Ext.Ajax.request, Ext.data.Store.load behind my own higher level abstractions that make more sense. It gives me more control over how people interact with the data (I can easily introduce offline support if people using my API's don't call the rest api's directly).

    My 2c

    Matt

  9. #9
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    35,668
    Vote Rating
    746
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    Disclaimer: this is my personal opinion.

    From what I just read, it seems that what you said is that it's easier to read.

    This code:

    Code:
    function getUserDetails(username, successHandler, errorHandler) {
        Ext.Ajax.request({
            url: "/user/details",
            params: {
                username: username
            },
            success: function(response) {
                if (Ext.isFunction(successHandler)) {
                    var userDetails = Ext.decode(response.responseText);
                    successHandler(userDetails);
                }
            },
            failure: function(response) {
                if (Ext.isFunction(errorHandler)) {
                    errorHandler("Could not get user details - server response was " + response.status);
                }
            }
        });
    }
    Can be simplified to:

    Code:
    function getUserDetails(username, successHandler, errorHandler) {
        Ext.Ajax.request({
            url: "/user/details",
            params: {
                username: username
            },
            success: successHandler,
            failure: errorHandler
        });
    }
    and now the successHandler/errorHandler can have a common code that you can reuse to handle Ajax failures or success (especially the failure). In fact, I'd have a common code that you can have errorHandler return a function so then I'd have this:

    Code:
    function getUserDetails(username, successHandler, errorHandler) {
        Ext.Ajax.request({
            url: "/user/details",
            params: {
                username: username
            },
            success: successHandler,
            failure: errorHandler('Could not get user details')
        });
    }
    So I'm executing errorHandler right away, but it would return a function which would get executed on the failure and in that closure I can handle the string I passed in. I'm sorry, I love this pattern and the standardization it gives and the code reusability but I felt it was a difference in your promises vs callback blog. If successHandler was undefined, it would not throw an error so you don't have to check for it. The promises you didn't do the function() {...}, you just pass the function and let the promise execute it.

    You can use the same pattern for promises also so what's the difference? Just the ability to some day add an argument? If you change any code you are going to have to retest that code. If you want to add an argument and you want to have it after username, you can do that very easily. Go through your code and change where you execute getUserDetails and pass in null for the new argument space. Sound like more work than doing it with promises? Yes it is but IMO, and if you were to work with me you would know I have code OCD, it would be the proper way to do it and it's really not that hard. Search for 'getuserDetails', add in null. 2 minutes later you are done, not really a complaint IMO.

    So the end, I'm not against promises, I just know that I wouldn't want the framework to support both so it'd be either or and the amount of work to switch over to promises is quite a bit and for me there isn't really a pay off especially when you start thinking backwards compat.

    Also, I don't like using callbacks, I like using events. Ext.Ajax is only time I'm required to use callbacks and I just fire an event and the controller listens to that event.
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  10. #10
    Touch Premium Member
    Join Date
    Nov 2009
    Location
    London
    Posts
    49
    Vote Rating
    6
    mattgoldspink is on a distinguished road

      0  

    Default


    Hi Mitchell,

    In the end these things will always come down to personal opinions as there is probably benefits either way - I would recommend trying the approach first on a reasonable sized project (I had to be persuaded first and the best way to form a true opinion is to try in anger).

    I did have a few comments on the example you posted and things you mentioned though
    (as an aside - I think my perspective on this comes working on large projects with very decoupled components so that they can easily be re-used and tested and where not every developer follows the same conventions):

    Code:
    function getUserDetails(username, successHandler, errorHandler) {
        Ext.Ajax.request({
            url: "/user/details",
            params: {
                username: username
            },
            success: function(response) {
                if (Ext.isFunction(successHandler)) {
                    var userDetails = Ext.decode(response.responseText);
                    successHandler(userDetails);
                }
            },
            failure: function(response) {
                if (Ext.isFunction(errorHandler)) {
                    errorHandler("Could not get user details - server response was " + response.status);
                }
            }
        });
    }

    and now the successHandler/errorHandler can have a common code that you can reuse to handle Ajax failures or success (especially the failure).
    I'd expect the common code to be hidden behind the API of getUserDetails, otherwise everywhere that calls it will have to copy the common code (or share it somehow - perhaps a function generating factory which parses the response into JSON). In my situation different parts of the application use the response for this in different ways, so the only boiler plate code is the JSON parse of the response, therefore I don't think the above simplification holds true for the API I'd want to provide to my users (I'd be interested to know if you have a different approach to this that would suit the kind of applications I have in mind).

    Code:
    function getUserDetails(username, successHandler, errorHandler) {
        Ext.Ajax.request({
            url: "/user/details",
            params: {
                username: username
            },
            success: successHandler,
            failure: errorHandler('Could not get user details')
        });
    }
    So I'm executing errorHandler right away, but it would return a function which would get executed on the failure and in that closure I can handle the string I passed in.
    I can see why you like this, but it feels counter intuitive to what I think a lot of developers would expect. I guess changing the name to be "errorHandlerCreationFn" might make more sense, and making it clear in the docs of the function that this will happen. I guess I'm a fan of the principle of least surprises.

    If you want to add an argument and you want to have it after username, you can do that very easily. Go through your code and change where you execute getUserDetails and pass in null for the new argument space. Sound like more work than doing it with promises?
    I don't think it is more work to do it with promises - you just add the argument. That's the beauty!

    No need to scan code for places it needs to be updated because by the definition of your API no-one should be passing in more than one. Again part of this issue comes down to shipping a library/API for others to use - getting them to all go through their code to update their invocations is a hassle for them.

    I think our perspectives on the usability of the two approaches come from different angle's of coding that we do and the audience for who our code is targeted.

    the amount of work to switch over to promises is quite a bit and for me there isn't really a pay off especially when you start thinking backwards compat.
    Completely agree - the api's that need it the most are too ingrained with the callback approach to ever be changed for a promises approach hence I think it's a of moot point on this thread to be pushing for it. Sadly once a core API is fleshed out in a certain way, changing it to cater for other use cases can be way more effort than it's worth and I think thats the case with Ext.Ajax and Ext.data.Store.load().

    Also, I don't like using callbacks, I like using events.
    And yes I agree that in most cases using event's is probably better, but sometimes I think it's better to be able to call an API which is task focussed i.e. do this ONE thing and call me back when it's done - thats when callbacks/promises are better suited.

    As always it's great to have these discussions as it's a learning experience on both sides.

    Thanks,
    Matt

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar