Add a `simulation.isFixed(node)` function about d3-force HOT 10 CLOSED

Hmm, maybe. In that example, though, I’m not sure how helpful simulation.isFixed would be. If you tried to use it on dragended, for example:

function dragended() {
  if (!d3.event.active) simulation.alphaTarget(0);
  if (simulation.isFixed(d3.event.subject)) simulation.unfix(d3.event.subject);
}

It would always be true because the drag subject is fixed in dragstarted. So it’s already the case that you’re going to need to track some external state to record the nodes that were fixed prior to the start of a drag event.

And if that’s the case, why not just store a node.fixed boolean yourself, like this?

https://gist.github.com/mbostock/4e4a31f132bc6b27634234dc935a7252

from d3-force.

That is true. The reason I'd really like this is that I'd prefer the node creation code to be agnostic of how drag is implemented. i.e. the node creation code can call .fix(node) without having to be aware of updating any extra state.

To work around the if (simulation.isFixed(d3.event.subject)) simulation.unfix(d3.event.subject); issue I was planning to store the previous fixedness on node._fix or similar, and then restore that state.

An alternative would be "onfix/onunfix" hooks, so that I could add that state and then modify it at a later point, that really feels hacky though.

from d3-force.

I also encountered a similar issue when trying to serialize/deserialize the "fixedness" of nodes in this Graph Diagram Editor. Related issue there - Store fixed node positions in files.

I was looking for a way to get the fixedness out of the simulation, but have not yet managed to do so. It seems like isFixed would be a great companion to simulation.fix. I feel like the "fixedness state" lives inside the simulation, so it would be great to be able to retrieve it from there, rather than duplicating the work of tracking the fixed state.

from d3-force.

Probably there should be a way to inspect not just the fix state of a node (a boolean) but to retrieve the current fixed position {x, y} (or null) for a given node. Perhaps this should be a matter of calling simulation.fix(node) without arguments x and y, similar to other getter-setter methods in D3. That would mean it’s a little harder to fix a node in its current position, though it’d be easy to say simulation.fix(node, node) to fix a node in its current position.

from d3-force.

I like he idea of getter/setters for these properties. But then I feel like it is wrong to conflate setting the position which happens to also set the fixed state to true. So, how about:

• fixed(node, bool) - set the fixed state
• fixed(node) - get the fixed state
• position(node, {x,y}) - set position
• position(node) - get position

Then for convenience you could add a fix(node) method that would be equivalent to:

fixed(node, true);
position(node, node);

The names may not be ideal, the fix/fixed distinction could be confusing.

from d3-force.

I feel like it is wrong to conflate setting the position which happens to also set the fixed state to true.

It’s not conflating them because simulation.fix isn’t setting the position of the node: it’s setting the fixed position of the node, which is independent of its current position. The current position of the node is node.x and node.y. When forces apply to that node subsequently, they typically modify node.x and node.y (and possibly the node’s velocity, node.vx and node.vy). The simulation then restores the position of the node back to its fixed position, if any.

from d3-force.

It felt like we were designing a lot of API to expose and manipulate something that should just be a node property—like the node’s position (node.x, node.y) and velocity (node.vx, node.vy). So that’s what I’ve done: if you set node.fx and/or node.fx, you can fix a node’s position. By clearing these properties, you unfix a node. It’s very similar to how node.fixed worked in D3 3.x.

from d3-force.

Yes, great observation, much cleaner.

Any idea when this will appear in a d3.v4 alpha release? Thanks.

from d3-force.

Soon… D3 4.0 should be released by the end of the month. I’ll cut another alpha release before then; probably later this week. But I don’t want to cut too many releases since it’s inefficient and I need to focus on finishing 4.0.

from d3-force.

(You can clone this repo, run npm run prepublish and then load a copy of d3-force.js after d3.js and get the latest code in the interim.)

from d3-force.