Plotly.js: `newPlot` does not clear histogram axis type!!!

Created on 7 Dec 2016  路  9Comments  路  Source: plotly/plotly.js

Here are the relevant codepens to reproduce:
http://codepen.io/andrewkfiedler/pen/XNqMeW?editors=0010
http://codepen.io/andrewkfiedler/pen/ObZpzv?editors=0010

In the first codepen, you can see that plotting a histogram of type 'Number' causes future histograms to be assumed to be of type 'Number' as well. As such it throws an error (the second plot is attempted 5 seconds after the first, so wait 5 seconds).

In the second codepen, you can see that plotting a histogram of type 'String' causes future histograms to be assumed to be of type 'String' as well. As such, the numbers are binned as though they are strings.

Both are examples are using Plotly.newPlot.

bug

Most helpful comment

Just to be clear what @etpinard means by "poor user input object management" - the issue is that we mutate the layout object you pass in, so the workaround is to create a new layout object for each newPlot call.

We can only fix this in v2, at which point we can clone data and layout and mutate those rather than the ones you pass in.

All 9 comments

What is the desired behavior here in your mind?

In my mind, Plotly should not crash when switching the type of data used in a histogram. 'Strings' are useful in histograms to bin things into categories, while 'Numbers' are useful to group things into ranges.

Using one type should not cause Plotly to assume that's the type for all future histograms.

I'd actually prefer being allowed to specify the type instead of allowing Plotly to make the decision for me, as right now I have to append a https://en.wikipedia.org/wiki/Zero-width_space in order to force String types that sometimes involve Numbers to be seen as such.

Anything else I can provide to help out on this?

Oh. You're using newPlot. Ok that's bad. Sorry I thought you were complaining about multi-trace graphs being cast to the same axis type. newPlot (as the name suggests) should clean up everything about the previous graphs.

Thanks for the report.

Changing the issue title to attract more attention.

The issue can be replicated all the back be to v1.0.0: not a regression.

We haven't fixed the bug yet, but here's a workaround: http://codepen.io/etpinard/pen/dOwJoZ

Our poor user input object management is responsible for this bug.

Just to be clear what @etpinard means by "poor user input object management" - the issue is that we mutate the layout object you pass in, so the workaround is to create a new layout object for each newPlot call.

We can only fix this in v2, at which point we can clone data and layout and mutate those rather than the ones you pass in.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

tim-sauchuk picture tim-sauchuk  路  3Comments

boleslawmaliszewski picture boleslawmaliszewski  路  3Comments

jonmmease picture jonmmease  路  3Comments

HunterMcGushion picture HunterMcGushion  路  3Comments

maxwell8888 picture maxwell8888  路  3Comments