Minor fixes to allow null frames internally#1121
Conversation
|
fyi @rreusser you'll need to merge master to make
pass again. |
| for(i = 0; i < trans._frames.length; i++) { | ||
| frame = trans._frames[i]; | ||
|
|
||
| if(!frame) continue; |
There was a problem hiding this comment.
so, technically, not just null is special. Any non-numeric i would make trans._frames[i] falsy?
There was a problem hiding this comment.
i can't be non-numeric since it's the array index. This is a check to see if the accessed frame is falsey. Perhaps a better check is if (!Lib.isPlainObject(frame)).
|
Making I wonder though, if we could expose a way through |
|
Short answer… no. I don't see any way to accomplish this without structural changes to animation. As discussed previously, I think the solution would be frames that you would toggle on/off. On each data -> fullData step, it would merge any 'on' frames. Turning the frames off would restore it to the original state. |
|
Thanks for the reply @rreusser
This would certainly make Perhaps (or not) this could as easy as adding a |
|
Yeah, I think with all the other machinery in place and with a much better understanding of what we're after that this might actually not be so difficult. The reason this wasn't done to begin with is that one solution cannot handle both ephemeral update-and-forget-about-it updates and stateless toggle updates. I think it would be worthwhile though. |
Conflicts: test/jasmine/tests/animate_test.js
|
💃 |
2 participants
This PR adds a small test and a couple fixes to prevent plotly from breaking on null frames. This is necessary for transforms that directly add or remove frames. If they remove frames, they should avoid compressing the array so that indices don't change. This means
nullorundefinedentries in the frame array should simply be ignored.