The new brush in v4 captures the shift, alt and meta keys to perform some
actions by default. To get around this, I forked d3-brush and modified it
so that it doesn’t capture the shift events. The new version (d3-brush-lite)
can be found on github. There
is an open github issue to
disable this behavior in d3-brush.

Because the d3-drag behavior consumes all events in v4, it is no longer
necessary to stop propagation.

The brush creates its own overlay which catches all events meaning that we
don’t need to turn the zoom behavior off when the shift key is pressed.

Whether a node is fixed is specified by the .fx and .fy parameters. This
eliminates the need to set the .fixed parameter on each node.

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.

Fast ES6 Development Using webpack-dev-server

06 Dec 2016

|

javascript

es6

|

Summary

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.

Details

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:

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:

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.