Fields missing in fullData

[dmt0]

1. Missing marker.colorbar.tickfont.color
   https://codepen.io/dmt0/pen/djNNpa?editors=1010 - done in Add missing fields to fullData #2850

2. For Violin plots missing:

• bandwidth
• span
• box.* done in Add missing fields to fullData #2850
• meanline.* done in Add missing fields to fullData #2850

https://codepen.io/dmt0/pen/MBpxLv?editors=1010

3. For choropleth:

• marker.line.color

[etpinard]

Missing marker.colorbar.tickfont.color

Yeah, that one sounds like a bug

For Violin plots missing:

bandwidth
span

Those are computed fields. They don't have a fixed default. Their values are punching in gd.calcdata[i][j].t not gd,_fullData. We could copy them back in fullData to make the editor happy, but I'm afraid similar issues are going to come up in other trace types. How does the editor handle other computed values like axis dtick, tick0, histograms xbins etc?

meanline.*

That's the expected behavior. We remove the meanline. container when the violins don't have mean lines:

plotly.js/src/traces/violin/defaults.js

Lines 51 to 54 in dcaebc2

	var meanLineColor = coerce2('meanline.color', lineColor);
	var meanLineWidth = coerce2('meanline.width', lineWidth);
	var meanLineVisible = coerce('meanline.visible', Boolean(meanLineColor || meanLineWidth));
	if(!meanLineVisible) delete traceOut.meanline;

[etpinard]

meanline.*

That's the expected behavior

Oh wait, maybe having gd._fullData[i].meanline.visible = false would have more sense for the editor instead of removing the container completely.

[etpinard]

... would be nice to talk about these during the weekly meeting on Thursday 📆

[etpinard]

generated pie marker.colors are also missing from fullData: https://codepen.io/veraz/pen/YjxgvE?editors=1010

cc @VeraZab

[etpinard]

Pie marker.colors, violin span, bandwidth all fall under the same category: their defaults are computed during the calc step (which occurs after Plots.supplyDefaults) and reside in gd.caldata, not gd._fullData.

These attributes differ from e.g. contour's contours.(start|end|size) or histogram's (x|y).bins which have their default values computed in calc but punched back into gd.data to preserve the correct autocontours / autobins behavior.

So, I see two possible solutions:

• Punch in the computed marker.colors, span and bandwidth, write a test in plotly.js and be done with it. This seems like a good solution if we consider marker.colors, span and bandwidth exceptions in the plot-schema. This seems fair as I can't think of any other attribute that behave that way. But we wouldn't be immune to similar problems when adding new trace types.
• Add a key in the plot-schema (e.g. calcDflt: true) and have the react-chart-editor handle those attributes separately. This key could also be valuable to https://plot.ly/javascript/reference/

About marker.colors, #2205 seems to suggest that punching in the "computed" default into fullData might throw off Plotly.PlotSchema.findArrayAttributes, but I can't remember what were the consequences.

cc @nicolaskruchten @VeraZab @dmt0 @alexcjohnson

[alexcjohnson]

We can't just fill these into fullData during calc, or Plotly.react will break (ie it will always think these attributes changed, because it's looking at newFullData immediately after supplyDefaults and comparing it to oldFullData after the plot is finished.

A calcDflt schema property might help, though if we do this AND fill the values back into fullData we'll still have a problem figuring out if the value is the default or not - the user inserts a non-default value, then removes it via Plotly.react - we see no value in newFullData and a value in oldFullData, how do we know if that old value is the default or was given explicitly? We could create trace._dflt_bandwidth = false or something...

If we make calcDflt but do NOT fill the value into fullData, how is the editor going to find the value, or even know that it should be expected to look for a value? Doesn't seem like a good idea to force it to reach into calcdata. So I feel like ^^ or something like that would work better.

Pie marker.colors is a tricky one. In addition to the question about findArrayAttributes, subsequent pies can affect each other. If you provide colors for the first pie trace (or even if you don't), any later pies with matching label values will inherit the same color if you don't override it, but previous pies will not. That means even if we manage to pull out the relevant color array, if someone uses that as the base to edit these colors, it could give unexpected results where a user expects to alter the color for all slices of a given label but ends up only altering some of them. We could fix that order dependence, but there would still be an ambiguity then if someone set the color for a certain label in one trace and then changed it in another trace - do they intend both to take the new color, or just one? What if there are 3 pies, you set a color first on the second pie, then you set a different color for the same label on the first pie, then the 3rd will inherit the new color?

Or that's how it's supposed to work anyway... looks like there's a bug where explicit colors don't get propagated correctly, though default colors do. In this test here, the orange 'a' should be red, looks like the mechanism that's supposed to make this work (fullLayout._piecolormap) is getting the wrong key (undefined) somehow:

Anyway, aside from making the editor happy, I'm not sure if it matters whether marker.colors defaults are included in fullData. Pie hover events already report the color either way, does it have other meaningful effects? For the editor's sake, seems like we may want to have one (very special) control based on fullLayout._piecolormap that figures out how to set these colors unambiguously, unless we think there's an important reason to support per-trace colors for matching labels.

[nicolaskruchten]

For the editor's sake, seems like we may want to have one (very special) control based on fullLayout._piecolormap that figures out how to set these colors unambiguously

Bingo, I think we just didn't know where that secret key was. /cc @VeraZab this is a more stable approach than my 'copy the colorway' hack :P

[nicolaskruchten]

@alexcjohnson it looks like _fullLayout._piecolormap gives a cross-pie view and we'll have to stitch the actual ordered scale back together... is there some internal function we can use that gives us the colors, in order, for a given pie trace?

[nicolaskruchten]

If not, we may just display the colorway for this particular component if nothing is stored in data... it's "close enough" :)

[etpinard]

Editor devs, is adding violins to the chart editor a high priority?

If so, I'm thinking of simply mutating the computed span and bandwidth default values back into gd._fullData and gd.data similar to how we currently handle histogram bins and contour levels.

[alexcjohnson]

it looks like _fullLayout._piecolormap gives a cross-pie view and we'll have to stitch the actual ordered scale back together...

yes, that's exactly the reason I suggested it - because that's the only way to unambiguously set the color for a label, without wondering whether it will apply to one, some, or all pies that share that label.

is there some internal function we can use that gives us the colors, in order, for a given pie trace?

No, but you could pull them out of calcdata.

If not, we may just display the colorway for this particular component if nothing is stored in data... it's "close enough" :)

As long as you're not worried about these changes propagating to non-pie traces, and as long as this pie isn't inheriting colors from another one. To me though those seem like pretty substantial caveats!