Three again#174
Conversation
fixes #121 thanks, @benstevens48!
Currently, the radial force...
d3.forceRadial(radius[, x][, y])
... allows only numbers to the `x` and `y` positions:
> If x is specified, sets the x-coordinate of the circle center to the specified number and returns this force.
This proposed change allows passing functions to `radial.x()` and `radial.y()`, using the same pattern of other forces. Here is the working demo: https://bl.ocks.org/anonymous/0685343afe4675a022403be8728bc7c4/7dda06727201c128b9ff820b24c2c955e655436d
and change x,y not vx, vy. - this makes #81 non-breaking - strength=1 recenters "at once" for non-interactive graphs (or, for example, the initial phyllotaxis layout) - strength=0.05 recenters gently for interactive situations such as https://observablehq.com/d/674136693ce67301 fixes #81
|
Requesting a review from @enjalot Demo of forceRadial.angle at https://observablehq.com/d/9187c989f882beee |
|
I took a closer look at forceRadial and don't see anything problematic. I made a deterministic fork of your example to help me pull apart the demo: It would be interesting to plot the non-force radial layout as way of understanding (visually verifying) the underlying data distribution. I played towards this here: https://observablehq.com/@enjalot/triangle-world?collection=@enjalot/triangle-world so that I could demonstrate how well UMAP was doing conceptually here: https://observablehq.com/@enjalot/triangle-world-umap?collection=@enjalot/triangle-world I'd like to do one for forceCenter in this way as well, if only to give people a better sense of what "softer" means.
|
|
Closing this PR since:
|
3 participants
Fixes:
Supersedes #172 #173 ; because of #113 it is a breaking change.