Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Three #173

Closed
wants to merge 13 commits into from
Closed

Three #173

wants to merge 13 commits into from

Conversation

Fil
Copy link
Member

@Fil Fil commented Jul 28, 2020

Because of the breaking changes in #81 (which impacts #17), #167 (and partly #45) this branch is "maximalist", and should be published as d3-force@3.

I would prefer to do this "maximalist" approach now to integrate into d3v6, but the alternative option is to have a minimalist d3-force@2 (#172) and wait for d3@7 to include these changes.

Fil and others added 8 commits June 25, 2020 18:32
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
src/radial.js Outdated Show resolved Hide resolved
@mbostock
Copy link
Member

If we’re willing to break backwards-compatibility then I think having explicit start is better than implicit start on the first event listener.

Fil and others added 2 commits July 28, 2020 22:22
Co-authored-by: Mike Bostock <mbostock@gmail.com>
@Fil
Copy link
Member Author

Fil commented Jul 28, 2020

I've just pushed that change (with simulation.restart aliased as simulation.start).

The code is admittedly cleaner, but it feels a bit awkward. (Maybe I just need a moment to get used to it.)

@Fil
Copy link
Member Author

Fil commented Jul 30, 2020

Concerning forceCenter() there is probably a case to be made for when you want an immediate centering (in particular to recenter an initial phyllotaxis arrangement).

Should we remove the dependency on alpha and just leave an optional strength() function? Then the default strength(1) would be immediate, and strength(0.05) or so would be the go-to choice for gentle interactive recentering.

Fil added 3 commits July 30, 2020 16:21
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
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
@Fil
Copy link
Member Author

Fil commented Jul 31, 2020

TL;DR: Drop #45 ; merge #167, #81 and #17.

After more consideration and tests:

  • I'm not terribly happy with Rethink automatic starting of simulations? #45; automatic start is nicer to use than having to explicitly call simulation.start, and easy to override with simulation.stop(). The logic of "waiting for listeners" (dubbed solution 1) was not right either (even if that's not recommended, you can imagine a situation in which the forces themselves are producing some side effects, the simulation being used like a timer…). The issue it wants to address can be solved by an example (stop, load then restart). So I'd vote to walk back this part.

  • forceRadial x, y and angle accessors (forceRadial x, y and angle accessors #167) are great; I don't think that it will impact many examples (or any at all) but the change is technically breaking (the getters now returning a function rather than a number).

  • forceCenter.strength solves d3.forceCenter should have an alpha parameter. #81 and defaults to the previous behavior, meaning it can be included with no breaking change, now or later.

  • the tests are now immune to the change in forceCenter, so they can be included with no breaking change

@Fil Fil mentioned this pull request Aug 1, 2020
3 tasks
@Fil
Copy link
Member Author

Fil commented Aug 1, 2020

closing in favor of #174

@Fil Fil closed this Aug 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants