0.3

[Fil]

Fixes #1 #3 #8. (I tried to separate the concerns but there were too many conflicts between my changes, and I gave up.)

Demo: https://observablehq.com/d/892da8c88474a46c

[mbostock]

I can’t put a finger on it but the API feels… a little awkward. Like, you presumably wouldn’t ever change the x- or y-accessor after populating your bins, but the API lets you. Perhaps we should model d3-delaunay instead. I’m excited about this work, through! I’ll try to play with a notebook and get a better sense of what I think would work well.

[Fil]

I don't have a clear use case for changing the x accessor mid-course, but if you're working on a stream of values, then maybe x represents their age x(d => d.time - currentTime) and currentTime varies… though we would probably recommend using translate() in this specific case.

[Fil]

Did you mean than once a point p is accessed, its (x,y) values should be set — but its (i,)j coords on the grid (the bin) could change if we change the translate/rotate?

I would tend to agree — but it means big changes:

• need to keep track of (x, y). If we don't want to mutate p, it means binning {x,y,p}?
• When doing a remove/removeAll operation we would need the accessor again, and make sure it gives the same (x,y) — or at least the same bin (i,j), because we're removing with bin.indexOf(point).

[Fil]

Rebased on master.

[Fil]

the API feels… a little awkward. Like, you presumably wouldn’t ever change the x- or y-accessor after populating your bins

Giving it another thought, there are 3 possible scenarios when when change a parameter and already have some data binned:

• A) do nothing special, keep the binned values in the hexagons they were sent to
• B) rebin with the new parameters (current approach of this PR)
• C) purge the existing bins and start again

I think there is a plausible user story for each of the scenarios; but I see the weirdness both in A and B, for opposite reasons.

With A the binned points are moving with their hexagons when you change the translate/rotate/radius, so what I do in the demo is not possible.

With B they are accessed again, so you can't have an x/y accessor that depends on time and points that are progressively binned and stay put.

The safe solution is probably C — also more future-proof as it creates no weird expectation? This way the user has to be explicit in how they want to bin everything (past and new data). The only drawback is that the hexbin isn't your data store (but it's easy enough to retrieve the data before changing the params, then rebin it).

[Fil]

Superseded by #19