joelburget / d4 Goto Github PK

Hey Joel,
There is already a project named D4 for charting with D3 https://github.com/heavysixer/d4

I just thought i'd bring that to your attention because I had users ask if I'd released a new version of the project when they came across yours. I am sure this will lead to name collisions of some form or another. My project already has the NPM namespace for D4 https://www.npmjs.com/package/d4 so you'll run into problems if you hope to deploy there.

Best Regards,
Mark

Is there a good way to do axes in this paradigm?

The demonstration code of https://d4.js.org shows the following example code:

const paths = voronoi(samples)
    .polygons()
    .map(sample => (
      <path
        d={`M${sample.join('L')}Z`}
        fill={color(sample.data)}
        stroke={color(sample.data)}
      />
    ));

but this is missing a key for React to do efficient DOM diffing. Without it you'll get both console warnings, and potentially slow operations where two samples being swapped causes React to instead rebuild them instead of just swapping them.

For properly taking advantage of React, you'll want something like this:

const paths = voronoi(samples)
    .polygons()
    .map(sample => (
      <path
        key={sample.id}
        d={`M${sample.join('L')}Z`}
        fill={color(sample.data)}
        stroke={color(sample.data)}
      />
    ));

where sample.id is a unique identifier for a sample.

And note that, while tempting, you can't use map( (sample,idx) => ....key={idx} ) because the sample's position in the list is not uniquely identifying for the sample (that's only unique information for the specific list the samples are currently in), so successive calls with a reordered array would still make React perform far worse than if a proper unique value is used as key.

Hello,
there is a small inaccuracy in your documentation.
In the README you say:

A small thing — it's possible to use only parts of d3. For example: import {voronoi as d3Voronoi} from 'd3-voronoi'; instead of d3.voronoi, and import {lab} from 'd3-color'; instead of d3.color.lab), but nobody uses it that way, so examples of the import style are hard to find (and it's often not obvious which name will be exported (d3-geo exports geoArea and geoBounds rather than area and bounds).

Actually, the namespacing is a powerful feature and using it is encouraged in d3v4:

If you don’t care about modularity, you can mostly ignore this change and keep using the default bundle. However, there is one unavoidable consequence of adopting ES6 modules: every symbol in D3 4.0 now shares a flat namespace rather than the nested one of D3 3.x. For example, d3.scale.linear is now d3.scaleLinear, and d3.layout.treemap is now d3.treemap.

See the official migration guide (and specifically this namespace migration table for the d3-geo library)