This post walks through bootstrapping an angular app asynchronously. You may find yourself needing to bootstrap angular asynchronously if you need to load system wide configs for example.
Q has Q.allSettled. $q does not. The main difference between $q.all and $q.allSettled is that $q.allSettled waits for all promises to resolve or reject (i.e. “settle”). Then it resolves. $q.all rejects when the first project is rejected.
Paraphrased from Q’s documentation:
$q.allSettled returns a promise that is fulfilled with an array of promise state snapshots, but only after all the original promises have settled, i.e. become either fulfilled or rejected.
This method is often used in order to execute a number of operations concurrently and be notified when they all finish, regardless of success or failure.
I’ve noticed a lot of Angular devs request $q.allSettled. So here it is! JS Fiddle.
$q.when() great. $q.whenFn() opens a new way to think about promises.
Continue reading $q.whenFn a subtle change from AngularJS’s $q.when.
Hey AngularJS devs! Let’s talk about executing async tasks serially with promises and how $q.serial can help.
First, we notice .then allows our success/fail callbacks to return a promise. $q treats success/fail callbacks that return promises specially. We’ll look at two examples to see how $q treats success/fail functions that return promises differently from those that don’t.
Continue reading $q.serial – execute promises serially in AngularJS.
Recently I started working with AngularJS. One of things I enjoy most about AngularJS are promises. Promises are a design pattern / module useful for asynchronous tasks. Normally, I rave about how awesome promises are, but instead of raving I wanted to talk about something that tripped me up when I first started using promises.
The following promises are not equivalent. And I’m going to explain why.
var deferred = $q.defer(); deferred.promise.then(mySuccessCallback, angular.noop, myNotifyCallback); deferred.promise.then(mySuccessCallback, null, myNotifyCallback);