Empty Pipes

Selectable zoomable force directed graph in D3v4

  • 29 Apr 2017
  • |
  • javascript
  • d3.js
  • d3v4.js
  • |

A previous post described how to use d3.js to create a force-directed graph we can zoom in to and select nodes from. Such a tool is useful for displaying and arranging larger networks. My colleagues and I personally used it to create a small web application for displaying RNA secondary structure.

Since that post, a new version of D3 was released. D3 V4 introduced a lot of useful new features (see Irene Ros’s excellent overview of the differences between v3 and v4). Unfortunately, however, it did not maintain backward compatiblity with previous versions of d3. This means that the previous selectable zoomable force directed graph example could not be used with new code written with the latest version of the D3 library. Until now.

As in the previous example, this graph provides the following selection behavior:

  1. Clicking on a node selects it and de-selects everything else.
  2. Shift-clicking on a node toggles its selection status and leaves all other nodes as they are.
  3. Shift-dragging toggles the selection status of all nodes within the selection area.
  4. Dragging on a selected node drags all selected nodes.
  5. Dragging an unselected node selects and drags it while de-selecting everything else.

Upgrading the selectable zoomable force directed graph implementation to D3 v4 required a few minor and not-so-minor changes.

  "nodes": [
    {"id": "Myriel", "group": 1},
    {"id": "Napoleon", "group": 1},
    {"id": "Mlle.Baptistine", "group": 1},
  "links": [
    {"source": "Napoleon", "target": "Myriel", "value": 1},
    {"source": "Mlle.Baptistine", "target": "Myriel", "value": 8},

The source code for this example can be found as a github gist or on bl.ocks.org.

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']