This question builds on previously rather sparingly documented behavior now described in this answer.
BACKGROUND
There are potentially many situations in which a mix of static and dynamic DOM elements are operated on by d3 transitions.
Here, by static I mean those elements in existence for (more or less) the lifespan of a governing svg:svg container, and by dynamic, I mean those created and removed with each transition cycle.
Individual static elements are normally subject to chained transitions, each new transition augmenting the previous one, the elements or transitions being assigned to a single, long-lived variable.
Dynamic elements are normally subject to staggered transitions, whereby each element or transition is assigned to a discrete, local and short-lived variable.
Whether chained, staggered or a mix, where discrete transitions exist concurrently, they appear to interfere with each other, suggesting that certain d3.transition() internal states end up being shared, or (otherwise put) that only one transition can be in existence at a given time.
I'm interested in strategies for eliminating such interference, the challenge being that -depending on the nature of the root or controlling transition, chained transitions may be derived from staggered transitions values and (less likely?) vice-versa.
PROBLEM
It seems to me that any such discrete but concurrent transitions may have to be maintained under entirely separate scope. The questions:
1) can multiple, discrete transitions coexist concurrently at all?
2) could they be coerced into coexistence through careful scoping?
3) if yes, how? Dare I hope for a d3-native pattern matching this use case?
FROM THEORY TO PRACTICE
This is just to give the above a little more context.
Were the circles in this compound animation static and the line dynamic, it would come very close to the situation I'm trying to describe.
In my case, the root transition has long been fixed as staggered, and much now depends on it. More a reflection of the state of D3 documentation than a conscious design decision, it's now a bit late to change.
My particular difficulty is the temporary highlighting of those circles using their fill and/or stroke attributes. Effectively, I have, locally, to convert from staggered to chained transitions..
First (and according to separate criteria) a small number of circles are selected from a fixed pool of possible, pre-existing circles. (For the sake of argument this can be imagined - while in fact just selecting the same two circles each time). OK
A governing, staggered transition is used to coordinate the drawing of (dynamic) lines between selected circles. OK
A derived, chained transition is then used to highlight the (static) circles selected. FAIL
Depending on how I try to augment a chained transition with the governing staggered transition values, the instant any second, concurrent delay() or duration() call is introduced, I'm rewarded with console errors of the form:
transition.delay is not a function
transition.duration is not a function
node.__transition__[id] is undefined
In this context, another important point: my staggered transition is received in a function call, ie passed by reference. This has until now allowed me to use the inherited transition values locally, as in:
selection
.transition() // <-- delay and duration as established *outside* the calling function
.call(do_something_cute)
.transition()
.delay()
.duration()
.call(do_something_cool)
It seems to be the inherited behaviours that any attempt at parallel, chained transitions is disturbing.
Though my first inclination was to wrap the chained transition and the static elements it acts upon in a closure, I'm now not sure this will enough to preserve it from impact by the wider staggered transition scope. I fear I may have to entirely isolate both - bringing greatly increased complexity. Will d3 come to the rescue?
