You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@dfcreative had this interesting idea from listening to some plotly.js workshop participants today and I thought I'd record it here. Dima, let me know if I got it totally wrong, am missing key parts, etc.
It would be nice if there were a way amateur developers could create and register their own plotly.js traces.
I'm imagining something like the Plotly.py's FigureFactory. Customized traces could be composed using D3 and registered as a trace type at runtime (see pseudocode below).
Right now, to create a new trace type on a Plotly.js coordinates system, the options are labor intensive or at least daunting:
Submit a PR complete with tests, mocks, etc
Fork plotly.js and hack it in
Make a D3 or WebGL chart entirely from scratch, writing your own axes, annotations, zoom/pan behavior, event emitters, and hover labels.
If developers could more easily add their own D3 creations to the Plotly.js coordinate system, such that they were treated like a trace, we'd have a lot more flexibility in helping users prototype ideas and patches without the herculean upfront effort of cementing them monolithically into plotly.js.
I'm imaging something like a Plotly.register routine that adds phylogeny as a trace type at runtime:
Plotly.register({
factory: phyFactory, // function that returns some D3 object
coordinates: 'polar',
type: 'phylogeny',
xaxis: 'xaxis1',
yaxis: 'yaxis1,'
// A bunnnnch of other stuff...
})
Then elsewhere in your JS code, you could add this pseudo-trace to a Plotly DIV like normal, but with a custom data object that gets passed onto the factory function provided in Plotly.register. Something like:
Ideally, as long as the D3 developer followed some guidelines, they would get a ton of boilerplate for free like a superb axes system, hover labels, zoom/pan configurability, and event emitters.
With a way to register D3 modules, users could make their own Plotly-D3 frankenplots. Here's an example: I want my time series to be lines, but I want my rangeslider to be a histogram. Currently this isn't possible - the rangeslider trace type has to be whatever the main plot(s) trace types are. But imagine if I could composite a D3 histogram rangeslider with Plotly.js line charts on the same x-axis system. In pseudo-code, something like:
Plotly.register({
factory: histRangeslider, // function that returns some D3 object or function
coordinates: 'cartesian',
type: 'histslider',
onZoom: updateTimeseries, // callback for zooming in this subplot,
xaxis: 'xaxis1',
yaxis: 'yaxis2,'
// A bunnnnch of other stuff...
})
These modules would be a really nice way to test feature performance and popularity before admittance into the Plotly JSON cathedral. I think we'd also get a lot more JS developer activity if we:
Took away some of the minutia of SVG chart making with our own optimized boilerplate
Provided a less Spartan way to extend Plotly.js
Longterm, the tail of highly specialized chart features is very long and growing. No plot library will ever satisfy every specialist, but maybe a framework is possible for custom extensions.
The text was updated successfully, but these errors were encountered:
To be fair, most of the herculean effort needed to add a new trace type comes from covering edge cases and adding tests: issues that most app developers don't have to care about.
I don't think the current way of adding trace types is that far from being usable to less-experienced devs if we document it properly.
Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson
@dfcreative had this interesting idea from listening to some plotly.js workshop participants today and I thought I'd record it here. Dima, let me know if I got it totally wrong, am missing key parts, etc.
It would be nice if there were a way amateur developers could create and register their own plotly.js traces.
I'm imagining something like the Plotly.py's FigureFactory. Customized traces could be composed using D3 and registered as a trace type at runtime (see pseudocode below).
Right now, to create a new trace type on a Plotly.js coordinates system, the options are labor intensive or at least daunting:
If developers could more easily add their own D3 creations to the Plotly.js coordinate system, such that they were treated like a trace, we'd have a lot more flexibility in helping users prototype ideas and patches without the herculean upfront effort of cementing them monolithically into plotly.js.
For example, say I wanted to add something like this phylogeny tree to my Plotly.js dashboard:
https://bl.ocks.org/mbostock/c034d66572fd6bd6815a
I'm imaging something like a
Plotly.register
routine that addsphylogeny
as a trace type at runtime:Then elsewhere in your JS code, you could add this pseudo-trace to a Plotly DIV like normal, but with a custom
data
object that gets passed onto thefactory
function provided inPlotly.register
. Something like:Ideally, as long as the D3 developer followed some guidelines, they would get a ton of boilerplate for free like a superb axes system, hover labels, zoom/pan configurability, and event emitters.
With a way to register D3 modules, users could make their own Plotly-D3 frankenplots. Here's an example: I want my time series to be lines, but I want my
rangeslider
to be a histogram. Currently this isn't possible - therangeslider
trace type has to be whatever the main plot(s) trace types are. But imagine if I could composite a D3 histogram rangeslider with Plotly.js line charts on the same x-axis system. In pseudo-code, something like:These modules would be a really nice way to test feature performance and popularity before admittance into the Plotly JSON cathedral. I think we'd also get a lot more JS developer activity if we:
Longterm, the tail of highly specialized chart features is very long and growing. No plot library will ever satisfy every specialist, but maybe a framework is possible for custom extensions.
The text was updated successfully, but these errors were encountered: