Repository navigation
wishlist for potential breaking changes since v1 #420
Description
Activity
On my list:
- Incorporate /remove all unofficial exposed methods (i.e
Plotly.Plots,Plotly.Fx,Plotly.Snapshot,Plotly.PlotSchema,Plotly.Queue) - Use proper state object instead of storing state in graph DOM element.
- Add OO API e.g :
var plot = Plotly.createPlot('graph', data, layout, config); plot.restyle(/* */); plot.relayout(/* */); plot.resize(); // ...
- Drop jQuery event support
- Better, more-consistent events data
- Better, more-consistent config options
Reacted by Robert Monfera, Miklós Tusz, Nicolas Riesco, Ducky, Jack Parmer, Anders Dalvander, Jacob Millward-Yuan, Antoine Roy-Gobeil, elv1s42 and Jendrik- Incorporate /remove all unofficial exposed methods (i.e
Ooooooh boy.
- use only d3 modules we need (fingers crossed)
- standardize interfaces across all traces/plots
- svg/gl parity
- no DOM state (virtual dom + diffing would be awesomeeeee)
- discrete process/render modules.
- immutable plot state (i.e. the returned
myPlotcontains methods, plotstate, and history, but it's current plotstate is always overwritten, and old state is pushed onto a history list) - es6 - it's definitely mature enough, and there's a lot of niceties that we could take advantage of
- agreed upon standard lib/prelude
edit: April 14
- logging utils that can be set to either verbose or silent (part of our prelude perhaps). Done
edit: April 22
- slimmed down interface. We could likely reduce the method count to 3-5, namely a constructor
Plotly.plot, and instance methodsPlot.update,Plot.exportand maybe a few others that don't fit as an update.
edit: April 26
- tooling to verify public interfaces meet standards, e.g. checking that all attribute names are
snake_caseorcamelCase(depending on what we choose)
edit: May 3rd
- all positioning in normalized units (margins specifically)
Reacted by Robert Monfera, Nicolas Riesco, Ducky, Carson Sievert, Jack Parmer and buggythepirateBesides agreeing with the above two lists, based on very limited work, take it with huge grain of salt:
- D3 might be used in some places; e.g. category scales/axes could be done via the ordinal scale even if mapping is made to logical points (e.g. the index of the axis tick); sometimes two D3 scales are linked (range of one is domain of the other). Might not work out but D3 scales are pretty powerful, especially in the upcoming D3 4.0.
- Smaller, and to the extent possible, pure functions, immutability as the default.
- (long term) Thinking about reactive visualization, e.g. streaming in new data points into a plot; it would smoothly transition to a possibly enlarged x/y domain; similar behavior with controls. Maybe it's mostly covered, I haven't seen enough. The reason for mentioning it is, it chimes with pure functions and immutability in that it's easier to base dynamic behavior atop of less imperative code.
- lodash/fp to replace typical, repeating code patterns, it's a painstakingly optimized library, it isn't just using slow [].map etc.
- I saw that some Jasmine test require PlotlyInternal (rather than Plotly); maybe worth using the public API for all tests, but again, maybe PlotlyInternal is much like an API except some of it is not (yet) user-exposed.
Reacted by Miklós Tusz, Velizar VESSELINOV and Jack ParmerTo add to @monfera's testing comments - I'm personally not a fan of tests that just test the internal workings of code - they end up being quite brittle and often only ensure that code remains the way it was originally written. I'd love to see tests specific to plotting only use the public API and inspect the returned object - if we no longer keep state in the DOM, this will be infinitely easier as well and rendering tests can be handled separately using mocks (and obviously, maintain unit tests for well specified functions) . As well - without the need for a real browser DOM, we'd be able to run tests (excluding image tests) headless!
Add OO API e.g :
This seems like a good place to discuss smooth transitions as well (requested in #142, and experimented with in plotly/plotly.R#547). It'd be awesome if
plotworked like a d3 selection wrt transitions:plot .transition({duration: 100, ease: 'cubic'}) .restyle('marker.color', 'red')Also, in my mind, transitioning positions (x/y) is the most important use case, so it'd be super useful if
restyle()(or some other method) could also support this:plot .transition({duration: 100, ease: 'linear'}) .restyle('scatter', {x: [1, 2], y: [1, 2]})There are multiple ways to transition a path, but I think I'd almost always want to transition the transform.
Reacted by Kai Brügge- Please allow callbacks for labels, text, values etc, so that their number can be specified and a callback provided to retrieve values, labels, text, hover text etc by index (passed to callback as a parameter).
- Let us build hover text with a callback by index, and allow any HTML in the hover text
Reacted by Calvin Fernandez and jezstarrall positioning in normalized units (margins specifically)
+💯
⬆️ there is palette overlap between
plotly.jsand some of itswebglrenderers, with a different resolution. Slight restructuring would make room for one shared palette set definition at a finer than current resolution.Reacted by etpinardDrop
'add'and'remove'relayout values from adding and removing annotations and shapes.Use e.g:
// to add a blank annotation: Plotly.relayout(gd, 'annotations[2]', {}); // to remove a shape: Plotly.relayout(gd, 'shapes[2]', null);
Maybe we should drop
Plotly.redrawin v2.0.0 ?Reacted by Miklós Tusz42 remaining items
From #3450 (comment) (and cc #3553):
Agreed that the end state should be no
textattributes that only ever appear on hover. But we should look at the traces that currently have no on-graph text and figure out which ones we can imagine adding it to in the future, before actually removing thetextattribute (in a major bump).Any plans to support react-native? I found a third party dev who build this: https://github.com/rynobax/react-native-plotly any thoughts?
Reacted by yinshurmanWe're going to do this in (at least) 4 major releases next year instead of one massive major release. Will have a lot to celebrate by next year's holiday party!
Roughly:
- v2.0 New styling defaults (colorway, reduce margin size, left-align title, etc) Jan-Feb 2019
- v3.0 Separate
tracesanddataMarch-June 2019
Hi - is this still active? Is there an updated roadmap/release date for 2.0.0? Is there RC/branch we could try out?
@nite sorry for the lack of update in this issue. We chose to prioritize new chart types (#2221) this year. We're still searching for a large company or consortium of companies to sponsor a v2 plotly.js API: https://plot.ly/products/consulting-and-oem/
The project is no longer developing?
Very much still developing, in fact we released v2.0.0 last summer and by now we're up to v2.8.3. 2.0 didn't include everything in this wishlist, but it got some of them. Looks like we never updated this issue afterward though.
@archmoj is this issue still useful? Perhaps we could rename it to "breaking changes wishlist" and check off the items that were completed with 2.0? Or, because the thread here is so long, perhaps it'd be better to close this issue and open a new one that collects the pieces of this one that are still relevant?
- changed the title
[-]v2.0.0 wishlist[/-][+]wishlist for potential breaking changes since v1[/+]on Jan 19, 2022 @alexcjohnson Good call. I checked the boxes and renamed the issue.
@Sank-WoT Here is the changelog for v2: https://github.com/plotly/plotly.js/releases/tag/v2.0.0any plan to support React Native ?
Leave this text box for planned improvements
d3to v4.0.0 (now v5) - should be mostly a matter of updating the general update pattern.es-promisepolyfill from bundle - and thus make IE users add their own Promise polyfill.Annotations,Shapes,RangeSlider, ...) register-able and remove them from the core bundle.config.plot3dPixelRatiomap for backward compatibilityPlotly.Snapshot.toImageand mergesrc/snapshotinplot_api/to_image.jslib/core.js- see Add registry of component modules #845Plotly.relayouthandlers for the'remove'and'add'special values - see Consistent container update / removal #1086layoutexpress everything in data units instead of linearized units. This applies torange,tick0, and annotation and image positions.xaxis2vsx2) probably by only using the name.'cross'->'cross-thin'(i.e. revert c0eb065)