Using DeftJS Promises to Simplify Service Interaction

Posted on October 4, 2012 by Brian Kotek — 5 Comments ↓

The DeftJS framework for ExtJS and Sencha Touch has been updated to include a Promise API. John and I are already at work on updated docs that cover these (and other) new features, but I wanted to post an entry to explain some of the benefits that Promises bring to the table.

If you aren’t familiar with Promises, perhaps the Wikipedia definition will help:

In computer science, future, promise, and delay refer to constructs used for synchronizing in some concurrent programming languages. They describe an object that acts as a proxy for a result that is initially unknown, usually because the computation of its value is yet incomplete.

Put another way, a Promise represents a future value that will eventually be returned asynchronously. In the JavaScript world, the folks at CommonJS have proposed a specification called Promises/A, which is what the DeftJS Promise API is modeled upon.

Definitions are nice, but I find examples to be much more useful to aid in understanding something. So lets jump in and look at some code.

A Common Example of an Asynchronous Call in ExtJS

Say I’m building an ExtJS application that uses DeftJS. I’ve tried to separate my concerns, so I’ve created a ViewController to manage a UI component, and a Service class to encapsulate interaction with some of my Stores, AJAX logic, and external resources. My ViewController might have a loadCompanies() method like this, which calls an injected Service object. The Service, in turn, asks a CompanyStore to load its data:

# Common way of making async call via underlying Store loadCompanies: -> @companyService.loadCompanies( callback: ( records, operation, success ) -> if( success ) # Do something with results else # Do something with the error # Do something whether the call succeeded or failed ) # CompanyService method using Store loadCompanies: ( config ) -> @companyStore.load( callback: config.callback )

“OK,” you might think, “that doesn’t look too bad.” And on the surface, it isn’t too bad. But let’s dig further. Stores aren’t the only option ExtJS provides for leveraging AJAX. It also has an Ajax class which can be used when a Store won’t fit your needs, or when you need more control over the handling of the results. Let’s look at the same general process I showed above, but using the Ajax class:

# Common way of making async call via underlying Ext.Ajax call loadCompanies: -> @companyService.loadCompanies( success: ( response ) -> results = Ext.decode( response.responseText ) # Do something with results # Do something whether the call succeeded or failed failure: ( response ) -> # Do something with the error # Do something whether the call succeeded or failed ) # CompanyService method using Ext.Ajax call loadCompanies: ( config ) -> Ext.Ajax.request( url: "company/loadCompanies.json" success: config.success failure: config.failure )

Notice anything disconcerting? The two calls to my Service method have different ways of defining the callbacks: one passes a “callback” property, but the other passes separate “success” and “failure” callbacks. The code in the controller is coupled to the way the service loads data. Worse, if you have a number of these sorts of service calls, with mixed sets of arguments, things get pretty ugly. Luckily, using a Promise offers a better way.

An Asynchronous Call using a Promise

Here is the ViewController code, along with examples of Service methods using both a Store load and an AJAX request:

# Using a Promise loadCompanies: -> @companyService.loadCompanies().then( success: ( records ) -> # Do something with results failure: ( error ) -> # Do something with the error ).always( -> # Do something whether the call succeeded or failed ) # Service method using a Store and returning a Promise loadCompanies: -> deferred = Ext.create( 'Deft.Deferred' ) @companyStore.load( callback: ( records, operation, success ) -> if( success ) deferred.resolve( records ) else deferred.reject( "Error loading Companies." ) ) return deferred.promise # Service method using an Ext.Ajax call and returning a Promise loadCompanies: -> deferred = Ext.create( 'Deft.Deferred' ) Ext.Ajax.request( url: "company/loadCompanies.json" success: ( response ) -> records = Ext.decode( response.responseText ) deferred.resolve( records ) failure: ( response ) -> deferred.reject( "Error loading Companies." ) ) return deferred.promise

Excellent. Now the ViewController method looks exactly the same, regardless of what the Service is doing! The Service methods create a Deferred object to wrap the async call, and then return a Promise back to the ViewController. Also, note that I can use the always() method provided by the Promise to run code regardless of whether it succeeded or failed. So what’s the difference between a Deferred and a Promise? To help explain the difference, I created this simple diagram:

So the general idea is that the Deferred is “private”, and actually wraps the async call. The Promise is the “public” view of the state of the Deferred. It won’t allow you to resolve or reject its state, but it will allow you to attach callbacks that are invoked when the state of the Deferred changes.

Multiple Asynchronous Calls

So we’ve seen how a Promise can help standardize the way things interact with async processes, and that’s great. But Promises can do a lot more. For example, let’s say at app startup I need to load both a list of companies and a list of featured products. I can’t proceed until both are finished. One way (a very bad way) this could be done is:

# Ill-advised attempt to make a chain of async call via underlying Store loadInitialData: -> @companyService.loadCompanies( callback: ( companyRecords, operation, success ) -> if( success ) @companyService.loadFeaturedProducts( callback: ( productRecords, operation, success ) -> if( success ) # Do something with both sets of results else # Do something with the error # Do something whether both calls succeeded or failed ) else # Do something with the error # Do something whether both calls succeeded or failed ) # Service methods using Store loadCompanies: ( config ) -> @companyStore.load( callback: config.callback ) loadFeaturedProducts: ( config ) -> @featuredProductStore.load( callback: config.callback )

I think we can all agree that’s just horrible. There are actually some slightly less horrible ways that could be done, but any way you slice it, it’s not very pretty. So how can using Promises help? How about:

# Using a Promise for a chain of async calls loadInitialData: -> @companyService.loadInitialData().then( success: ( records ) -> # Do something with results failure: ( error ) -> # Do something with the error ).always( -> # Do something whether the call succeeded or failed ) # Service method aggregating Promises for separate calls and returning a single Promise loadInitialData: -> return Deft.Promise.all( [ @loadCompanies() @loadFeaturedProducts() ] ) loadCompanies: -> deferred = Ext.create( 'Deft.Deferred' ) @companyStore.load( callback: ( records, operation, success ) -> if( success ) deferred.resolve( records ) else deferred.reject( "Error loading Companies." ) ) return deferred.promise loadFeaturedProducts: -> deferred = Ext.create( 'Deft.Deferred' ) @featuredProductStore.load( callback: ( records, operation, success ) -> if( success ) deferred.resolve( records ) else deferred.reject( "Error loading Products." ) ) return deferred.promise

As you can see, I’m taking the two Promises returned by loadCompanies() and loadFeaturedProducts(), and wrapping them in another Promise. That Promise will resolve or reject based on the state of the two Promises it is wrapping. Even better, we can once again see that the code in the ViewController stays exactly the same as in the previous examples! This is a far better option than the other hackish ways one might come up with to execute multiple calls in a single group.

Conclusion

I’ve shown how Promises can bring consistency to code that has to deal with asynchronous behavior. The ability to treat multiple asynchronous calls as a single unit just adds more icing to the cake. Promises are useful in even more ways, but I’ll stop rambling for now. If you use ExtJS and are using (or considering) DeftJS, you’ll definitely want to give the Promises API a try.

About Brian Kotek

Brian has been developing web applications for over 14 years, primarily using Java, Groovy, .NET, ColdFusion, ExtJS, Flex, and AIR. He's worked as a consultant or employee on a wide range of projects for private companies and government agencies. Brian is a regular speaker at industry conferences, as well as a blogger and author. He has contributed to a number of community endeavors, including DeftJS, Swiz, Fusebox, ColdSpring, and several RIAForge projects.

Tagged with: CoffeeScript, DeftJS, ExtJS
Posted in HTML RIA Development, Life After Flex

5 comments on “Using DeftJS Promises to Simplify Service Interaction”

Gareth Arch says:

October 8, 2012 at 12:09 pm

Thanks for the write up of this stuff.

Didn’t realize it was written in coffeescript at first, so I was looking at the “@” and “->” and figured I was missing something being still slightly new to Sencha.

Reply
Brian Kotek says:

October 8, 2012 at 4:18 pm

Sorry, guess I assumed that with all my droning on about CoffeeScript in prior entries that I should stop talking about it heh. I’ll try to make sure I mention that the code is in CS in the future just to make sure it’s not confusing. Thanks.

Reply
Gabrielle says:

October 11, 2012 at 9:43 am

Thanks a lot Brian. Your post sheds light on DeftJS Promises.
Keep doing such “tutorials”. It is much appreciated.

Reply
Thomas says:

January 11, 2013 at 4:25 pm

I don’t know if I’m missing something, but I’m trying to do something similar to your loadInitialData example, except instead of loading a store I’m just doing a regular ajax request. I’m doing pretty much the same thing, except where you have store.load() I’m doing Ext.Ajax.request() and in the success callback there I’m doing deferred.resolve(). Everything appears to work fine when the requests are successful, but to test a failure I removed one of my deferred.resolve() calls and the success() function in the then() still runs. I also tried called deferred.reject(), also doesn’t work, the success() function still runs. Am I missing something?

Reply
Kevin O'Riordan says:

March 11, 2013 at 2:09 pm

Hmm, it sounds to me like you could be doing

Ext.Ajax.request({
….

success: deferred.resolve()
..
}

instead of

Ext.Ajax.request({
….

success: deferred.resolve
..
}

in which case deferred.resolve() is going to run every single time regardless of whether the success event triggers or not.

Probably worth posting the code you have.

Reply