Commit 425a97a8 authored by Mike Bostock's avatar Mike Bostock
Browse files

Update CHANGES.

parent 9e2e9946
......@@ -4,15 +4,15 @@ N.B.: This document is a work-in-progress. It does not yet cover all API changes
## Modularity
D3 3.x was a monolithic library: the core functionality resided in a single [repository](https://github.com/d3/d3) and was published in a single file, [d3.v3.js](https://d3js.org/d3.v3.js). It was possible to create a custom build using a nonstandard tool ([SMASH](https://github.com/mbostock/smash)), but not easy. (There were also [plugins](https://github.com/d3/d3-plugins), but these could only add features and had their own monolithic repository.)
D3 3.x was a monolithic library: the core functionality resided in a single [repository](https://github.com/d3/d3) and was published in a [single file](https://d3js.org/d3.v3.js). It was possible to create a custom build using a [nonstandard tool](https://github.com/mbostock/smash), but not easy, and few did. (There were also plugins, but these could only add features, and had their own [monolithic repository](https://github.com/d3/d3-plugins).)
D3 4.0 is modular. Instead of one library, D3 now consists of many [small libraries](https://github.com/d3) that are designed to work together, but don’t have to; you can pick and choose which parts to use as you see fit. Each library is maintained in a separate repository, allowing decentralized ownership and independent release cycles.
D3 4.0 is modular. Instead of one library, D3 now consists of many [small libraries](https://github.com/d3) that are designed to work together, but are not required to; you can pick and choose which parts to use as you see fit. Each library is maintained in a separate repository, allowing decentralized ownership and independent release cycles. Want to own a new repository in the [D3 organization](https://github.com/d3)? Let me know!
The default bundle of D3, [d3.v4.js](https://d3js.org/d3.v4.0.0-alpha.45.js), aggregates about thirty of these small libraries. However, you don’t have to use the default bundle; it is merely provided for convenience. You can load D3 modules separately using vanilla script tags or RequireJS (great for HTTP/2!); you can `cat` them into a custom bundle; you can use an advanced bundler such as Webpack or Rollup to create optimized custom bundles. I recommend Rollup: the D3 microlibraries are written as [ES6 modules](http://www.2ality.com/2014/09/es6-modules-final.html), and Rollup lets you pick at the *symbol* level to produce the smallest bundles! Custom bundles are especially useful for charting libraries that use only a subset of D3’s features; for example, a React charting library might use D3’s scales and shapes, but use React for DOM manipulation instead of selections.
The [default bundle](https://d3js.org/d3.v4.0.0-alpha.45.js) of D3 4.0 aggregates about thirty of these microlibraries. But you don’t have to use the default bundle; it is merely provided for convenience. Custom bundles are especially useful for applications that use only a subset of D3’s features; for example, a React charting library might use D3’s scales and shapes, but use React for DOM manipulation instead of selections. You can load D3 modules separately using vanilla script tags or RequireJS (great for HTTP/2!); you can `cat` them into a custom bundle; you can use a powerful bundler such as [Webpack](https://webpack.github.io/) or [Rollup](http://rollupjs.org/) to create optimized bundles. I recommend Rollup: the D3 microlibraries are written as [ES6 modules](http://www.2ality.com/2014/09/es6-modules-final.html), and Rollup lets you pick at the symbol level to produce the smallest bundles!
But modularity is less about optimizing custom bundles, and more about making D3 *fun* again. Small, standalone modules are easier to understand and test, and make it easier for new people to get involved and contribute. I want to reduce the distinction between a “core module” and a “plugin”, and increase the pace of development in D3 features.
Yet modularity is less about custom bundles and more about making D3 *fun* again. Small, standalone libraries are easier to understand, develop and test. They make it easier for new people to get involved and contribute. I want to reduce the distinction between a “core module” and a “plugin”, and increase the pace of development in D3 features.
If you don’t care about modularity, you can mostly ignore this change and continue to use the default bundle. However, there’s an unavoidable consequence: every symbol in D3 4.0 now shares a flat namespace rather than the somewhat haphazard grouping employed in D3 3.x. For example, d3.scale.linear is now d3.scaleLinear, and d3.layout.treemap is now just d3.treemap. There have also been significant changes (hopefully improvements!) to D3’s functionality. So rather than list all of the renamed symbols, I’ll cover the changes in the corresponding section below.
If you don’t care about modularity, you can mostly ignore this change and keep using the default bundle. However, there’s an unavoidable consequence: every symbol in D3 4.0 now shares a flat namespace rather than the somewhat nesting employed in D3 3.x. For example, d3.scale.linear is now d3.scaleLinear, and d3.layout.treemap is now d3.treemap. There have also been significant changes (hopefully improvements!) to D3’s functionality. Rather than list all the renamed symbols here, I’ll cover the changes in the sections below.
## d3-timer
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment