DatumFunction refactoring investigations

[anthonime]

@ericcitaire

It appears that we forgot an additional argument in the DatumFunction.apply() method.
It is explained here: http://bost.ocks.org/mike/nest/#index

The tutorial clearly states that we can access the "row index" in case of nested selection.
I have tested it on different contexts (notably the Drag.origin method which is not clearly documented in d3.js).

I have the strong feeling that in every part of the API, every time a "data-aware" function can be provided, and even if it is not clearly documented, the method that we can pass always ensure the following contract:

• 'this' is the current element context (or an other object, e.g an Array, but in that exceptional case it is clearly stated in the documentation).
• arg 1 is the datum
• arg 2 is the index of the element in the selection / the index of the datum in the array of datum
• arg 3 is the row index in case of nested selections (and default to 0 in case of a flat selection)

So I suggest that we refactor the DatumFunction to take the additional argument into account.

What is not clear to me is, in case of a multi-dimension nested selection (like array of array of array), will we have additional arguments (fifth, sixth, etc...) ? or is it limited to one level of nesting ?

I am going to investigate further in the next days.

What do you think ?

Involved API:

• selection.attr - get or set attribute values.
• selection.classed - add or remove CSS classes.

[anthonime]

Do not have a clue for the moment.

[anthonime]

as stated in the source:
https://github.com/mbostock/d3/blob/master/src/selection/each.js

there is an extra argument for the group index, j