Description
This is a quick sketch of what a fluent interface for plotly might look like. The goal is to simplify the API to make it more usable in JS.
See live example here: http://codepen.io/rsreusser/pen/EgJxwv
Example (shown using constructor which is probably better than what my example actually does):
// Execute calls with chaining:
var p = new Plotly.Plot([{x: [1, 2, 3], y: [3, 1, 2]}])
.delay(500)
.animate([{data: [{y: [2, 3, 1]}]}])
.delay(500)
.animate([{data: [{'marker.color': 'red'}]}])
.delay(500)
.restyle('marker.size', 30)
.on('restyle', function () {
console.log('restyled!');
});
// Or without chaining (but still implicitly chained since that's how methods
// need to be called)
p.delay(500);
p.animate([{data: [{'marker.color': 'green'}]}]);
p.delay(500);
p.restyle('marker.color', 'purple');
// Of course the normal API is unaffected and works fine, but this happens
// *before* the above calls:
Plotly.restyle(p.gd, 'line.width', 6);
Note that this is accomplished without affecting the current plotly API. An approach probably better than my codepen would be to fork things into two paths:
Plotly.plot
: entry point for the current API. Return a promise. No different than the current approachnew Plotly.Plot
: entry point for object-oriented API. Returns an object used as shown above.
With some currying (is that a strictly correct word?), the second really just wraps the methods of the former so that this could be accomplished without any compatibility worries. The object maintains a method queue so that things work pretty much like you'd expect if you're familiar with jquery transitions etc.
Submitted here for the sake of posterity so that this experiment/approach doesn't get lost.