wishlist for potential breaking changes since v1

[etpinard]

Leave this text box for planned improvements

• upgrade d3 to v4.0.0 (now v5) - should be mostly a matter of updating the general update pattern.
• remove es-promise polyfill from bundle - and thus make IE users add their own Promise polyfill.
• drop jQuery event support
• Make components (e.g. Annotations, Shapes, RangeSlider, ...) register-able and remove them from the core bundle.
• revamp set of default colorscales
• make config arguments consistent Minor inconsistency in config #839
• remove config.plot3dPixelRatio map for backward compatibility
• Incorporate /remove all unofficial exposed methods (i.e Plotly.Plots, Plotly.Fx, Plotly.Snapshot, Plotly.PlotSchema, Plotly.Queue)
• drop event-based Plotly.Snapshot.toImage and merge src/snapshot in plot_api/to_image.js
• remove (some) components for lib/core.js - see Add registry of component modules #845
• drop Plotly.relayout handlers for the 'remove' and 'add' special values - see Consistent container update / removal  #1086
• for log axes, have layout express everything in data units instead of linearized units. This applies to range, tick0, and annotation and image positions.
• remove support for dates provided as epoch milliseconds
• remove the distinction between axis name and axis id (ie xaxis2 vs x2) probably by only using the name.
• rename current gl marker symbol 'cross' -> 'cross-thin' (i.e. revert c0eb065)

[etpinard]

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

[mdtusz]

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 myPlot contains 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 methods Plot.update, Plot.export and 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_case or camelCase (depending on what we choose)

edit: May 3rd

• all positioning in normalized units (margins specifically)

[monfera]

Besides agreeing with the above two lists, based on very limited work, take it with huge grain of salt:

1. 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.
2. Smaller, and to the extent possible, pure functions, immutability as the default.
3. (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.
4. lodash/fp to replace typical, repeating code patterns, it's a painstakingly optimized library, it isn't just using slow [].map etc.
5. 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.

[mdtusz]

To 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!

[cpsievert]

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 plot worked 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.

[meglio]

• 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

[cpsievert]

all positioning in normalized units (margins specifically)

+💯

[etpinard]

Remove our es6-promise polyfill and ask IE9, IE8, IE11 (ref) to use their own Promise polyfills.

[etpinard]

Revamp our set of default colorscales.

[monfera]

⬆️ there is palette overlap between plotly.js and some of its webgl renderers, with a different resolution. Slight restructuring would make room for one shared palette set definition at a finer than current resolution.

[etpinard]

Drop '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);

[etpinard]

Maybe we should drop Plotly.redraw in v2.0.0 ?

[rreusser]

@etpinard 👍 for removing unofficial exposed methods.

[alexcjohnson]

• Specify log axes with data values, not linearized values. ie range [0.1, 100] rather than [-1, 2]. For dates we're doing this in Dates as dates #1078 but I can't see a backward-compatible way to do it for logs. This also applies to annotation and image positions (but shapes already get it right!) and tick0. Perhaps in 2.0 we also remove the compatibility transform that Dates as dates #1078 introduces for dates that supports the old range-as-epoch-milliseconds format.
• Along the lines of "Drop 'add' and 'remove' relayout values" above, drop the built-in coordinate transforms when an annotation or shape has its axis references changed. This is really just for GUI editing so should reside in streambed.

[alexcjohnson]

• rename all the axis objects 'x', 'x2', 'y2' etc. instead of 'xaxis', 'xaxis2', 'yaxis2' so you can go straight from xref/yref to the axis object and we can get rid of Axes.id2name and name2id

In principle this allows us to also change log axis ranges to data values backward-compatibly, since you can't make a log axis without explicitly specifying the container. The only downside I see to this is attribute names are a bit overloaded: trace.x, annotation.x, scene.domain.x etc are data values or arrays of data values, but layout.x and scene.x are axis objects. Doesn't seem too confusing to me but it should be discussed.

[etpinard]

rename all the axis objects 'x', 'x2', 'y2' etc. instead of 'xaxis', 'xaxis2', 'yaxis2'

I'd vote for the opposite. Rename all axis ids 'xaxis', 'xaxis2', 'yaxis2', ...

[mdtusz]

I'd vote for not having "names" that require parsing at all - put them as indexed elements in a list.

[alexcjohnson]

I'd vote for the opposite. Rename all axis ids 'xaxis', 'xaxis2', 'yaxis2', ...

That could work. It gives us the same simplification, clears up the ambiguity, and is a smaller change for users to adapt to. Means we have to do something more clever to manage backward compatibility but maybe that's unavoidable.

I'd vote for not having "names" that require parsing at all - put them as indexed elements in a list.

Like layout.xaxes=[{...}, {...}, {...}]? two things bother me with that idea:

• If you delete an axis, all your references to later axes need to change
• It violates the idea of "simple things should be simple" - almost all plots have only one x axis, and making everyone put that axis into a list just because some other people will make multiple axes is annoying. And then scenes, ternaries, geos that can only have one axis of each type, either the structure is different or they also have that extra list cruft.

[alexcjohnson]

Proposal from @etpinard, came up during stacked area #2960:
Make 'fill' part of the mode flaglist, then the fill value just determines how to fill, not whether to fill.

• 🔪 fill: 'none'
• add 'fill' flag in scatter mode
• add that 'fill' flag the mode default whenever stackgroup is set
• coerce scatter fill (that maybe we should call fills similar to the markers and lines attribute containers) only if 'fill' is part of mode
• make tonexty the only valid fills value when stackgroup is set (tonextx for horizontal stacks). Lib.log something if some other value is set.

I might even go one step further, now that we have orientation (which is so far just used by the stackgroup, and if we did this it would still only have one value within a stack group but outside that it would be a per-trace attribute), we could 🔪 the 'x' and 'y' suffixes, determine that from orientation, and just let fill take values 'tozero', 'tonext', and 'toself'

[etpinard]

PR #2944 added layout.clickmode with default value 'event' which fires plotly_click event when clicking on data points. In v2, we could consider making 'select' or 'event+select' the default enabling click-to-select by default.

[alexcjohnson]

• Remove ALL auto* attributes: if a value is needed and not provided, that's enough to indicate that it should be determined automatically, just like all other defaults. This might be too broad a statement, but I think it's mostly the right goal. There are a few bits of functionality we will need to find a new home for, like autorange: 'reversed'
• And related to this but perhaps not exactly congruent, NO mutations to gd.data or gd.layout during Plotly.plot. This requirement has been hinted at elsewhere in this issue but I don't think it was explicitly stated.

#3044 may serve as a model for this kind of behavior, using _private attributes to stash values determined during calc rather than supplyDefaults

[etpinard]

From #3248

• Stop emitting plotly_selected (with event data undefined) when clicking on graphs under dragmode 'select' or 'lasso.

plotly.js/src/plots/cartesian/select.js

Lines 258 to 262 in 3a32ac0

	// TODO: remove in v2 - this was probably never intended to work as it does,
	// but in case anyone depends on it we don't want to break it now.
	// Note that click-to-select introduced pre v2 also emitts proper
	// event data when clickmode is having 'select' in its flag list.
	gd.emit('plotly_selected', undefined);

[jackparmer]

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

1. v2.0 New styling defaults (colorway, reduce margin size, left-align title, etc) Jan-Feb 2019
2. v3.0 Separate traces and data March-June 2019
3. v4.0 @etpinard 's and AJ's lists of clean up items, plus OO API July - Sept 2019
   wishlist for potential breaking changes since v1 #420 (comment)
   wishlist for potential breaking changes since v1 #420 (comment)
   (+ others in this issue, mostly related to events/callback support)
4. v5.0 Rewrite stack.gl 3d modules in regl, with 3d point selection and tweening transitions in mind Throughout 2019 with Q4 release target

Giving these items plenty of time so that the Chart Studio, Dash, and Plotly.py teams have time to adjust to each major change.

//cc @jonmmease @etpinard @alexcjohnson @nicolaskruchten @chriddyp @bpostlethwaite

[etpinard]

From #3450 (comment) (and cc #3553):

Agreed that the end state should be no text attributes 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 the text attribute (in a major bump).

[jasonleonhard]

Any plans to support react-native? I found a third party dev who build this: https://github.com/rynobax/react-native-plotly any thoughts?

[nite]

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

1. v2.0 New styling defaults (colorway, reduce margin size, left-align title, etc) Jan-Feb 2019
2. v3.0 Separate traces and data March-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?

[jackparmer]

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

[Sank-WoT]

The project is no longer developing?

[alexcjohnson]

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?

[archmoj]

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

[yinshurman]

any plan to support React Native ?