Fix multicategory axis second-level category ordering - #7931
Conversation
Sorry, something went wrong.
On a multicategory axis, second-level categories were keyed on where each label first appears anywhere in the data, so every first-level category rendered the same child sequence regardless of its own data order. Track children per parent instead: collect parents in first-appearance order and each parent's children in the order its own data supplies them, then emit the pairs directly - no flat row list and no sort needed, as setCategoryIndex already dedups. The lookups are now prototype-less objects, so a category named e.g. 'toString' no longer resolves through Object.prototype and ends up without an index. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VuN1reWCtHE6WFsNZjdGCD
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VuN1reWCtHE6WFsNZjdGCD
|
Authored by Claude Code (Fable) CI status: everything is green except test-baselines / test-baselines-b64, which fail on exactly the three expected mocks — multicategory2, multicategory-y, multicategory-sorting — i.e. the known blocker from the PR description, nothing else. The good news: CI has already rendered the corrected baselines itself. The baselines-default-diff artifact (156 KB) from the failing run contains exactly six files — the three CI-rendered replacements under test_images/ and the three visual diffs under test_images_diff/ for eyeballing. So no local kaleido run is needed; to finish this PR:
Since the PNGs come from CI's own renderer, test-baselines and test-baselines-b64 should both go green on the next run. I'll keep watching and confirm. Generated by Claude Code |
Sorry, something went wrong.
Written with Claude Code
Split out of #7929 (the fix half; the categoryorder/categoryarray feature follows separately) after review discussion there concluded the two changes should be weighed independently.
Overview
On a multicategory axis the second-level categories share one global ordering, keyed on where each label first appears anywhere in the data. Every first-level category therefore renders the same child sequence, regardless of its own data order.
Minimal case — data order is P1/b, P1/a, P2/a, P2/b:
P2 is flipped: b was seen first under P1, so b precedes a under every parent. Real-world shape: months under years supplied in strict chronological order starting mid-year render every year in the first year's month order. Reported downstream at plotly/dash-ai-analyst#171.
The fix
setupMultiCategory in set_convert.js now tracks second-level categories per parent: parents are collected in first-appearance order, each parent's children in the order that parent's own data supplies them, and the pairs are emitted directly. Since setCategoryIndex already dedups, this removes the flat row list and the sort from the previous implementation rather than adding a second level of index maps to it — net simpler and O(n).
The category lookups are also prototype-less now, so a category literally named toString no longer resolves through Object.prototype (previously it never received an index, producing NaN comparisons in the sort).
Tests
Two new Axes.makeCalcdata specs: per-parent ordering and the toString prototype case.
Baselines — needs a maintainer
Three committed baselines encode the bug and need regenerating (per #7929's regression sweep of all 1067 non-gl3d/map/geo mocks, these are the only three multicategory orderings that change):
multicategory2 supplies 2018 q1, q2, q3 and the committed baseline shows q1, q3, q2. Sandbox-generated baselines don't match CI's font rendering (a control regeneration of an untouched baseline differed by ~11k pixels), so:
🤖 Generated with Claude Code
https://claude.ai/code/session_01VuN1reWCtHE6WFsNZjdGCD
Generated by Claude Code