d3-force-drag? about d3-force HOT 7 CLOSED

@mbostock How's this: d3-force-drag?

The module checks if the argument node is a canvas element and applies drag.container and drag.subject accordingly. Then it, by default, implements "basic" drag behavior.

The listener and dragsubject functions are customizable, providing for cases where the defaults aren't good enough.

from d3-force.

While I understand the drive to add more syntactic sugar (and in pure D3 candy land it would be great), I would reiterate your already identified:

Another gotcha is that I don’t want to introduce a dependency from d3-force to d3-drag (or vice versa), so this would need to live in a new module d3-force-drag, presumably.

To elaborate, the separation of concerns between the event handling in d3-drag (and underneath the hood d3-selection for d3.event is critical in use cases where event handling is done outside the realm of D3. E.g. using d3-force for layout calculation, but Angular for DOM/rendering and event handling.

from d3-force.

@tomwanzek That's hard for me to visualize (or maybe I'm misunderstanding) because I've never worked with Angular, but I don't doubt it. May you provide such a case?

from d3-force.

@augmt Unfortunately, I cannot currently point you to a public worked example repo that fully illustrates the point. But I will try to give a "verbal" 50,000ft explanation (in reference to Angular 2+)

At its most fundamental, Angular manages a tree of data-driven, reusable components. For purposes here, let's just focus on a web application rendered in the browser.

A reusable component is essentially a combination of a component HTML template, possibly component-specific styles (e.g. css) and the code for the component class. The component class code, at its most basic, allows the Angular (change detection and the rendering engine):

• to instantiate components using input data bindings
• render the component template in the DOM
• handle events (e.g. DOM events bound to elements in the template or non-DOM events)
• emit output events which can be listened to and handled by parent components
• destroy no longer needed components.

The components can be nested in component trees etc. They are reusable in that they can be instantiated multiple times, wherever needed in the web application.

Against this simplistic background, there are two strategies to use Angular 2+ and D3 to generate visualizations of force-directed networks with e.g. node dragging.

Strategy 1: D3 is Allowed to touch the DOM

• An Angular 2 component has a template which essentially only contains a DOM element, like and svg or g to serve as an anchor point for the simulation visualization.
• The component accepts input data defining the network data.
• d3-force is used for the layout of the network/simulation
• d3-selection and d3-drag are used to dynamically append the simulation visualization to the anchor point element and handle all DOM events within these dynamically added DOM elements.
• If network data change, d3 functionality (merge, enter/exit/update) is used to update the DOM as needed

Strategy 2: D3 Force for Layout Calculation Only

• An Angular 2 component has a template which contains elements to visualize the entire network (including nodes and links)
• d3-force is used to simulate the network and compute the node positions depending on the use case
• Angular 2 is used to map the network data (including position data) to the visualization elements for individual nodes and links and touch the DOM as needed. (Angular has a directive called *ngFor which allows an array of data to drive the generation/destruction of DOM elements for each array element.
• All DOM events required to support node dragging are bound to the so generated node DOM elements using Angular 2. This means a dragging logic functionally comparable to d3-drag is implemented in Angular 2.

While there is a bit more to Strategy 2, when it comes to using a one-way data flow for component interaction, at the core it means Strategy 2 does not use d3-selection (incl. d3.event) and d3-drag. I.e. D3 does not touch the DOM itself.

So a tight coupling between d3-force and d3-drag might limit the choice of strategies. Thus I think the modularization choice made so far was very wise indeed 😄

from d3-force.

PS: Actually, there is the following illustrative implementation: ngx-charts force-directed graph

from d3-force.

I’ve been using the drag function here often:

https://observablehq.com/@d3/force-directed-graph

from d3-force.

Closing this issue due to inactivity. Please do not hesitate to add a comment or reopen the issue if you think it is still worth pursuing.

from d3-force.