I have some scatter chart which uses the range/autorange feature only for one end of the y-axis. The upper end range is set to 100, while to lower end should be dynamically/auto-ranged.
This is working fine, if only a single line is shown in a chart. As soon as I add a second line with its own y-axis, the first line seems to have autorange enabled for both ends of the axis, i.e. the range: [null,100] configuration is ignored.
I’ve created a simple demo on CodePen to show the behavior. Initially only a single line is shown and the y-axis ranges up to 100. As soon as you enable the second line and axis by uncommenting line 8, the range for the first y-axis changes unexpectedly.
Is this a bug or do I miss something that needs to be set to keep the desired behavior?
I’m not sure I understand well but I think this is what you are looking for, just comment out the two autoranges and the anchor: ‘free’ and uncomment your second axis
The anchor: 'free' was the problem. Removing this entry solves the problem and the autorange-feature is working as expected. (The two autorange entries were not necessary but didn’t harm.)
Not sure why I had the anchor: 'free' in the example. It was probably left over from other experiments.
Anyway, could you please explain the anchor property to me and why this effects the autorange? The documentation isn’t of much help. It only references the position property.
The solution proposed by @Saratoga only works, if I have at most two y-axes. Once a third axis is added, I need anchor: 'free' to position the axes correctly.
I’ve created another CodePen to show the problem: at first two traces on separate y-axes are shown. Range is always set to [null,200], which means upper bound is 200 while lower bound is dynamically.
As soon as you enable a third trace with a third axis (by uncommenting line 10), the range of the first two axes changes unexpectedly.
The question remains: why does anchor: 'free' affect range/autorange? Is this a bug?
Thanks for your answer once again. Unfortunately I don’t see how your example would help me in any way. It doesn’t use a range attribute at all, which is the actual problem.
I try to rephrase my problem, maybe this will help: I start with a chart with only a single trace and a single y-axis which is partly autoscaled by using (for example) range: [null,200] and autorange: 'min'. Depending on the actual data the lower boundary of the rang is calculated dynamically, while the upper boundary is always at 200. This works fine and looks like this:
When I add more traces with a separate axis for each, I use autoshift: true to position the axes accordingly. As described in the documentation, autoshift implies to set anchor: 'free' . But with anchor set to free the fixed range stops working and the upper boundary is also calculated dynamically, just like the lower one. This looks like this:
I can avoid the usage of autoshift and anchor: 'free', but positioning of axes gets complicated then. And I guess that’s the reason why those attributes were introduced. So I really think there is a bug in plotly regarding this. That’s why I created issue #7296.
As far as I can tell, your most recent example is a valid workaround for the fixed-range problem by avoiding the use of the mentioned attributes for axes positioning. It seems to work regarding the fixed range, but has other problems: 3rd axis has no line visible, enabling the legend overlaps the axis. Probably those problems could also be worked around, but I prefer a real fix rather than implementing one workaround over the other.
(You also added an event handler to update some chart properties on resize of the graphic. Maybe this is another bug. Problems regarding resizing were not my initial problem.)
So my conclusions for now are:
There is a bug regarding fixed-range when autoshift/anchor:'free' is used.
There are workarounds to get fixed-range working again.
The workarounds make axes-positioning significantly harder.
Regards,
Martin
PS: The problem exists also with Plotly.JS 2.35.3 and 3.0.1.
Last attempt, it is definitely a bug like many others out there, the problem is that there are many bugs that are already many years old and still have no solution, so the only thing left for you is to look for a temporary remedy or wait until they fix it, many times the errors occur when you resize the graph area or when you call a Plotly function either directly (update, relayout, restyle) or indirectly (modebar, updatemenus, sliders), in some cases it deletes the data you configured and puts the default ones, the solution in these cases is to reestablish them to the values that you had configured in the plotly_relayout event when they are changes that affect the layout, in the plotly_restyle event when they are changes that affect the plot data, in the previous example I put the annotation and many of the posts that I have solved have similar bugs, the values that you configure are deleted and the default ones are put and that had been without a solution for years, so well I leave you this Last solution applying the properties you need and fixing the bug by rewriting the values again in the relayout event, you will know if you apply it or if you want to wait for it to be fixed
Your last post gave me a lot of insights from an expert user, especially the part about when “many errors occur” and “still have no solution”.
I really would like to see the bugs fixed. And if I find the time, I’ll try and fix it myself and create a pull-request. Unfortunately I’m not very familiar with the plotly source-code by now.
For now, I’ll probably live with your proposed workarounds, which at least showed me the way…
Kind regards,
Martin
PS: As your last example solves most all mentioned problems, I’ll mark it as “solution”.
