Empty Pipes

D3v4 event filtering example

  • 18 Apr 2017
  • |
  • javascript
  • d3.js
  • |

D3 behaviors, such as d3.zoom, work by responding to events which pass through the element on which they are called. If the element has children, the behavior will be called as long as the children don’t block events’ propagation. This is often beneficial. If we want to be able to zoom on a populated SVG, we need only call the zoom behavior on the root node and we’ll be able to pan and zoom even if we drag and scroll on the child elements.

There are times, however, when we may want to ignore certain elements without having the block the propagation of the event. For this, there is event filtering. By filtering events, we can let them pass through without having to block or process them. This can be seen in the example below where dragging the background leads to panning, while dragging the circles has no effect.

The crux of the code for this example is a simple check to see that handled events have not passed though an element with a no-zoom class.

var zoom = d3v4.zoom()
    .filter(() => { return !d3v4.event.path[0].classList.contains('no-zoom') })
    .on('zoom', function(d) { g.attr('transform', d3v4.event.transform); });

A bl.ock of this example can be found here.

Fast ES6 Development Using webpack-dev-server

  • 06 Dec 2016
  • |
  • javascript
  • es6
  • |


Switching from gulp and webpack-stream to webpack-dev-server reduces the rebuild time for a 5500-line javascript project from ~11s to ~1.3 seconds.


Whenever I create a javascript project, I do it using a very uniform directory structure and configuration, as outlined in a previous blog post. With this configuration, all the source files are transpiled using babel and bundled using the webpack-stream module as part of a step in the build process managed by gulp.

This is great because then I can run gulp serve and have it recompile and reload the resulting web page whenever I make any changes to the source code in app/scripts.

This works like a charm until the source code and dependencies get to any appreciable size. As more and more files need to be transpiled, the process gets slower and slower until at about ~10 seconds, it starts to get annoying:

[BS] 3 files changed (main.js, playground.js, worker.js)
[08:31:20] Finished 'scripts' after 11 s

So how can this be sped up? Easy, stop using gulp and webpack-stream and switch to the…

Webpack dev server

The webpack dev server runs in its own terminal and watches the source files listed in its config file (webpack.config.js). When one of the files changes, it recreates the output files specified in its config and reloads the web page. I run it using the following command line:

webpack-dev-server --content-base app --display-exclude --profile --inline | grep -v "\\[\\d\*\\]"

The grep at the end is to filter out some of the [overly] verbose output that webpack produces. So how long does it take to regenerate the code when a source file is changed?

Version: webpack 1.12.15
Time: 1296ms
chunk    {0} main.js (main) 4.61 MB

This is about 10x faster than the configuration using gulp and webpack-stream.

The resulting web page can be found at http://localhost:8080/index.html

The only thing I needed to change in my webpack.config.js file was to add output: { publicPath: '/scripts/'}. This is because my index.html file loads the compiled scripts from the scripts directory:

<script src='scripts/playground.js'></script>

Below is the entire webpack.config.js for this project. Notice that there’s multiple different targets being built including a worker script that can be used in a web worker to do compute intensive tasks off of the main UI thread.

Other notable sights include the devtool: "cheap-source-map" entry to make sure we can easily see the source code when debugging.

var path = require('path');
var webpack = require('webpack');

module.exports = {
  context: __dirname + '/app',
  entry: {
      playground: ['./scripts/playground.jsx'],
      main: ['./scripts/main.jsx'],
      worker: ['./scripts/worker.js']
  devtool: "cheap-source-map",
  output: {
    path: __dirname + '/build',
    publicPath: '/scripts/',
    filename: '[name].js',
    libraryTarget: 'umd',
    library: '[name]'
  module: {
    loaders: [
        test: /\.jsx?$/,
        //exclude: /node_modules/,
        include: [path.resolve(__dirname, 'app/scripts')],
        loader: 'babel-loader',
        query: {
          presets: ['es2015', 'react']
      }, {
        test: /\.css$/,
        loader: 'style!css'
    postLoaders: [
            include: path.resolve(__dirname, 'node_modules/pixi.js'),
            loader: 'transform?brfs'
    externals: {

    resolve: {
      extensions: ['.js', '.jsx']

Cambridge Tree Map

  • 16 Nov 2016
  • |
  • javascript
  • d3.js
  • maps
  • |

The city of Cambridge, MA maintains a wealth of geographic information on its GIS website. One of the more unconvential datasets is the list of trees lining the streets of the city. It contains the position and species of around 30 thousand trees and can be explored using the Cambridge Tree Walk) application. While this app is incredily detailed and useful at high resolution, it loses all information at low resolution. The identities and positions of the trees are lost. And if they weren’t they would be too dense to display in a meaningful and intelligible manner.

To provide a different view, I calculated which tree species is most common on each block in Cambridge and plotted the results using D3.js. The analysis shows that Maple trees dominate the landscape in Cambridge. Further down the list are Oaks, Lindens and Pears. While these are the most common trees on most street blocks in Cambridge, there are a few which are dominated by less common species. This isn’t to say that those species are only found on those blocks, just that those are the only blocks where those species are in the majority.

How useful is this map? I don’t know. But it was fun to make and will hopefully serve as a decent example for introducing how D3.js can be used for cartography at Maptime Boston. A tutorial describing how this map is made is available on the GitHub page for the project. It’s also avilable as a block.