This commit is contained in:
Mike Bostock 2016-06-08 11:29:53 -07:00
Родитель bdaa388311
Коммит 11f26ea4be
1 изменённых файлов: 2 добавлений и 2 удалений

Просмотреть файл

@ -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 dont 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 D3s features; for example, a React charting library might use D3s 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 dont have to use the default bundle. Custom bundles are useful for applications that use only a subset of D3s features; for example, a React charting library might use D3s 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 dont care about modularity, you can mostly ignore this change and keep using the default bundle. However, theres 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 D3s functionality. Rather than list all the renamed symbols here, Ill cover the changes in the sections below.