fix bin size becomes 1 (very thin) when data changes with barmode: 'overlay' for histogram by Lexachoc · Pull Request #7507 · plotly/plotly.js · GitHub
When using Plotly.react to update the data of a histogram with barmode: 'overlay', if the traces contain single data points (one point per trace), the calculated bin.size could incorrectly set to 1. This results in the histogram bars becoming visually very thin after a data update.
This issue is particularly noticeable for react-plotly users, where data mutations are frequent.
Changes
This new logic ensures that auto-binning is correctly triggered when usingPlotly.react (for data mutations).
This PR directly fixes the incorrect histogram auto-binning size calculation for single-point traces in overlay mode on data updates. However, it's worth noting that this issue is often triggered by a deeper behavior within Plotly.react concerning layout object reuse. See the Note in #7506.
I found that if the same layout object is reused in Plotly.react calls while the data's axis type (xaxis.type in layout) changes (e.g., from linear to category), the layout object can become "stuck" (stale) with the last-used axis type. For instance, after switching from numeric to string data, the axis type becomes category. When switching back to numeric data, the axis type incorrectly remains category, leading to rendering issues.
The long-term solution might involve changes to how Plotly.react handles the layout object. For now, the good practice for users might be: if your data update might change the axis type (i.e., change the layout), you should also provide a new layout object (or a deep copy) to Plotly.react to ensure correct rendering.
The test case added in this PR (histogram_test.js) intentionally uses data of the same type (linear, auto-detected by Plotly) to specifically test the auto-binning fix when data changes, without being affected by the separate layout reuse behavior.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR fixes #7506
Description
When using Plotly.react to update the data of a histogram with barmode: 'overlay', if the traces contain single data points (one point per trace), the calculated bin.size could incorrectly set to 1. This results in the histogram bars becoming visually very thin after a data update.
This issue is particularly noticeable for react-plotly users, where data mutations are frequent.
Changes
This new logic ensures that auto-binning is correctly triggered when usingPlotly.react (for data mutations).
Before/After
See the fixed look in #7506 (comment).
Note on Plotly.react and layout object
This PR directly fixes the incorrect histogram auto-binning size calculation for single-point traces in overlay mode on data updates. However, it's worth noting that this issue is often triggered by a deeper behavior within Plotly.react concerning layout object reuse. See the Note in #7506.
I found that if the same layout object is reused in Plotly.react calls while the data's axis type (xaxis.type in layout) changes (e.g., from linear to category), the layout object can become "stuck" (stale) with the last-used axis type. For instance, after switching from numeric to string data, the axis type becomes category. When switching back to numeric data, the axis type incorrectly remains category, leading to rendering issues.
The long-term solution might involve changes to how Plotly.react handles the layout object. For now, the good practice for users might be: if your data update might change the axis type (i.e., change the layout), you should also provide a new layout object (or a deep copy) to Plotly.react to ensure correct rendering.
The test case added in this PR (histogram_test.js) intentionally uses data of the same type (linear, auto-detected by Plotly) to specifically test the auto-binning fix when data changes, without being affected by the separate layout reuse behavior.