Commit 11f26ea4 authored by Mike Bostock's avatar Mike Bostock
Browse files

Update CHANGES.

parent bdaa3883
......@@ -8,9 +8,9 @@ D3 3.x was a monolithic library: the core functionality resided in a single [rep
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](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!
The [default bundle](https://d3js.org/d3.v4.0.0-alpha.45.js) of D3 4.0 conveniently aggregates about thirty of these microlibraries. But you don’t have to use the default bundle. Custom bundles are 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 instead of selections to manipulate the DOM. You can load D3 microlibraries using vanilla script tags or RequireJS (great for HTTP/2!); you can `cat` them into a custom bundle; you can use powerful tools 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!
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.
Small files are nice, but modularity is less about faster load times and more about making D3 *fun* again. Microlibraries 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 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.
......
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