Monthly Archives: January 2014

It’s Promises, All the Way Down

I’ve been working with AngularJS and using its Promises for a while now.

I tend to think of a Promise as an IOU that Angular hands me. No…  more as an empty box for data that Angular has yet to retrieve. Often the data must be retrieved from the Internet, or a database, or some other place, all too far away in time —  for a snappy, no-lag UI/X that people expect nowadays — to rely on.

In Angular, I don’t need the data before I start building a view with it.  I  use its empty-box Promise in stead.

The thing is,  it is Angular that first hands me the empty Promise box in response to, say, a database request.

I choose, at some point in my program, to hand the Promise box, unopened, back to Angular to build a web page screen around the boxes contents.

It is Angular that builds the page, with everything but the data. It is Angular that quietly stuffs the data in the Promise box when it finally gets the real thing. And  it is Angular that rather dramatically pulls the true data out of  the box and pops it on the screen.

I never had to look in the box.

Promises work great and can remain forever unseen under the covers of the Angular framework.  Being able to move on in the programming sequence and create your typical CRUD lists and forms based on objects as-yet unrealized feels good for me as UI programmer. It feels good for me and it feels good for the user. It just flows.

But I want to provide an experience that exceeds the typical CRUD displays. And this may mean working with the real data of the promises.

I want to know when the actual data arrives, just as Angular does behind the scenes.  To do this, I take the Promise into my own hands.  I get $promise from the resource object and call the “$promise.then”  method, passing in my own call-back function for the promise system to call back if and when it retrieves the data successfully. As below, I make it clear that  I want my data mining task  to be launched with the true data in the call below, and I move on to complete other event set-ups.

And then I wait. I wait for the ‘then’.  And when the ‘then’ data arrives, I move on. In real time.  Spawning a task that is based on that data.

In my own practice,  there is always an end to this chain of Futures.

But I got to thinking, how nice would it be for an entire framework or language to use only promises, from end to end? My technique of  triggering  certain tasks only when the real data arrives wouldn’t make sense.  I would never need to wait; I would assume I have a promise. I would blithely move forward, deeper in the code, spawning each task based on a promise, carrying this on to the program’s nether end.

It would be Promises, all the way down.

So then, why can’t I do that now? With what I’ve got? Is this kiting the future?

Stay tuned…