When you think of traversing a tree, what comes to mind? Recursion? Looping with a stack? While both of these methods work perfectly well, neither has the elegance, convenience, composability, and laziness of IEnumerable-based traversal using LINQ. Luckily, it isn’t hard to “factor out” the mechanics of traversing trees and tree-like data structures such that we can cleanly process such objects with LINQ without writing lots of boilerplate code first. In this post we’ll look at a couple functions in the MedallionCollections NuGet package that do just that.
Developers love utility functions, and every developer seems to have his or her favorite set. In my various projects, I find myself using the same utilities over and over again, copying them from project to project. This gets frustrating and wastes time, especially when I find a bug or performance issue in a utility and want to get it updated everywhere. The obvious solution is to wrap my favorite utilities up in their own NuGet package, but this has several disadvantages which I’ll describe further on. To address this issue, I’ve created a tool which allows for the creation of “inline” NuGet packages which are, in my mind, a particularly appropriate way to distribute utilities.
I’ve mentioned before that collection equality is a relatively common and useful operation that has no built-in implementation in the .NET framework:
bool CollectionEquals<t>( this IEnumerable</t><t> @this, IEnumerable</t><t> that, IEqualityComparer</t><t> comparer = null); </t>
Here I’m differentiating collection equality from sequence or set equality: I want two collections to be considered equal if and only if they contain exact same elements, respecting duplicates but disregarding order. While I’ve implemented this functionality in the past, for a new utility library I’m creating I wanted to see how much I could tune the implementation.
Locks are probably the most prolific synchronization construct in all of programming. The premise is simple: carve out a region of code that only one thread can enter at a time. Most programming languages provide support for locking mechanisms in their standard libraries if not (as in C#) in the languages themselves.
Unfortunately, these default tools often start to break down when we start to think about distributed locking. That is, when we don’t want to limit execution just to one thread in the current process but instead to one thread in an entire system or even in a cluster of systems.
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.