$q.allSettled – Q.allSettled for angular promises

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.

Continue reading $q.allSettled – Q.allSettled for angular promises

$q.serial – execute promises serially in AngularJS.

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.

The Power of Parameter Names

C# 4 introduced named and optional parameters: the ability to set default values for arguments and explicitly label arguments by name instead of just position. Despite being a relatively minor features, named and optional parameters actually do quite a lot to make coding simpler to write, read, and consume. So much so, that I find myself sorely missing this feature when working in languages without it (e. g. JavaScript).

Continue reading The Power of Parameter Names

Better validation with yield and async/await: the wrapper pattern

Recently, I’ve been writing a lot of code which gets packaged up into libraries to be consumed by other developers. One of the key aspects of writing this sort of code effectively is to be stringent about argument validation. The earlier your code detects invalid arguments, the easier it is for consumers of your APIs to diagnose errors. Argument checking is fairly straight-forward, but I recently came upon an interesting subtlety when working with the C# yield keyword.

Continue reading Better validation with yield and async/await: the wrapper pattern

Promises and the danger of angular.noop

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);

Continue reading Promises and the danger of angular.noop

Creating a dynamic OData grid with MedallionOData and JQuery DataTables

LINQ providers such as Entity Framework (and therefore any OData services built on top of them) are heavily reliant on server-side static typing to define the model. This has a number of benefits, such as allowing for automatic strongly-typed endpoint code generation, more robust parsing of OData queries, and added security. However, many practical applications don’t fit nicely into the static query model. Luckily, the MedallionOData library provides an easy solution through it’s ability to create dynamic OData service endpoints. We’ll walk through the setup step-by-step in the context of a toy example.

Continue reading Creating a dynamic OData grid with MedallionOData and JQuery DataTables