Support custom object key accessor in layer transitions

[ilyabo]

Target Use case

It's fantastic to have the support for very efficient layer transitions. Currently, there is a possibility to define entering transitions for the individual objects in a layer. However, to determine which elements are new, the array indices are used. From the docs:

Attribute transition is performed between the values at the same index

This is a very strong limitation. In our situation changes to data happen often and the objects must be sorted in a certain way, so we cannot put the new ones to the end of the array. Also, storing all the possibilities in the array and setting the opacities for the "non-existing" ones to 0 would be completely impractical (we need to represent connections between pairs of locations).

Proposed feature

It should be possible to specify a custom key accessor function to identify objects and changes in the data passed to a layer analogously to the D3's key parameter in selection.data()

To Do List

• [ ] Add label and assign to milestone
• [ ] Coding
• [ ] Doc update
• [ ] What’s new update
• [ ] Test

[Pessimistress]

@ilyabo Thank you for the suggestion. We do plan to expand the transition feature, though I'm not sure it can be as flexible as the d3 key feature, mainly because of its perf implication (potentially sorting an array of 1M objects).

Suppose we support enter/update/exit, but you cannot change the order of your objects. i.e. the transition from A0 C0 D0 to B1 C1 D1 will be treated as the exit of A, updates of C and D, and enter of B. However, the transition from A0 B0 C0 D0 to B1 C1 D1 A1 has to be treated as an exit of A0 and an enter of A1. Would that be sufficient for your use case?

[ilyabo]

Thanks for your answer @Pessimistress!

We draw arrows sorted by their weights. The sorting is essential so that the larger arrows are drawn on top of thousands of smaller ones. We have interactive filters (not in the above example) which modify data and affect the sorting. So the change may well be like A0 B0 C0 D0 to A1 C1 B1 D1 and it should not trigger any enter/exit transitions. That means that what you propose won't be sufficient for our case.

I understand that you have to make tradeoffs and performance is very important, but I also don't think that our case is a very special one. I think that not having the possibility to correctly identify changes will be a major blocker in many cases in which data can change.

I don't really know how it works under the hood (I believe you are using transform feedback for the animation, is that right?). But maybe you could optionally send the correct indices to the shaders along with the data to avoid re-sorting?

[Pessimistress]

In your use case, you are using order to simulate z-index. If you instead set a small z to the arrow positions, you should not have to reorder them (and z is transition-enabled, unlike object index).

We are indeed using transform feedback under the hood. To support reordered data, we will need to reconstruct the start buffer to match the new end buffer. I guess the perf loss is acceptable since you as the user knows what you are asking for.

[tsaiDavid]

Thanks for the awesome work on this library, wanted to say that it'd be very beneficial to have the support for identifying "new data" outside of just the array indices!

[JRVID]

@Pessimistress Just wondering if this work is still in progress at all? I have animation requirements on a data set that constantly changes in both length and order based on incoming data from an api/ changing zoom levels and using keys to identify the objects and their new positions rather than indexes would solve my issue instantly!