Add optional redraw parameter to extendTraces/prependTraces

[drderiv]

An optional parameter has been added to extendTraces and prependTraces that specifies whether the graph should be redrawn after a new group of traces has been appended or prepended, as the case may be. This can be useful when the time to redraw cannot keep up with the frequency in which new data arrives, or when data arrives so fast that updating the graph with each trace addition is distracting. Importantly, this change is backwards-compatible with any prior version, as the optional redraw parameter defaults to true, thus, unless explicitly set to false, graphs will continue to be redrawn after each trace addition.

[alexcjohnson]

Thanks @drderiv - this is an interesting concept and clearly useful! I'm a little worried about it though, as the user would need to be pretty careful to end any particular chain of operations with redraw=true, otherwise some data would be missing when the graph looks static.

What if we instead added a throttle parameter, that specified a minimum number of milliseconds between redraws but then we could schedule one last update to happen that much time later if no more data arrives? And it would default to zero to match the current behavior.

[drderiv]

To clarify your concern, it's that a user does a chain of extendTraces, for example, explicitly setting redrawGraph=false along the way, and then fails to make a call with either no redrawGraph specification or redrawGraph=true and thus the graph does not get updated?

The way I am currently using it is like this: Plotly.extendTraces(graph, data, [0], undefined, counter++ % 10 == 0), with calls to the function being event driven when new data is available. It's true that if data stops flowing for some reason there could be, in my example, up to 9 un-plotted points that may never show up. I do believe your suggested solution would solve that issue and can't think of any negatives associated with that off the top of my head.

[gvwilson]

@alexcjohnson any further thoughts on this one? thanks - @gvwilson

[alexcjohnson]

Ah, I missed that @drderiv reworked this in line with my suggestion - thank you! This looks great. I haven't tested it, but assuming it works as intended I'm quite happy to accept this.

I suspect adding a programmatic test of this will be tough - and the change is only in the non-default setting anyway, so manual testing may be the best way to handle this one.

[gvwilson]

thanks @alexcjohnson - much appreciated