Range slider data update fix #1350
Conversation
- instead of `(!rangeslider.range)`-based criterion - which allows for data update to correctly expand the range slider - rm now useless axis.autorange criterion for _needsExpand
| @@ -82,7 +82,7 @@ module.exports = function(gd) { | |||
| // compute new slider range using axis autorange if necessary | |||
| // copy back range to input range slider container to skip | |||
| // this step in subsequent draw calls | |||
| if(!opts.range) { | |||
| if(axisOpts._needsExpand && axisOpts._min.length && axisOpts._max.length) { | |||
There was a problem hiding this comment.
As the computed range slider range (i.e. opts.range here) is copied to the user layer container, Axes.getAutoRange would not get called on data array updates (unless one would delete gd.layout.xaxis.rangeslider.range).
Note that xaxis._min and xaxis._max are only defined when an update call passed through the calc step as setConvert clears them here in supplyDefaults.
| xaxis: { rangeslider: { range: [-1, 11]} } | ||
| }) | ||
| .then(function() { | ||
| assertRange([-0.13, 2.13]); |
There was a problem hiding this comment.
A bit confusing, as it looks like this test is identical to the previous one until you squint at the details of assertRange. Nonblocking, but I might have made it explicit by saying assertRanges([-0.13, 2.13], [-1, 11]) or something.
|
💃 |
|
This fix doesn't work for soon-to-be-added multiple range sliders #1250. I'm working on a better solution, possibly by adding |
|
Dropping from the This bug fix will be part of the multiple range slider #1250 feature PR. |
fixes https://github.com/plotly/streambed/issues/9088
A very subtle change that ensures that new range slider ranges are computed under data array restyle/addTraces/expandTrace/deleteTraces updates.