Improve implementation of computeFrames

extendDeepNoArrays was a simple way to prevent the frame logic from doing a deep extend on data arrays. The assumption was array attributes were a negligible concern. Transforms are a notable exception and should be deep-extended when computing frames. That can be handled with a special case. If this seems like a common situation though, then the attributes should be extended with proper knowledge of the plot schema.

@monfera, I know you’ve dealt with very similar issues when implementing transforms. Is merging attributes with knowledge of the plot schema a problem you’ve already solved elsewhere?

cc: @etpinard

[rreusser]

(which, to be clear, is just extendDeep once you strip out the snarkiness 😄 )

[rreusser]

If I understand, you’re planning an extendDeepExceptSomeArrays which doesn’t just simply do an Array.isArray check, but, uses the above logic.

Correct! Goal: avoid deep merges of data arrays but permit deep merges of things like arrays of transforms.

And thanks for the additional thoughts! As a result and before going farther, I’m going to turn my extendDeepNoArrays into an extendDeepSureWhyNotArraysToo and check the performance. There’s a good chance that this extend deep, though unsatisfyingly inefficient, will not be a limiting factor until long after the number of data points has pushed SVG rendering behind 16ms/frame.

A general principle I’ve been aiming for is to avoid adding any additional iteration through the full data, but if we need to handle webgl much more carefully, then it’s probably poorly-done premature optimization anyway to avoid this.

I don’t know the answer yet, but thanks for bringing up these concerns!