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.

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

How to expose state to callbacks? #4

Closed
mbostock opened this issue May 6, 2016 · 1 comment
Closed

How to expose state to callbacks? #4

mbostock opened this issue May 6, 2016 · 1 comment
Assignees

Comments

@mbostock
Copy link
Member

mbostock commented May 6, 2016

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.

@mbostock mbostock self-assigned this May 6, 2016
@mbostock
Copy link
Member Author

mbostock commented May 6, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant