Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
258 views
in Technique[技术] by (71.8m points)

javascript - Why does d3.js v3 break my force graph when implementing zooming when v2 doesn't?

I have a force layout that I have created using d3.js

I would like to have both the normal functionality of a draggable force layout as well as the ability to zoom.

I have basically copy/pasted the zooming code from (http://jsfiddle.net/nrabinowitz/QMKm3/). This is the same way of zooming that Mike Bostock uses in (http://bl.ocks.org/mbostock/3680957).

Here is my code: http://jsfiddle.net/kM4Hs/6/

The zooming works fine, but I am unable to select single nodes in the force layout and drag them around.

I have found the culprit to be the fact that both authors use d3.v2.js rather than the newer d3.v3.js. When I change my import to v2 it works perfectly. However, I would like to use v3 if possible.

<script type='text/javascript' src='http://d3js.org/d3.v3.min.js'></script>

versus

<script type='text/javascript' src='http://d3js.org/d3.v2.min.js'></script>

why does v3 break the force layout when v2 doesn't, and more importantly, what can I do to fix it?

Thanks in advance!

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

If you peruse the release notes, you’ll see a full explanation of everything that’s changed between the final release of 2.x (2.10.3) and the most recent release, 3.2.7. In particular, from release 3.2.2:

Better handling of drag gestures in d3.behavior.drag, d3.behavior.zoom and d3.svg.brush by not preventing default behaviors or stopping propagation. For example, mousedown now changes focus, mouseup outside an iframe works correctly, and touchstart does not stutter.

So, in V2, the drag behavior could take priority over the zoom behavior by stopping propagation on zoom events. In V3, this no longer happens automatically, giving you the choice of which behavior takes priority, and when.

If you want to give the drag behavior priority when dragging nodes, then you need to stopPropagation on input events while dragging so that these events are not simultaneously interpreted as panning by the zoom behavior. Stopping propagation on dragstart is sufficient:

var drag = d3.behavior.drag()
    .on("dragstart", function() { d3.event.sourceEvent.stopPropagation(); })
    .on("drag", function() { /* handle drag event here */ });

If using a force layout, the code is:

var drag = force.drag()
    .on("dragstart", function() { d3.event.sourceEvent.stopPropagation(); });

Working example:

drag and zoom

Note: combining these two behaviors means that gesture interpretation is ambiguous and highly sensitive to position. A click on a circle is interpreted as dragging that circle, whereas a click one pixel away could be interpreted as panning the background. A more robust method of combining these behaviors is to employ modality. For example, if the user holds down the SPACE key, clicking and dragging is interpreted as panning, rather than dragging, regardless of the click location. This approach is commonly employed in commercial software such as Adobe Photoshop.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...