You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think the new design is better, but it presents an interesting conundrum: I want callbacks that conform to the D3 convention (this is the selected element, d is its datum, i is its index, and nodes is its group) but that can also receive additional information from the drag behavior (namely the coordinates x and y and the touch identifier id).
I could pass additional arguments to the callback, but that’s annoying because you have to specify (and then ignore) the standard arguments you may not care about, most often i and nodes.
I could omit the conventional arguments, and just provide this, but then you have to use this.data if you want the datum, which is ugly. And there’s no (easy) way to recover i or nodes.
I could temporarily expose the state on the drag behavior, or temporarily set them as globals, but isn’t that just a different way of accomplishing what d3.event is for?
This seems to imply that the additional state should be exposed on a custom d3.event.
I’ve so far avoided custom events because callbacks have either not been associated with a selection (d3-request and d3-force) or there wasn’t a need to pass any additional information (d3-transition; related d3/d3-transition#41). Though if we do want to pass additional information to transition callbacks, such as the transition’s name and id, it seems reasonable to expose that on d3.event, too.
So, if we are going to allow callers to temporarily override d3.event (and set event.sourceEvent automatically; related d3/d3-selection#70), then we’ll need a new method in d3-selection.
The text was updated successfully, but these errors were encountered:
This is of course related to selection.dispatch, which uses the native event system to dispatch a CustomEvent (and thus sets d3.event, although it doesn’t automatically set d3.event.sourceEvent… maybe it should). I don’t use selection.dispatch in d3-transition, since there’s no need for the events to bubble up the DOM, and the events are transition-specific rather than element-specific; and I don’t see a great reason to use it for d3-drag, either.
I think the new design is better, but it presents an interesting conundrum: I want callbacks that conform to the D3 convention (this is the selected element, d is its datum, i is its index, and nodes is its group) but that can also receive additional information from the drag behavior (namely the coordinates x and y and the touch identifier id).
I could pass additional arguments to the callback, but that’s annoying because you have to specify (and then ignore) the standard arguments you may not care about, most often i and nodes.
I could omit the conventional arguments, and just provide this, but then you have to use this.data if you want the datum, which is ugly. And there’s no (easy) way to recover i or nodes.
I could temporarily expose the state on the drag behavior, or temporarily set them as globals, but isn’t that just a different way of accomplishing what d3.event is for?
This seems to imply that the additional state should be exposed on a custom d3.event.
I’ve so far avoided custom events because callbacks have either not been associated with a selection (d3-request and d3-force) or there wasn’t a need to pass any additional information (d3-transition; related d3/d3-transition#41). Though if we do want to pass additional information to transition callbacks, such as the transition’s name and id, it seems reasonable to expose that on d3.event, too.
So, if we are going to allow callers to temporarily override d3.event (and set event.sourceEvent automatically; related d3/d3-selection#70), then we’ll need a new method in d3-selection.
The text was updated successfully, but these errors were encountered: