Hi Mike, Jason,

I'm a package maintainer for Meteor.js, a popular full-stack JavaScript framework.

Meteor devs love d3. It was a core package until recently, and now it's time to separate concerns and let the community maintain the Meteor <-> d3 integration. This PR will allow you to directly publish updated versions of d3 as they become available. All you have to do is create an account at https://meteor.com/ (click SIGN IN, then Create account). After you've done that, please let me know the name of the account, and I'll add you as a maintainer.

I've already published the current version of the package on Atmosphere (Meteor's package directory). When you release new versions of d3, you'll be able to publish them to Atmosphere by running make meteor.

Thanks & best regards, Dan

Hi Mike,

am I correct that when you set an SVG attribute, (ie. .attr('width', 300)) the 'this-object' is not available? If I would want to find out the this.parent.index which I could do in Protovis, how would I do that in D3? And for instance, can I access parent index in D3?

And something else of which I am not really sure what I am doing wrong: var c = d3.scale.linear().domain([0, 50, 100]).range(['#19162B', '#1C425C', '#ffffff']) and when I do c(100) it doesn't turn out white, which is what I would have expected?

Thanks! Jan Willem

I know this was considered previously (#1978 mbostock/smash#12), but I’ve been using Browserify for a project and I like it quite a bit. It might be time to rewrite D3 to use Browserify along with the other larger 4.0 changes.

Hello D3 Family!!!!! @TheLarkInn from webpack here!

We have been working on a new feature for webpack 4+ which allow's library authors to add a special field to package.json allowing them to declare that their libraries that have "reexports" in them do not contain side effects!

Tiny Backstory

Because webpack implements the Harmony Module Specification to spec, we include code that was reexported (even if it wasn't used). This is because all code [per spec] must be eval'd). The beautiful news is that we do not have to implement exactly to spec. So we have created what is called "pure-module". webpack as imports are being resolved will also check to see if the module is pure (which is indicated through the pure-module flag in the package.json fields). Therefore, there would be no bundle size difference between the following examples:

import {bottomAxis} from "d3-axis";

and

import bottomAxis from "d3-axis/direct/path/to/d3AxisBottom"

Proposal

If there are no side-effects within the D3 packages in places where re-exports occur, then I'd love to propose that all D3 packages add pure-module: true to their package.json.

Pros

Developers (using webpack) get huge perf wins by doing nothing.

Cons

Bit more work to get it all done.

Please let me know if you have any questions, the webpack team is really anxious to help in any way if we can (that means, submitting PR's, adding issues to individual repo's to track, etc).

sideEffects: true

• [x] d3-format (src/defaultLocale.js)
• [x] d3-time-format (src/defaultLocale.js)
• [x] d3-transition (src/selection/index.js)

sideEffects: false

• [ ] d3
• [x] d3-array
• [x] d3-axis
• [ ] d3-brush
• [x] d3-chord
• [x] d3-color
• [x] d3-contour
• [x] d3-delaunay
• [x] d3-dispatch
• [x] d3-drag
• [x] d3-dsv
• [x] d3-ease
• [x] d3-fetch
• [x] d3-force
• [x] d3-geo
• [x] d3-hexbin
• [x] d3-hierarchy
• [x] d3-interpolate
• [x] d3-path
• [x] d3-polygon
• [x] d3-quadtree
• [x] d3-random
• [x] d3-scale
• [x] d3-scale-chromatic
• [x] d3-selection
• [x] d3-shape
• [ ] d3-tile
• [x] d3-time
• [x] d3-timer
• [ ] d3-zoom

This is based on the Protovis version. This initial commit is just to see if I'm on the right track, there are still a few things to add e.g. vertical orientation before it should be pulled.

When ES6 code importing d3 (using "import * as d3 from 'd3') is transpiled using Babel, Babel tries to imitate the ES6 module immutability by copying the poperties on the exported object into a new object. This includes d3.event which is thus always seen as null from the importing module's perspective.

Do you have a fix in the pipeline for this?

I am using voronoi to make simple radnomized drawings. It works great most of the time, but once in a while throws an error 'TypeError: Cannot read property 'x' of null'. Is it a know error? Is there some points for which there is no Voronoi tesselation that can be calculated?

For example, this happened with the following data set :

var data = [[162.625,97.42857142857143],[540.6751658469439,97.42857142857143],[512.852513932271,140.7176197088363],[527.1340686082946,193.83092702632547],[477.96982619017825,238.62234566803937],[451.4444556682072,281.63698097906445],[483.1044046913885,292.7353428956168],[408.25114800483453,361.11349522897973],[368.4552492817462,386.43779412571894],[367.73991981069696,408.4655505584161],[327.23397423325974,440.91126844861094],[271.9441040381313,447.2783369755093],[231.3183408178836,464.8987604363098],[183.64125952641743,490.6342071874143],[139.01744689338847,425.60629082860515],[91.52476039970534,440.8609536265624],[50.7819582027996,466.7517342167433],[11.183244819866417,409.5782014996885],[-12.022138010542562,426.2499782865578],[-52.11768265327041,404.35232813819675],[-87.91180657628351,365.92763451746805],[-115.31234555488544,323.9298076521682],[-137.77305520454655,274.51946250365353],[-208.63232162457786,239.8917783235541],[-164.05196897480602,185.08788433033993],[-225.86198629074596,142.5763909605722],[-164.51515098288655,97.42857142857147],[-168.93241508152545,48.8112871990978],[-220.62094168742402,4.249358577293663],[-156.03958646319967,-28.976123962541905],[-155.59804866991823,-87.49511552151564],[-117.46219598471191,-137.50936864144467],[-114.42256168476172,-124.80797733093577],[-62.40654690401547,-173.24432815621287],[-34.92109288645628,-231.77547272408145],[13.243281327294596,-253.71290365408754],[50.108112775233224,-280.520402320271],[94.67169382248188,-289.4662314229714],[140.75187833759216,-295.76903521730037],[186.7138723643959,-252.77374498107582],[231.72212738926686,-267.7762086250434],[266.80663424058025,-219.8715369001228],[308.80693489306793,-232.91974386965757],[348.426624775039,-199.88281899388494],[373.6656986850646,-210.53607230240647],[436.75498495400694,-148.29678300908915],[442.8566733626943,-122.9898329610533],[488.7596396659666,-65.55986283677596],[527.8148963912654,-36.90405535711672],[482.29962464758825,9.630899371618412]]

Things to do (https://github.com/d3/d3/issues/2922)

• [x] Arrays (d3-array)
• [x] Axes (d3-axis)
• [x] Brushes (d3-brush)
• [x] Chords (d3-chord)
• [x] Collections (d3-collection)
• [x] Colors (d3-color)
• [x] Dispatches (d3-dispatch)
• [x] Dragging (d3-drag)
• [x] Delimiter-Separated Values (d3-dsv)
• [x] Easings (d3-ease)
• [x] Forces (d3-force)
• [x] Number Formats (d3-format)
• [x] Geographies (d3-geo)
• [x] Hierarchies (d3-hierarchy)
• [x] Interpolators (d3-interpolate)
• [x] Paths (d3-path)
• [x] Polygons (d3-polygon)
• [x] Quadtrees (d3-quadtree)
• [x] Queues (d3-queue)
• [x] Random Numbers (d3-random)
• [x] Requests (d3-request)
• [x] Scales (d3-scale)
• [x] Selections (d3-selection)
• [x] Shapes (d3-shape)
• [x] Time Formats (d3-time-format)
• [x] Time Intervals (d3-time)
• [x] Timers (d3-timer)
• [x] Transitions (d3-transition)
• [x] Voronoi Diagrams (d3-voronoi)
• [x] Zooming (d3-zoom)

Choose your module, leave a comment and add chevrons next to the method name in README.md like this:

# d3.min(array[, accessor]) <>

Returns the minimum value in the given array using natural order. If the array is empty, returns undefined. An optional accessor function may be specified, which is equivalent to calling array.map(accessor) before computing the minimum value.

d3.time.day should always return midnights. However, Firefox doesn't return midnight for the following:

var d = new Date(1970, 0);
d.setFullYear(2011, 8, 22);
// Thu Sep 22 2011 01:00:00 GMT+0100 (BST)

Chrome and Node.js return:

// Thu Sep 22 2011 00:00:00 GMT+0100 (BST)

This is because new Date(1970, 0) has different daylight saving behaviour in the two browsers.

Chrome: Thu Jan 01 1970 00:00:00 GMT+0000 (GMT) Firefox: Thu Jan 01 1970 01:00:00 GMT+0100 (BST)

In fact, Firefox is more correct! The UK was on permanent BST from February 1968 until October 1971. This seemingly minor difference in interpretation results in non-midnight times being returned for all day intervals and other intervals that use d3.time.day internally.

The fix forces midnight to always be returned.

Fixes #1196.

It might be useful to expose this as d3.svg.textWrap?

function wrap(text, width) {
  text.each(function() {
    var text = d3.select(this),
        words = text.text().split(/\s+/).reverse(),
        word,
        line = [],
        lineNumber = 0,
        lineHeight = 1.1, // ems
        y = text.attr("y"),
        dy = parseFloat(text.attr("dy")),
        tspan = text.text(null).append("tspan").attr("x", 0).attr("y", y).attr("dy", dy + "em");
    while (word = words.pop()) {
      line.push(word);
      tspan.text(line.join(" "));
      if (tspan.node().getComputedTextLength() > width) {
        line.pop();
        tspan.text(line.join(" "));
        line = [word];
        tspan = text.append("tspan").attr("x", 0).attr("y", y).attr("dy", ++lineNumber * lineHeight + dy + "em").text(word);
      }
    }
  });
}

Live example: http://bl.ocks.org/mbostock/7555321

I'm working on Mozilla Aurora v 30.0a2 and I noticed this Warning today appearing in both Firefox Dev tools and Firebug.

"TypeError: mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create"

I've switched to Chrome and there was no such warning in the console.

To be sure that it is not something inside my web application I've tested several examples provided in https://github.com/mbostock/d3/wiki/Gallery and they all seem to give out the same warning.

I know it is just a warning but still, I thought I should bring it up.

Mainly while answering questions on StackOverflow I often find myself looking for information about when a method was added to the code base. It would be particularly helpful if we could have this information presented in the API docs themselves like this:

# selection.selectChild([selector]) · Source · Since v2.0.0

Ideally, the version info on the method would link directly to the tagged release version in the GitHub repository like in above example.

Obviously, this needs to be done twice for every method:

1. Version when added to the module
2. Version when added to the main bundle

This is a one-time effort, though, as the information will not change in the future. Should we agree on this I would love to volunteer for assembling the information from the repository's history.

I'm curious, what the stance is in terms of adopting let and const in this repo?

Possible approaches:

• Consistently ES5 (var only)
• Consistently ES6 (e.g. would a PR be welcome that converts all var to let & const?)
• Allow internal inconsistency (mixed var, let, const within & between files)

This relates to how PRs should be reviewed with respect to usage of these keywords. Thanks!

the main page : https://d3js.org/

has beehive alveolas of examples usages on diverse sites but some of the examples have ceased to be hosted by the sites. here are some examples :

http://www.nytimes.com/interactive/2012/11/30/us/tax-burden.html https://www.theguardian.com/info/2017/feb/05/removed-interactive