Resolving An AngularJS Deferred Object Twice With DeferredWithUpdate.js
Posted October 8, 2012 at 10:36 AM by Ben Nadel
A couple of weeks ago, I blogged about using jQuery's Deferred.notify() to provide a locally-cached response before the server had time to resolve the request. Lately, as I've been playing around with AngularJS, I've wanted to implement the same kind of "update" behavior with the $q class - AngularJS' deferred implementation. Since the $q class doesn't have a notify() method, however, I've created a new AngularJS class that decorates the core $q class with update() and mistake() callback hooks.
| | | | ||
| | | |||
| | | |
View the DeferredWithUpdate.js project on GitHub.com.
The DeferredWithUpdate.js module has the same API as the core $q class:
- all()
- defer()
- reject()
- when()
The defer() method instantiates the core $q.defer() method and then augments both the deferred object and its promise. The all(), reject(), and when() methods currently pass the request directly through to the underlying $q class without augmentation.
When the defer() method decorates the underlying promise object, it adds two callback hooks:
- update( callback )
- mistake( callback )
These callbacks will only be invoked if the deferred object events are triggered once the deferred object is already in a resolved state. If the deferred object has been resolved and then the resolve() method is called again, the second request will be routed to the update() callbacks. Similarly, if the deferred object has been resolved and then the reject() method is called, it will be routed to the mistake() callbacks.
The intent here is that the deferred object can be resolved with locally-cached data while still providing the calling context with a hook into the server's true response. And, while the calling context does need to be aware of this new class, the callbacks should work completely fine even if no caching is used.
Reader Comments
Interesting. These decorators are more powerful than what we expected. :-)
I'm curious if others find these api useful. They kind of break the expectations one should have from a promise, but who knows.. maybe the spec is wrong :)
@Igor,
I don't think the spec is wrong ;) I've been loving Deferred / Promise objects for a long time now and this project is the first one where I really wanted this kind of augmentation. This is very specifically for combining locally-cached responses with server-side responses.
I tried, originally, with just the $q class. And this worked great well there was no caching. Then I tried using the $resource class; and that worked great when there was no caching. In both cases, I was basically using the success-callback to update the UI.
When, when I added client-side caching / localStorage integration, then I ended up invoking the callbacks for the cached data and never knew when the server data would come back.
In my situation, I am actually using $q AND $resource - the deferred object resolves to the resource instance. This allows the value to update dynamically (ala the resource behavior). But, I was still left in the cold as to how to "filter" the resultant values once they came back from the server.
But, like I said, this is my first AngularJS project - and I know there is an "angular way". So, this may be crazy - may be missing the point.
@Igor,
One more thing - sorry - since my deferred usually resolve to Resource instances, you only need to use the update() callback *if* you need to *further consume* the data once it comes back from the server. If not, then the simple then() callbacks will already propagate the resource response into the array or object reference.
@All,
As a follow-up, I've looked at applying cached responses to AngularJS $resource responses:
http://www.bennadel.com/blog/2432-Applying-A-Cached-Response-To-An-AngularJS-Resource.htm
... the trick is to never break the original object reference.
