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.

Sign up for GitHub

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

Jump to bottom

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 •
edited
Loading

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
@Fil
make forceCenter much less aggressive (with a small strength multipli…
b47fd69 
…ed by alpha)

fixes #81
@Fil
only start the simulation when someone is listening
ac23e0b 
fixes #45
@Fil
make forceCenter much less aggressive (with a small strength multipli…
676836f 
…ed by alpha)

fixes #81
@Fil
a few tests for #17
c1ee878
@Fil
forceCenter is now more gentle
006ea1b
@GerardoFurtado @Fil
Passing functions to radial.x() and radial.y()
e1a9ece 
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
@Fil
document forceRadial.x() and .y() as setting accessor functions inste…
46ce7a9 
…ad of numbers
@Fil
forceRadial().angle() sets the preferred angle
32e8571 
as in https://observablehq.com/@fil/forcepolar
closes #152
@Fil Fil mentioned this pull request Jul 28, 2020
Closed
5 tasks
@Fil Fil requested a review from mbostock July 28, 2020 09:33
mbostock
mbostock reviewed Jul 28, 2020
View reviewed changes
@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
@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
@Fil
Add forceCenter().strength(), which defaults to 1
04775ae 
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
Add forceCenter().strength(), which defaults to 1
e685de2 
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
Merge branch 'two-minimalist' into three
7dcfcb3
@Fil
Copy link
Member Author

Fil commented Jul 31, 2020 •
edited
Loading

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
Closed
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
Reviewers

@mbostock mbostock mbostock left review comments

Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@Fil @mbostock @GerardoFurtado