rusackas commented on issue #33900: URL: https://github.com/apache/superset/issues/33900#issuecomment-5553506385
@jansule @villebro circling back on this, since I'd like to decide whether this becomes a scoped issue or a fix PR. Reading `master`, the root cause looks pretty simple: the cartodiagram calls the referenced chart's own `transformProps` once per location, and each of those calls does `CategoricalColorNamespace.getScale(colorScheme)`, which hands back a brand new scale. Color assignment and the collision check both live on that scale instance, so every pie starts over at color zero. The shared `LabelsColorMap` only helps for labels it has already seen, which is why pre-seeding it through a single scale (your fork) works on a dashboard and nothing works in explore. The shape of a fix seems to hinge on a few questions. Should the sub-charts of one cartodiagram share a single label to color mapping, and is that scope the cartodiagram's own `sliceId` (like your fork) or a new scope in core that sits between one scale and the whole dashboard? If a cartodiagram on a dashboard seeds the shared map, those labels will get persisted into the dashboard's `map_label_colors`, which might be fine, but I'm not sure it's what we want. And is there a sane way for a parent chart to hand a scale down into a child's `transformProps`, rather than the plugin copying the echarts label formatting just to register labels ahead of time? That last one is the difference between a plugin-only patch and a `superset-ui-core` API change that every plugin would feel. Curious which way you'd lean, since this is squarely in the color scheme architecture, which is... complicated. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
