9 ms·

D3 v4.0.0 released

438 points by aw3c2 10y ago

a_humean 10y ago
Changelog (weekend reading): https://github.com/d3/d3/blob/master/CHANGES.md https://github.com/d3/d3/blob/master/CHANGES.md Really excited about this release. It seems like nothing has been left untouched with major changes to everything from selections to layout generations and the modularisation of the entire lib (think lodash). There are major namespace changes with basically everything being flattened ( d3.geom.voronoi -> d3.voronoi) and many of the typical patterns will have to be relearned (major changes to selections), so I don't see upgrading any existing projects and I may have to hold off on using 4.0 in new projects until I actually understand what has happened. Favourite thing so far has to be the changes to selections, which I think will make things a lot clearer to newer users: https://github.com/d3/d3/blob/master/CHANGES.md#selections-d3-selection https://github.com/d3/d3/blob/master/CHANGES.md#selections-d...
- mbostock 10y ago
  Aye, a lot has changed! I know change in itself is a pain; despite the quantity of changes I did try to avoid unnecessary change, and batch the changes into a rare major release. I believe such change is worthwhile, and that it’s better in the long run to keep improving the API than to be tied down to past mistakes. The renames (like d3.voronoi instead of d3.geom.voronoi) are superficial changes, so although it might seem disruptive, it should be pretty easy to update your code and habits. At least, I haven’t found it difficult… The more design-y changes, like the new d3.stack and d3.treemap, require thought to migrate existing code. But the new designs are much better, so I hope you find the effort worthwhile.
  - zellyn 10y ago
    I know Perl6 and Python3 have shown the dangers of changing things in disruptive ways. But I still appreciate your willingness to change things carefully to make them better. The length of time your software will be used in the future almost certainly outweighs the length of time it was used in the past :-)
    - mbostock 10y ago
      I thought about the Python 2/3 debacle a lot this past year, and yes, I hope this isn’t a repeat. The Python migration was especially hard because of dependencies between libraries (you could only migrate your library or application to Python 3 after your dependencies migrated), and because Python is used for many large, long-term projects. Certainly D3, too, has its own plugin ecosystem and long-term projects, but it’s also commonly used as a standalone library in short-term work, such as in news graphics—where migration should be much easier. So hopefully that pain is lessened.
  - tomgp 10y ago
    Excellent work! I've been using bits and pieces of this since the start of the year and can attest to the fact that migration from 3 is relatively painless.
  - a_humean 10y ago
    I think it is certainly worthwhile, and I've already used one of your new features in the d3-hierarchy package (d3.stratify) in a d3 v3 project. I think the general improvements are enough to warrant the breaking changes. I think you will see a brief period of a python 2/3 syndrome, but I think it will pass quickly. Thank you for working so hard on this Mike!
betageek 10y ago
Looks like quite a lot to take in, where should we start? - are there updated tutorials, upgrade guide etc?
- mbostock 10y ago
  The place to start is the release notes: https://github.com/d3/d3/releases/tag/v4.0.0 https://github.com/d3/d3/releases/tag/v4.0.0 And the detailed change list: https://github.com/d3/d3/blob/master/CHANGES.md https://github.com/d3/d3/blob/master/CHANGES.md I will update my tutorials and examples (and probably write new tutorials) in the near future, and I expect others will, too. But as I now have thousands of examples, I didn’t want to hold the release on updating all of them. My newer examples use 4.0 already, and I’ll be going through the others in the coming weeks.
  - enjalot 10y ago
    Does this mean you intend to update your existing examples in place? It might be nice if you forked them with v4 instead to create a defacto upgrade guide. I know many tutorials reference your examples and it might create more confusion if they are updated in place. I suppose it depends on how much you want to keep supporting v3, but I'd argue its worth keeping the old knowledge base intact for a while.
    - mbostock 10y ago
      Yep, I’m going to update my examples in-place. Consider it my heavy-handed encouragement to upgrade to 4.0. (For one thing, there are lot of 3.x bugs fixed in 4.0, and I have limited resources to provide free support to old versions.) My examples are backed by git repos, so you’ll still be able to find the 3.x versions if you need them.
      - enjalot 10y ago
        fair enough!
rusosnith 10y ago
Is it possible to have V3 and V4 coexisting in a project? Like, adding some of the awesome v4 new things to an already working v3 project without having to rework all the v3 code to v4 compliance? I've tried doing this with v4 beta, with strange behaviours :)
- a_humean 10y ago
  I think it is quite possible in some cases due to the modularisation. I have already done that with in my D3 v3 projects. For example I used the d3.stratify method that is part of the d3-hierarchy module.
- mbostock 10y ago
  Hmm. It might be possible, though it doesn’t sound like a great idea to have both D3 3.x and the D3 4.0 default bundle loaded simultaneously, since there will be a lot of overlap. A better strategy might be to load just the new modules you want to use. Like if you just want the new force layout, then load d3-force: https://github.com/d3/d3-force https://github.com/d3/d3-force But it might be best to just migrate to 4.0. I know the changelist is long, but it might not be as hard as you think to migrate. And you can always send your questions to the d3-js Google group or d3.js on Stack Overflow and I’ll try to help.
  - chrisprice 10y ago
    On a project I work on* we've found that this technique has worked well so far. We're slowly moving from v3 to v4 by splitting out groups of components into their own packages and upgrading them as we go. We've been heavily inspired by d3's approach e.g. with the use of rollup for bundling. We're probably at about 60% of the library upgraded/split-out but we've yet to tackle the more tricky changes like d3-selection. * https://github.com/d3fc https://github.com/d3fc
dswalter 10y ago
Modularization aside (and it's terrific to have in the library), what additional functionality are you most excited about with this release?
- mbostock 10y ago
  Let’s see, in no particular order… * New pretty continuous color schemes (viridis, rainbow, ColorBrewer) * New axes that are easier to use. * Vastly improved circle-packing layout. * More stable, extensible force layout. * Cleaner implementation of immutable selections & transitions. And a ton of other stuff. Taken overall, it feels like a big step forward in robustness and cleanliness. And I’m hopeful that it’ll be easier for folks to develop more D3 modules.
jonahx 10y ago
Just want to say how much I appreciate the refactoring into smaller libraries. d3 has enough traction that it's not something they had to do, but it's the right thing to do, and probably took a good deal of effort and thinking.
- mbostock 10y ago
  Thanks. It’s definitely more fun to work on the pieces of D3 individually, rather than feeling the weight of a massive monolith. Hopefully it will encourage others to develop more reusable libraries that depend on (the relevant parts of) D3, too.
  - cprayingmantis 10y ago
    Just wanted to say that your work is very much appreciated. I've been using D3 since it was Protovis and I love it. Excited to dig into the changes and try it out.
nthitz 10y ago
More comments here https://news.ycombinator.com/item?id=11994410 https://news.ycombinator.com/item?id=11994410 including from @mbostock. Not sure why it didn't stay on FP.
- sctb 10y ago
  Thanks, we've merged that thread with this one.
iyn 10y ago
What's the best way to integrate D3 and react? Or there's a better approach to charts/visualization in react than using D3?
- mbostock 10y ago
  I don’t know about the “best” way, but there are quite a few ways people have explored so far; Google [d3 react] for starters… D3 4.0 introduces a new option which is to use the D3 minilibraries d3-scale, d3-shape, d3-hierarchy etc. without d3-selection, so that you manipulate the DOM exclusively through React. (Of course I’m biased and still recommend D3’s data-join and transitions for animating between views, but now there’s more flexibility.)
  - krebby 10y ago
    I agree, though I've found that the animation story with React for anything even mildly complex is still pretty terrible. My day job is building big data visualization applications with lots of D3 and React, so I have a lot of opinions about this. If you can get away with using CSS transitions or react-motion in your app, and you don't need D3's enter-update-exit selections, I feel React's declarative syntax is a much simpler mental model and is consistent with how the rest of my app works. But anything complex you'll need to drop out of React and build your DOM in D3, which has a very different notion of element lifecycles than React and doesn't allow you to reuse any of your other React components.
- segphault 10y ago
  D3 is a relatively low-level library for composing custom visualizations. There are some good high-level abstractions on top that integrate well with React and provide specific kinds of preconfigured charts. You might want to check out Uber's React Vis components: https://github.com/uber/react-vis https://github.com/uber/react-vis
- saidajigumi 10y ago
  You'll probably want to use D3 to build a React component. The component provides the API to the rest of your application, while D3 takes over dataviz heavy lifting inside the component. The most interesting aspect, which applies to apps beyond React, is likely to be respecting the D3 selections API[1], if needed. If you're already familiar with the ins and outs of selections, then I wouldn't expect any particular problems. [1] https://github.com/d3/d3/blob/master/API.md#selections-d3-selection https://github.com/d3/d3/blob/master/API.md#selections-d3-se...
yoavm 10y ago
D3 has the reputation of being super-complicated because of all the libraries that are based on it, "simplifying" it so that everyone can use it. In the past year I wanted to create pretty unique type of data visualisation, so I dived into D3 and discovered it a makes a lot more sense than I though. Of course, if you only want a regular bar chart, you'll do better with things like C3, nvd3 etc'. But if you want anything a bit special, D3 itself is very powerful and the documentation in pretty good - there's no reason to avoid using it directly. Definitely looking forward to try the new release.
- minimaxir 10y ago
  To add to that, if you are a complete newbie to any data visualization, do not start with d3. If you want to make pretty charts programatically, using R/ggplot2 or Python/Seaborn is good enough. Even Excel is fine if you tweak the defaults. D3 is good if your visualization benefits from interactivity, either with dynamic data adjustment or rich tooltips. But static visualizations are important too. (I recently restructured my workflow so I can output static images and interactive charts with the same code, which makes it the best of both worlds.)
  - danso 10y ago
    What is your static+interactive workflow now, if I can ask? Also, is it fairly easy to build a workflow that generates static visualizations via D3 (i.e. making savable SVGs)?
    - minimaxir 10y ago
      I make charts with R/ggplot2. Standard workflow is to construct chart and save as static file. (PNG/SVG etc.) But with the plot.ly bridge, I can convert to an interactive chart w/ rich tooltips with very very little tweaking. (See this notebook: https://github.com/minimaxir/interactive-facebook-reactions/blob/master/facebook_reactions_classification.ipynb https://github.com/minimaxir/interactive-facebook-reactions/...) To convert D3 to SVG, I believe all you need is a helper function but that is not my area of expertise.
deleted 10y ago
[deleted]
dmix 10y ago
Any 4.0 tutorials available yet to dive in and try it out for a first-timer?
- gkst 10y ago
  Many of mbostock's recent "blocks" use D3 v4 http://bl.ocks.org/mbostock http://bl.ocks.org/mbostock These are not tutorials, but working examples with some introductory texts. They are very helpful for diving into D3.
gkst 10y ago
Exciting release! I played with the force layout on canvas to graph reddit conversations http://ramiro.org/tool/graphit/ http://ramiro.org/tool/graphit/ It's harder to get interaction done with canvas compared to SVG, but for large graphs the performance gains are huge. Curious to dive into the other new features. Thanks for this incredible piece of software mbostock!
th0ma5 10y ago
Did they remove the emphasis n the .enter() pattern yet? This is the weirdest thing compared to how just about every other library works, and it can totally be avoided by just using the data() stuff directly.
blaze33 10y ago
Does anyone know if there is a good way to do server-side rendering (svg files) of D3 charts while being able to reuse the same code in a browser? We do a lot of charts at work to visualize electricity consumption and are currently thinking about how to rewrite the js we've accumulated over the years. I've found some attempts at doing server-side rendering but nothing really compelling for now... D3 is a well thought out library to do interactive visualizations in the browser and having an easy way to do svg exports (for things like automated emails) would be a big plus. Doing screenshots through selenium ain't always so pleasant ;)
- m0j0l 10y ago
  Not sure if it fits your use case, but; for one project I needed to have charts that the user could modify in their browser, and once they were happy they could hit 'download PDF' to get a PDF version. Achieved this by (admittedly slightly clunky way) of sucking the SVG out of the chart and sending it to the server via ajax. Server intercepts SVG and passes it to inkscape which does pretty good command line svg -> pdf... then, sends back completed PDF. One gotcha is that you won't get any CSS this way, so all styling has to be done via SVG props.
  - e1g 10y ago
    That's exactly what we are doing but running the SVG code through Apache Batik Rasterizer to turn it into png. I like this approach because the user can customise the chart in the front end and then the same resulting svg code is rendered by the backend. The only issue is styling as you mentioned.
  - Frencil 10y ago
    > One gotcha is that you won't get any CSS this way, so all styling has to be done via SVG props. There actually is a way to bake stylesheets directly into the SVG in a way that at least Inkscape can read, but it's tricky. We're successfully doing this in a graphing library tuned for genetic data that's built on top of d3 called LocusZoom. The first step is to get the content of the stylesheet into a string. We do that here with a CORS request in case the stylesheet is being loaded over a CDN, as javascript won't be able to access the content of CDN-loaded stylesheets from document.styleSheets: https://github.com/statgen/locuszoom/blob/v0.4.0/assets/js/app/Instance.js#L808 https://github.com/statgen/locuszoom/blob/v0.4.0/assets/js/a... Since the stylesheet doesn't change once the page is loaded this only needs to happen once. From there, in our case, we have a dynamic/interactive SVG plot so the download needs to bundle up the current state of the SVG on request. Here's the method that does that: https://github.com/statgen/locuszoom/blob/v0.4.0/assets/js/app/Instance.js#L783 https://github.com/statgen/locuszoom/blob/v0.4.0/assets/js/a... Other than what no doubt looks familiar for pulling the raw SVG markup into a string we also insert a tag right after the opening <svg> tag that looks like this: "<style type=\"text/css\"><![CDATA[ " + this.css_string + " ]]></style>" Where this.css_string is our stylesheet content. We then base64 encode the string and stick in the href of an <a> tag styled to look like a download button as seen here: https://github.com/statgen/locuszoom/blob/v0.4.0/assets/js/app/Instance.js#L748 https://github.com/statgen/locuszoom/blob/v0.4.0/assets/js/a... The end result is a download SVG link/button that is 100% client-side with our chosen stylesheet embedded. Now, I have noticed that some styles defined in the stylesheet are valid in the browser but fail in InkScape and other SVG viewers. A prime example would be setting a stroke or fill to "transparent". InkScape doesn't interpret this properly and you can end up with solid black, just about the exact opposite of transparent. Keeping this in mind I stick to defining explicit "fill-opacity" and "stroke-opacity" values in the stylesheet for SVG elements and everything plays nice. A working demo of this can be seen here: http://statgen.github.io/locuszoom/plot_builder.html http://statgen.github.io/locuszoom/plot_builder.html
monfera 10y ago
Fantastic work! D3 has a large API surface area, due to the functionality it covers. So even a relatively conservative major upgrade is a TON of work, and some of it might not have been pure fun only. 1) What's your opinion on the apparent case that the bulk of changes come from you, as society promotes teamwork so much? Is it a case of 'small team efficency'? (Btw. I know of others' contributions too, and reliance on Rollup, ColorBrewer, matplotlib/Viridis etc.) 2) What kept you going? It's probably at least a person-year of work just on your side that's not paid for by companies, not to mention some kind of startup bet. Have you alternatively toyed with the idea of starting a value-added layer, since so many for-profit organizations benefit from your work? 3) While it changes the API, and most everything is rewritten, it's IMO a conservative upgrade in that it doesn't steer away from familiar concepts and structure. It still does DOM binding, transitions, layout etc. fairly similarly. Have you considered much more disruptive departures? As an example, React's DOM diffing is more radically different from D3 selections than the change from D3 3.* to 4.* or the Grammar of Graphics as an API concept is more radically different from D3 than the 3.* -> 4.0 API changes. Or something like moving away from the 'functional objects' concept in favor of curried, fixed-argument pure functions, perhaps prefaced with the familiar chaining API would have been a large change (these are mostly examples rather than wishlist). What were YOUR ideas, had you wanted more disruptive changes, or 'D4'?
- smrtinsert 10y ago
  IIRC a key point of d3 was to not be declarative, like the gog. That was more an influence in protoviz, its precursor. You might be interested in Vega and Vega lite if you want to go declarative.
  - monfera 10y ago
    I'm contributing to plotly.js right now, which is also declarative, and I see the pros and cons of levels of denotative semantics (mostly depends on goals and library user requirements) but it was just an example for what I mean by more radical changes. Good you mentioned it anyway, protovis -> D3 also represented a rather disruptive change. But perhaps I was late with these questions for this specific AMA.
deleted 10y ago
[deleted]
toothrot 10y ago
Why didn't they name it D4
- colejohnson66 10y ago
  Because D3 is the actual name of the library. The full name is "Data-Driven Documents v4.0.0". Shorten that and you get "D3 v4.0.0".
  - 8note 10y ago
    and there's a derivatived library called D4 as well
    - mrits 10y ago
      Derivatived Data Driven Documents?
dnprock 10y ago
For those interested making d3.js reusable for data analysis, check out https://vida.io https://vida.io. We create templates out of d3.js visualizations with dynamic properties. You can create dashboards from custom d3.js components. For more examples, see https://vida.io/explore https://vida.io/explore.
sntran 10y ago
For simpler need such as rendering a SVG map from Topojson or GeoJSON data, is there an alternative than D3 that can utilize React.js' rendering of SVG? With no animation, no charts, just map with zoom in and out and drag around, is there a benefit of using D3?
con_ssc 10y ago
1. Are there any plans to have a TypeScript version of the lib? 2. Would it be possible to add jsdoc comments for autocompletion? 3. Are the polyfills for Map and Set still necessary now that we have that in es2015? 4. Why is the lib so heavy on argument overloads? 5. Are there any code style restrictions? I often saw loops and conditions without curly brackets and alike. 6. Are there any fields you'd need support in for maintaining or reworking the library? I really like D3.js although I haven't found an application for me yet. I find it hard to get/update the date from a none standard REST endpoint and display them, especially if they are kind of multichanneled, like working times of multiple users unordered.
deleted 10y ago
[deleted]
dasdas1111 10y ago
dsadsds
onesquared 10y ago
The d3.transform method has been removed. But have you a similar function in d3js v4.0.0 ?

438 points by aw3c2 10y ago

Changelog (weekend reading): https://github.com/d3/d3/blob/master/CHANGES.md https://github.com/d3/d3/blob/master/CHANGES.md Really excited about this release. It seems like nothing has been left untouched with major changes to everything from selections to layout generations and the modularisation of the entire lib (think lodash). There are major namespace changes with basically everything being flattened ( d3.geom.voronoi -> d3.voronoi) and many of the typical patterns will have to be relearned (major changes to selections), so I don't see upgrading any existing projects and I may have to hold off on using 4.0 in new projects until I actually understand what has happened. Favourite thing so far has to be the changes to selections, which I think will make things a lot clearer to newer users: https://github.com/d3/d3/blob/master/CHANGES.md#selections-d3-selection https://github.com/d3/d3/blob/master/CHANGES.md#selections-d...

mbostock 10y ago
Aye, a lot has changed! I know change in itself is a pain; despite the quantity of changes I did try to avoid unnecessary change, and batch the changes into a rare major release. I believe such change is worthwhile, and that it’s better in the long run to keep improving the API than to be tied down to past mistakes. The renames (like d3.voronoi instead of d3.geom.voronoi) are superficial changes, so although it might seem disruptive, it should be pretty easy to update your code and habits. At least, I haven’t found it difficult… The more design-y changes, like the new d3.stack and d3.treemap, require thought to migrate existing code. But the new designs are much better, so I hope you find the effort worthwhile.
- zellyn 10y ago
  I know Perl6 and Python3 have shown the dangers of changing things in disruptive ways. But I still appreciate your willingness to change things carefully to make them better. The length of time your software will be used in the future almost certainly outweighs the length of time it was used in the past :-)
  - mbostock 10y ago
    I thought about the Python 2/3 debacle a lot this past year, and yes, I hope this isn’t a repeat. The Python migration was especially hard because of dependencies between libraries (you could only migrate your library or application to Python 3 after your dependencies migrated), and because Python is used for many large, long-term projects. Certainly D3, too, has its own plugin ecosystem and long-term projects, but it’s also commonly used as a standalone library in short-term work, such as in news graphics—where migration should be much easier. So hopefully that pain is lessened.
- tomgp 10y ago
  Excellent work! I've been using bits and pieces of this since the start of the year and can attest to the fact that migration from 3 is relatively painless.
- a_humean 10y ago
  I think it is certainly worthwhile, and I've already used one of your new features in the d3-hierarchy package (d3.stratify) in a d3 v3 project. I think the general improvements are enough to warrant the breaking changes. I think you will see a brief period of a python 2/3 syndrome, but I think it will pass quickly. Thank you for working so hard on this Mike!

betageek 10y ago

Looks like quite a lot to take in, where should we start? - are there updated tutorials, upgrade guide etc?

mbostock 10y ago
The place to start is the release notes: https://github.com/d3/d3/releases/tag/v4.0.0 https://github.com/d3/d3/releases/tag/v4.0.0 And the detailed change list: https://github.com/d3/d3/blob/master/CHANGES.md https://github.com/d3/d3/blob/master/CHANGES.md I will update my tutorials and examples (and probably write new tutorials) in the near future, and I expect others will, too. But as I now have thousands of examples, I didn’t want to hold the release on updating all of them. My newer examples use 4.0 already, and I’ll be going through the others in the coming weeks.
- enjalot 10y ago
  Does this mean you intend to update your existing examples in place? It might be nice if you forked them with v4 instead to create a defacto upgrade guide. I know many tutorials reference your examples and it might create more confusion if they are updated in place. I suppose it depends on how much you want to keep supporting v3, but I'd argue its worth keeping the old knowledge base intact for a while.
  - mbostock 10y ago
    Yep, I’m going to update my examples in-place. Consider it my heavy-handed encouragement to upgrade to 4.0. (For one thing, there are lot of 3.x bugs fixed in 4.0, and I have limited resources to provide free support to old versions.) My examples are backed by git repos, so you’ll still be able to find the 3.x versions if you need them.
    - enjalot 10y ago
      fair enough!

rusosnith 10y ago

Is it possible to have V3 and V4 coexisting in a project? Like, adding some of the awesome v4 new things to an already working v3 project without having to rework all the v3 code to v4 compliance? I've tried doing this with v4 beta, with strange behaviours :)

a_humean 10y ago
I think it is quite possible in some cases due to the modularisation. I have already done that with in my D3 v3 projects. For example I used the d3.stratify method that is part of the d3-hierarchy module.
mbostock 10y ago
Hmm. It might be possible, though it doesn’t sound like a great idea to have both D3 3.x and the D3 4.0 default bundle loaded simultaneously, since there will be a lot of overlap. A better strategy might be to load just the new modules you want to use. Like if you just want the new force layout, then load d3-force: https://github.com/d3/d3-force https://github.com/d3/d3-force But it might be best to just migrate to 4.0. I know the changelist is long, but it might not be as hard as you think to migrate. And you can always send your questions to the d3-js Google group or d3.js on Stack Overflow and I’ll try to help.
- chrisprice 10y ago
  On a project I work on* we've found that this technique has worked well so far. We're slowly moving from v3 to v4 by splitting out groups of components into their own packages and upgrading them as we go. We've been heavily inspired by d3's approach e.g. with the use of rollup for bundling. We're probably at about 60% of the library upgraded/split-out but we've yet to tackle the more tricky changes like d3-selection. * https://github.com/d3fc https://github.com/d3fc

dswalter 10y ago

Modularization aside (and it's terrific to have in the library), what additional functionality are you most excited about with this release?

mbostock 10y ago
Let’s see, in no particular order… * New pretty continuous color schemes (viridis, rainbow, ColorBrewer) * New axes that are easier to use. * Vastly improved circle-packing layout. * More stable, extensible force layout. * Cleaner implementation of immutable selections & transitions. And a ton of other stuff. Taken overall, it feels like a big step forward in robustness and cleanliness. And I’m hopeful that it’ll be easier for folks to develop more D3 modules.

jonahx 10y ago

Just want to say how much I appreciate the refactoring into smaller libraries. d3 has enough traction that it's not something they had to do, but it's the right thing to do, and probably took a good deal of effort and thinking.

mbostock 10y ago
Thanks. It’s definitely more fun to work on the pieces of D3 individually, rather than feeling the weight of a massive monolith. Hopefully it will encourage others to develop more reusable libraries that depend on (the relevant parts of) D3, too.
- cprayingmantis 10y ago
  Just wanted to say that your work is very much appreciated. I've been using D3 since it was Protovis and I love it. Excited to dig into the changes and try it out.

nthitz 10y ago

More comments here https://news.ycombinator.com/item?id=11994410 https://news.ycombinator.com/item?id=11994410 including from @mbostock. Not sure why it didn't stay on FP.

sctb 10y ago
Thanks, we've merged that thread with this one.

iyn 10y ago

What's the best way to integrate D3 and react? Or there's a better approach to charts/visualization in react than using D3?

mbostock 10y ago
I don’t know about the “best” way, but there are quite a few ways people have explored so far; Google [d3 react] for starters… D3 4.0 introduces a new option which is to use the D3 minilibraries d3-scale, d3-shape, d3-hierarchy etc. without d3-selection, so that you manipulate the DOM exclusively through React. (Of course I’m biased and still recommend D3’s data-join and transitions for animating between views, but now there’s more flexibility.)
- krebby 10y ago
  I agree, though I've found that the animation story with React for anything even mildly complex is still pretty terrible. My day job is building big data visualization applications with lots of D3 and React, so I have a lot of opinions about this. If you can get away with using CSS transitions or react-motion in your app, and you don't need D3's enter-update-exit selections, I feel React's declarative syntax is a much simpler mental model and is consistent with how the rest of my app works. But anything complex you'll need to drop out of React and build your DOM in D3, which has a very different notion of element lifecycles than React and doesn't allow you to reuse any of your other React components.
segphault 10y ago
D3 is a relatively low-level library for composing custom visualizations. There are some good high-level abstractions on top that integrate well with React and provide specific kinds of preconfigured charts. You might want to check out Uber's React Vis components: https://github.com/uber/react-vis https://github.com/uber/react-vis
saidajigumi 10y ago
You'll probably want to use D3 to build a React component. The component provides the API to the rest of your application, while D3 takes over dataviz heavy lifting inside the component. The most interesting aspect, which applies to apps beyond React, is likely to be respecting the D3 selections API[1], if needed. If you're already familiar with the ins and outs of selections, then I wouldn't expect any particular problems. [1] https://github.com/d3/d3/blob/master/API.md#selections-d3-selection https://github.com/d3/d3/blob/master/API.md#selections-d3-se...

yoavm 10y ago

D3 has the reputation of being super-complicated because of all the libraries that are based on it, "simplifying" it so that everyone can use it. In the past year I wanted to create pretty unique type of data visualisation, so I dived into D3 and discovered it a makes a lot more sense than I though. Of course, if you only want a regular bar chart, you'll do better with things like C3, nvd3 etc'. But if you want anything a bit special, D3 itself is very powerful and the documentation in pretty good - there's no reason to avoid using it directly. Definitely looking forward to try the new release.

minimaxir 10y ago
To add to that, if you are a complete newbie to any data visualization, do not start with d3. If you want to make pretty charts programatically, using R/ggplot2 or Python/Seaborn is good enough. Even Excel is fine if you tweak the defaults. D3 is good if your visualization benefits from interactivity, either with dynamic data adjustment or rich tooltips. But static visualizations are important too. (I recently restructured my workflow so I can output static images and interactive charts with the same code, which makes it the best of both worlds.)
- danso 10y ago
  What is your static+interactive workflow now, if I can ask? Also, is it fairly easy to build a workflow that generates static visualizations via D3 (i.e. making savable SVGs)?
  - minimaxir 10y ago
    I make charts with R/ggplot2. Standard workflow is to construct chart and save as static file. (PNG/SVG etc.) But with the plot.ly bridge, I can convert to an interactive chart w/ rich tooltips with very very little tweaking. (See this notebook: https://github.com/minimaxir/interactive-facebook-reactions/blob/master/facebook_reactions_classification.ipynb https://github.com/minimaxir/interactive-facebook-reactions/...) To convert D3 to SVG, I believe all you need is a helper function but that is not my area of expertise.

deleted 10y ago

[deleted]

dmix 10y ago

Any 4.0 tutorials available yet to dive in and try it out for a first-timer?

gkst 10y ago
Many of mbostock's recent "blocks" use D3 v4 http://bl.ocks.org/mbostock http://bl.ocks.org/mbostock These are not tutorials, but working examples with some introductory texts. They are very helpful for diving into D3.

gkst 10y ago

Exciting release! I played with the force layout on canvas to graph reddit conversations http://ramiro.org/tool/graphit/ http://ramiro.org/tool/graphit/ It's harder to get interaction done with canvas compared to SVG, but for large graphs the performance gains are huge. Curious to dive into the other new features. Thanks for this incredible piece of software mbostock!

th0ma5 10y ago

Did they remove the emphasis n the .enter() pattern yet? This is the weirdest thing compared to how just about every other library works, and it can totally be avoided by just using the data() stuff directly.

blaze33 10y ago

Does anyone know if there is a good way to do server-side rendering (svg files) of D3 charts while being able to reuse the same code in a browser? We do a lot of charts at work to visualize electricity consumption and are currently thinking about how to rewrite the js we've accumulated over the years. I've found some attempts at doing server-side rendering but nothing really compelling for now... D3 is a well thought out library to do interactive visualizations in the browser and having an easy way to do svg exports (for things like automated emails) would be a big plus. Doing screenshots through selenium ain't always so pleasant ;)

m0j0l 10y ago
Not sure if it fits your use case, but; for one project I needed to have charts that the user could modify in their browser, and once they were happy they could hit 'download PDF' to get a PDF version. Achieved this by (admittedly slightly clunky way) of sucking the SVG out of the chart and sending it to the server via ajax. Server intercepts SVG and passes it to inkscape which does pretty good command line svg -> pdf... then, sends back completed PDF. One gotcha is that you won't get any CSS this way, so all styling has to be done via SVG props.
- e1g 10y ago
  That's exactly what we are doing but running the SVG code through Apache Batik Rasterizer to turn it into png. I like this approach because the user can customise the chart in the front end and then the same resulting svg code is rendered by the backend. The only issue is styling as you mentioned.
- Frencil 10y ago
  > One gotcha is that you won't get any CSS this way, so all styling has to be done via SVG props. There actually is a way to bake stylesheets directly into the SVG in a way that at least Inkscape can read, but it's tricky. We're successfully doing this in a graphing library tuned for genetic data that's built on top of d3 called LocusZoom. The first step is to get the content of the stylesheet into a string. We do that here with a CORS request in case the stylesheet is being loaded over a CDN, as javascript won't be able to access the content of CDN-loaded stylesheets from document.styleSheets: https://github.com/statgen/locuszoom/blob/v0.4.0/assets/js/app/Instance.js#L808 https://github.com/statgen/locuszoom/blob/v0.4.0/assets/js/a... Since the stylesheet doesn't change once the page is loaded this only needs to happen once. From there, in our case, we have a dynamic/interactive SVG plot so the download needs to bundle up the current state of the SVG on request. Here's the method that does that: https://github.com/statgen/locuszoom/blob/v0.4.0/assets/js/app/Instance.js#L783 https://github.com/statgen/locuszoom/blob/v0.4.0/assets/js/a... Other than what no doubt looks familiar for pulling the raw SVG markup into a string we also insert a tag right after the opening <svg> tag that looks like this: "<style type=\"text/css\"><![CDATA[ " + this.css_string + " ]]></style>" Where this.css_string is our stylesheet content. We then base64 encode the string and stick in the href of an <a> tag styled to look like a download button as seen here: https://github.com/statgen/locuszoom/blob/v0.4.0/assets/js/app/Instance.js#L748 https://github.com/statgen/locuszoom/blob/v0.4.0/assets/js/a... The end result is a download SVG link/button that is 100% client-side with our chosen stylesheet embedded. Now, I have noticed that some styles defined in the stylesheet are valid in the browser but fail in InkScape and other SVG viewers. A prime example would be setting a stroke or fill to "transparent". InkScape doesn't interpret this properly and you can end up with solid black, just about the exact opposite of transparent. Keeping this in mind I stick to defining explicit "fill-opacity" and "stroke-opacity" values in the stylesheet for SVG elements and everything plays nice. A working demo of this can be seen here: http://statgen.github.io/locuszoom/plot_builder.html http://statgen.github.io/locuszoom/plot_builder.html

monfera 10y ago

Fantastic work! D3 has a large API surface area, due to the functionality it covers. So even a relatively conservative major upgrade is a TON of work, and some of it might not have been pure fun only. 1) What's your opinion on the apparent case that the bulk of changes come from you, as society promotes teamwork so much? Is it a case of 'small team efficency'? (Btw. I know of others' contributions too, and reliance on Rollup, ColorBrewer, matplotlib/Viridis etc.) 2) What kept you going? It's probably at least a person-year of work just on your side that's not paid for by companies, not to mention some kind of startup bet. Have you alternatively toyed with the idea of starting a value-added layer, since so many for-profit organizations benefit from your work? 3) While it changes the API, and most everything is rewritten, it's IMO a conservative upgrade in that it doesn't steer away from familiar concepts and structure. It still does DOM binding, transitions, layout etc. fairly similarly. Have you considered much more disruptive departures? As an example, React's DOM diffing is more radically different from D3 selections than the change from D3 3.* to 4.* or the Grammar of Graphics as an API concept is more radically different from D3 than the 3.* -> 4.0 API changes. Or something like moving away from the 'functional objects' concept in favor of curried, fixed-argument pure functions, perhaps prefaced with the familiar chaining API would have been a large change (these are mostly examples rather than wishlist). What were YOUR ideas, had you wanted more disruptive changes, or 'D4'?

smrtinsert 10y ago
IIRC a key point of d3 was to not be declarative, like the gog. That was more an influence in protoviz, its precursor. You might be interested in Vega and Vega lite if you want to go declarative.
- monfera 10y ago
  I'm contributing to plotly.js right now, which is also declarative, and I see the pros and cons of levels of denotative semantics (mostly depends on goals and library user requirements) but it was just an example for what I mean by more radical changes. Good you mentioned it anyway, protovis -> D3 also represented a rather disruptive change. But perhaps I was late with these questions for this specific AMA.

deleted 10y ago

[deleted]

toothrot 10y ago

Why didn't they name it D4

colejohnson66 10y ago
Because D3 is the actual name of the library. The full name is "Data-Driven Documents v4.0.0". Shorten that and you get "D3 v4.0.0".
- 8note 10y ago
  and there's a derivatived library called D4 as well
  - mrits 10y ago
    Derivatived Data Driven Documents?

dnprock 10y ago

For those interested making d3.js reusable for data analysis, check out https://vida.io https://vida.io. We create templates out of d3.js visualizations with dynamic properties. You can create dashboards from custom d3.js components. For more examples, see https://vida.io/explore https://vida.io/explore.

sntran 10y ago

For simpler need such as rendering a SVG map from Topojson or GeoJSON data, is there an alternative than D3 that can utilize React.js' rendering of SVG? With no animation, no charts, just map with zoom in and out and drag around, is there a benefit of using D3?

con_ssc 10y ago

1. Are there any plans to have a TypeScript version of the lib? 2. Would it be possible to add jsdoc comments for autocompletion? 3. Are the polyfills for Map and Set still necessary now that we have that in es2015? 4. Why is the lib so heavy on argument overloads? 5. Are there any code style restrictions? I often saw loops and conditions without curly brackets and alike. 6. Are there any fields you'd need support in for maintaining or reworking the library? I really like D3.js although I haven't found an application for me yet. I find it hard to get/update the date from a none standard REST endpoint and display them, especially if they are kind of multichanneled, like working times of multiple users unordered.

deleted 10y ago

[deleted]

dasdas1111 10y ago

dsadsds

onesquared 10y ago

The d3.transform method has been removed. But have you a similar function in d3js v4.0.0 ?