The “active” selection?

[mbostock]

Related d3/d3#2246. With ES6 arrow functions on the horizon, using this to represent the current selected node has diminishing usefulness. We should consider one of these options:

1. Setting the current node as a global (node), similar to the event global.
2. Tracking the current node internally and exposing an activeSelection (selectActive?) method.

The latter approach is along the lines of d3/d3-transition#15, which proposes an activeTransition method for accessing the active transition on a given element. We could restrict activeTransition to only apply to the current node, in which case you wouldn’t need to pass it a node, and you wouldn’t need to expose a global node, either.

The active selection should probably maintain the same grouping structure as the originating selection, rather than being limited to a flat selection. Although, I’m not sure this is a requirement.

I also wonder if having an activeSelection method would eliminate the need to pass indexes to selection methods. Well, you often still want to access the index as implicit data. So perhaps we do want to expose a node and index global, even if we also provide an activeSelection method. And if we are exposing these globals, then activeSelection() is simply shorthand for select(node) which isn’t especially useful… unless preserving the nested structure of the active selection is useful, in which case the two are slightly different.

Then the question is whether we want to also expose the active parent nodes and indexes as globals? And how?

[mbostock]

I recently changed the selection function arguments to {d, i, nodes}, partly to mimic standard JavaScript array methods that take {element, i, array}. This provides another way to access the current element: nodes[i], although perhaps not as convenient as the proposed d3.node. (The group can also be used to access the parent, as nodes._parent, although that requires the semi-private API.)

Also, now that selections are back to being bilevel rather than arbitrary hierarchies, the need to reconstruct the active selection is less important. Yes, d3.select(this) within selection.each loses the index and parent from the originating selection, but in most cases you don’t care about this information anyway. It feels like bilevel selections encourage you to think “flat” (for example, pushing data down to children as needed), rather than hierarchical selections which encourage more internal (inherited) state.

I think d3.activeTransition should require a node, rather than infer it from the “active” node. It feels a little too magical otherwise.