D3 4.0.

[mbostock]

• release notes, D3 4.0 Release Notes #2841
• major releases of modules, Major releases of D3 modules. #2849
• reference index, The API Reference index is slightly out-of-date. #2865
• d3-array
• d3-axis
• d3-brush
• d3-chord
• d3-collection
• d3-color
• d3-dispatch
• d3-drag
• d3-dsv
• d3-ease
• d3-force
• d3-format
• d3-geo
• d3-hierarchy
• d3-interpolate
• d3-path
• d3-polygon
• d3-quadtree
• d3-queue
• d3-random
• d3-request
• d3-scale
• d3-selection
• d3-shape
• d3-time-format
• d3-time
• d3-timer
• d3-transition
• d3-voronoi
• d3-zoom

[colinmegill]

+1 for making the modules as agnostic as possible about SVG / Canvas etc. If the DOM model in general is an implementation detail, the potential scope of the library increases, especially for server side rendering. Easy to imagine using d3.layout.tree() with: https://github.com/Automattic/node-canvas this way. Or with react-native on iOS, as d3.layout.tree() just returns x y pairs and diagonals.

[colinmegill]

Just checked the google results for d3 canvas server and the first three are unanswered SO posts. Also, when our startup needed to support older versions of Android that didn't have SVG, we forked the output and used Raphael to do produce static versions. PITA.

[mbostock]

as agnostic as possible about SVG / Canvas

Yep. Obviously the retained-mode aspects of D3, notably d3-selection and d3-transition, will always require a DOM-like scenegraph. (I say DOM-like because it doesn’t strictly require the DOM: OMG Particles II selects a simple object to store transition state, and DOM-to-Canvas uses custom DOM elements to render to Canvas.) But many other aspects of D3 don’t care about the visual representation, including layouts.

I have a more ambitious plan to develop D3’s geometry pipeline that could allow things like d3.svg.line and d3.svg.area to work with either Canvas or SVG. The geometry pipeline is what currently allows d3.geo to output to either SVG or Canvas, as shown in the World Tour.

This effort may or may not intersect with Path2D, which will hopefully become more widely supported in the future. If it does, it becomes trivial to take D3’s SVG shapes and use their generated path data with Canvas. But, there are still some nice things about having a generic, composable geometry pipeline. See Pencil Sketch for another example.

[colinmegill]

But many other aspects of D3 don’t care about the visual representation, including layouts.

Absolutely... have taken advantage of that with React... see:

• Tree: http://jsbin.com/yiweti/18/edit?html,js,output
• Force: http://jsbin.com/fanofa/14/edit?html,js,output
• Treemap: http://jsbin.com/qoyevo/9/edit?html,js,output

I'm generally excited about this methodology because the SVG is more declarative, and the loops are more explicit. Modular D3 helps this a bunch.

It will have to handle transitions differently, which is what I'm working on now:

gist gif

Currently react-tween-state expects an integer, so I'm extending it for dates, colors, etc.

[colinmegill]

<circle r={this.props.hasChildren ? 3 : 1} /> gives me a lot of joy :)

[mbostock]

Old notes:

• The current d3.locale API might make it awkward to have d3-number-format and d3-time-format in separate modules. Maybe that API should be broken up so that d3.formatNumber is localizable and d3.formatTime is localizable without depending on a shared d3.locale object.
• The names d3.format and d3.time.format aren’t great. Maybe d3.formatNumber and d3.formatDate? More generally, should “time” be renamed “date”?
• The d3-svg module should probably be broken up into separate modules? Also, should it be SVG-specific? Probably we can make it work with Canvas, too. Maybe d3-shapes is a better name? Though note that things like d3.svg.axis will likely remain SVG-specific. And making too many name changes will make migration difficult, so we’ll probably want aliases for anything we rename, anyway.
• The d3.transform class will be removed, though d3.interpolateTransform will still be supported.

[chrisvfritz]

Really looking forward to this! In my visualization projects, D3 is increasingly being used as a layout engine, with everything else handled by React. I know v4 is still a ways out, but is there a timeline for when an alpha version might be available?

[mbostock]

Many of the modules are already available for use: see https://github.com/d3. There’s no explicit timeline for the first “complete” default build of D3 4.0, but my goal is early next year. I expect that the remaining layouts (d3-hierarchy, d3-chord, and the stack layout for d3-shape) will be done this month. I’ll probably tackle d3-force after that.

[chrisvfritz]

Wonderful to hear! I really appreciate your work. I'll start trying out some of the available modules in new projects. Are they at a point where it's useful to open issues or submit PRs if something isn't working quite right?

[sultaniman]

Hi @mbostock when do you plan to rollout d3-brush as a separate module?

Thank you.

[mbostock]

@imanhodjaev It’s probably next after I finish d3-zoom, so it should be in the next two weeks. After that, d3-geo and d3-geo-projection.

[mbostock]

Current status:

[colinmegill]

Woohoo!
On Fri, Jun 24, 2016 at 4:29 PM Mike Bostock notifications@github.com
wrote:

Current status:

[image: image]
https://cloud.githubusercontent.com/assets/230541/16353007/a32cecee-3a28-11e6-9b53-fce8096e9417.png

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#2461 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ABsDGUPTOQYbU6Fn_cGqewb1Bo595LD_ks5qPGhlgaJpZM4E5UB4
.

[mbostock]

(Probably won’t blast off until next week. But we are close!)