docs(colorbar): log/date dtick string forms are not supported on color bars - #7991
Open
CAOShurong wants to merge 2 commits into
Open
docs(colorbar): log/date dtick string forms are not supported on color bars#7991CAOShurong wants to merge 2 commits into
CAOShurong wants to merge 2 commits into
Conversation
Copy link
Copy Markdown
Contributor
Sorry, something went wrong.
The warning compared the layout getter sankey.nodePadding() against the configured node.pad. Since @plotly/d3-sankey 0.12.3 (plotly#7830) that getter returns the *configured* value (the post-clamp padding lives in an internal variable), so the comparison never fired and users no longer learn their pad was reduced. Measure the smallest gap between consecutive nodes sharing a column instead: it reflects the effective padding and works for both @plotly/d3-sankey and @plotly/d3-sankey-circular. Fixes plotly#7832
…ported on color bars The colorbar tick axis is mocked with type 'linear' (mockColorBarAxis in src/components/colorbar/draw.js), and clean_ticks.dtick silently falls back to the default step for any non-numeric dtick on a linear axis. So the *L<f>*, *D1*, *D2* (log) and *M<n>* (date) special strings that the shared dtick description advertises have no effect on colorbar.dtick or coloraxis.colorbar.dtick - they even degrade to a 1-unit linear step, producing one garbage label per pixel of bar length (issue plotly#7376). Give the colorbar dtick attribute its own accurate description: only positive numbers are honored. Regenerate test/plot-schema.json and the TS types accordingly.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Reviewers
At least 1 approving review is required to merge this pull request.
Assignees
2 participants
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.
Fixes the documentation half of #7376.
colorbar.dtick (and coloraxis.colorbar.dtick) inherits its description from the cartesian dtick attribute, which advertises the special log forms (L, D1, D2) and date form (M). None of them works on a color bar:
Measured behavior (verified against this branch's parent with a jsdom harness, heatmap spanning 10^0 to 10^9): setting colorbar: {dtick: 'D1'} does not error and does not produce decade ticks - it degrades to a 1-unit linear step over a z-range of 1e9, i.e. ~56 million candidate tick labels (the renderer draws one garbage label per pixel of bar length, e.g. -0.056233M). The identical dtick: 'D1' on a real log y-axis produces correct decade + minor ticks, confirming the colorbar path is the broken one. Numeric dtick values work fine on the same color bar.
This PR gives the color-bar dtick attribute its own accurate description: only positive numbers are honored; the log/date string forms are silently ignored. No behavior change. test/plot-schema.json and the generated TS types are regenerated accordingly (the schema diff is exactly the new description).
If maintainers would rather implement log-scale color bars than document the limitation, the mock axis type is the single place to start - happy to attempt that instead. But as long as strings are accepted-and-discarded, the docs should not claim they work.