Introducing Loupe

Today, I am introducing a brand new data visualization library called Loupe. Although It is small, only 12K minified 4K gzipped, it still has lots of power! It is capable of data transformations, animations, complex visualizations, etc. It will work on any modern browser and because of its small size is perfect for mobile development.

A little more about data transformations. The basic premise is that you tell loupe what shapes you want to draw, then you provide it with a set of data, and finally tell it how you want to transform the data and the shapes. You can specify which fields on the shape should be transformed (and or animated) as well as define static properties. Loupe has an expressive and declarative api.

Loupe is extensible and built for plugins. I have already provided two plugins, one for drawing pie charts and one for drawing area charts.

Loupe is still in alpha so there are likely to be bugs especially while I build up the test suite. But it will soon enter beta (by sometime in October).

Enough talk here are some pictures (click on the pictures to see the live examples).

Screen Shot 2013-09-20 at 7.39.14 AM Screen Shot 2013-09-20 at 7.39.08 AM Screen Shot 2013-09-20 at 7.39.01 AM Screen Shot 2013-09-20 at 7.38.54 AM

 

 

Peppy Version 2.0.0-beta

Well its been over four years since I initially released Peppy. Today, I am releasing a new version of Peppy which has been completely rewritten from the ground up.

When I look at the selector engine landscape today I see a lot of fast and high quality solutions: NWMatcher, Sizzle, Slick, Sly, DomQuery, DomAssistant, Acme just to name a few. Why bother rewriting Peppy at this point you might ask? Well my main motivations are:

  1. For fun
  2. To provide a readable reference for effective DOM traversal

I’d like to speak more to number two. Of course this is my opinion, but I find it very difficult to reverse engineer these existing selector engines. They all pretty much make use of large and complicated regular expressions to do the selector parsing, and have made choices like pre-compiled code paths or not straight forward selector tests in the name of optimization.

First let me say that I believe this to be a good thing and I am glad that there are selector engines out there that care about optimization. I also believe that these bodies of work are offering great resources to the community with regard to this.

For this most recent version of Peppy I chose different tenants to follow. Peppy is no longer as fast or faster than the other selector engines. In fact it is slower. But it still retrieves its results in milliseconds. So for me and for most practical applications this is fast enough. It is readable and of high quality. These were my goals.

Peppy no longer uses large regular expressions for parsing selector strings. It now uses a selector parser that I wrote called LLSelectorParser. This is a top down parser that returns an abstract syntax tree. Peppy internally now works off of this tree.

There is still more work to do. Right now Peppy follows the “Native-First, Dual Approach” for working with querySelectorAll. This is less than ideal and will be changed. However, my goal for this first release was to get the actual selector engine out there to the community and to not be as concerned with querySelectorAll bugs or inconsistencies.

I am proud of the new version of Peppy. If you have time please go check it out and let me know what you think.

 

Scoping AngularJS Directives Part 2

This is part 2 in a series on scoping directives with AngularJS. In this post I am going to cover how the three different scoping techniques affect each other when multiple directives are applied to one element.

To begin lets review the three directive scoping techniques available through AngularJS:

  1. inherit scope from the nearest controller scope [default]
  2. create a new scope that is prototypically inherited from the nearest controller scope [scope: true]
  3. create an isolated scope that only has access to the nearest controller scope via parameters or the $parent property. [scope: {}]

First, lets take a look at the first two together (inherited scope and new scope):

You will notice that independently they behave as described above in the list. However, when both are applied to the same element, regardless of order, they have the same scope which is the scope type 2 (new scope).

Next, lets take a look at the first and last together (inherited and isolated scope):

You will notice that independently they behave once again as described above in the list. However, when both are applied to the same element, regardless of order, they have the same scope which is the scope type 3 (isolated scope). This is the most important combination to understand as you other directives may be expecting either direct or prototypical access to the nearest controller scope, but when paired with an isolated scope directive they no longer have this access. This can lead to many unexpected errors. In my opinion isolated scopes should be used only very judiciously and with exact intention understanding this behavior.

Finally, when you apply scope type 2 and scope type 3 together (new scope and isolated scope) you get an error. It won’t allow that combination.

In the next part of this series  (part 3) we are going to examine how transclusion affects directive scoping.

Scoping AngularJS Directives Part 1

AngularJS directive scoping confuses a lot of people. I thought I would take a moment and attempt to defuse some of the confusion. First I encourage you to visit the AngularJS developer guide on directives: http://docs.angularjs.org/guide/directive.

To simplify you should know that there are only three types of scoping with directives:

  1. inherit scope from the nearest controller scope [default]
  2. create a new scope that is prototypically inherited from the nearest controller scope [scope: true]
  3. create an isolated scope that only has access to the nearest controller scope via parameters or the $parent property. [scope: {}]

First, lets take a looksy at scope type 1: inherited scope.

You can see that we have direct access to $scope.property which is created within the nearest controllers scope.

Next, lets take a look at scope type 2: new child scope

You can see that we have access to $scope.property via the prototype chain.

Finally, lets take a look at scope type 3: isolated scope

You can see that we only have access to $scope.property via properties in the isolated scopes object literal definition as well as through the scopes $parent property.

This is part one in a series on AngularJS scoping. In part two we will examine how these three scoping types interact when you have multiple directives on the same element.