Filter on deep object properties in angularjs

AngularJS provides a neat way of filtering arrays in an ng-repeat tag by piping elements to a built in filter filter which will filter based on a predicate. Doing it this way you can filter items based on a function, or an expression (evaluated to a literal), or by an object.

When filtering by an object you can pass in a javascript object that represents key value items that should match whats in the backing data element. For example:

$scope.elements = [{ foo: "bar" }, { foo: "biz" }]


<div ng-repeat="foos in elements | filter: { foo: "bar" }">
  {{ }} matches "bar"

Here I filtered all the objects whose foo property matches the value “bar”. But what if I have a non-trivial object? Something with lots of nested objects? I found that passing in the object to the filter was both unweidly, and error prone. I … Read more


Mongoose with TypeScript

Mongoose is a library for node.js that wraps the mongoDB driver. Since I’ve been playing with typescript, I wanted to show a short demo of strongly typing mongoose with unit tests run in nodeunit all using typescript.


First, I have a collection of definition files that represent mongoose types, nodeunit types, and my own document types (in schemaDef.d.ts).


///<reference path="./mongoose.d.ts"/>
///<reference path="./nodeUnit.d.ts"/>
///<reference path="./schemaDef.d.ts"/>

The nodeunit definitions /def/nodeUnit.d.ts

interface ITest{
done(): void;
ok(isGood:Boolean, message?:string):void;
equal(expected:any, actual:any, message?:string);

Here are the basic mongoose definitions in /def/mongoose.d.ts. I can’t guarantee that these types are right, I’m updating them as I go along. I’m inferring the structure from the documentation and personal experimentation. As I encounter new mongoose definitions, I can just add them to the appropriate scope. You can see that I’m also chaining definitions: one definitions functions might return another interface that has … Read more

, ,

Tech talk: Javascript Memory Leaks and JSWhiz

Todays tech talk revolved around the recently published JSWhiz whitepaper from google. The paper discusses common javascript memory leak patterns. It also goes over how those leaks can be created and how google automated detection of them using Closure type annotations.


First Google identified common javascript memory leak patterns, though some of these are described in terms of Closure syntax

  • Create without dispose EventHandler – “Closure objects of type EventHandler provide a simple mechanism to group all events and listeners associated with an object together. This allows for easy removal of listeners when the events being listened to can no longer fire. Unfortunately this is also one of the main sources of leaks
  • Setting member to null without removing event listeners. “In JavaScript setting a variable to null is the idiomatic way of providing a hint to the garbage collector that the memory allocated by an
Read more


Event emitters with success and fail methods for node.js

When it comes to node.js you hear a lot of hype, good and bad, so I’ve finally decided to take the plunge and investigate for myself what the fuss is about. So far it’s been interesting.

I’m not really building anything in particular right now, I’m just playing with different tech stacks to see how things are done. One of the things that I found I liked, while experimenting with node modules, is the syntax success and fail for callback registration. Something like this:

      .success(function() { })
      .fail(function() { });

Using this kind of syntax I wanted to have a basic user authentication forwarder that I could wrap route calls in such that only logged in users could call the route. Non logged in users would automatically be forwarded to a twitter oauth route for auto login (done using everyauth).

The first step was to create a custom … Read more

, ,