Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Needs discussion: Registering bespoke trace types #2174

Closed
jackparmer opened this issue Nov 20, 2017 · 2 comments
Closed

Needs discussion: Registering bespoke trace types #2174

jackparmer opened this issue Nov 20, 2017 · 2 comments

Comments

@jackparmer
Copy link
Contributor

jackparmer commented Nov 20, 2017

@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.

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 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:

Ploty.plot( [{
    type: 'phylogeny',
    data: newickJsonString,
    innerRadius: ... // etc
}] )

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.

@jackparmer jackparmer changed the title Needs discussion: Registering custom trace types Needs discussion: Registering bespoke trace types Nov 20, 2017
@etpinard
Copy link
Contributor

etpinard commented Nov 20, 2017

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.

@gvwilson
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants