Per-group names in groupby transform

[rreusser]

The problem: When you group more than once trace, the legend is confusing. It shows repeated groups without a good indication of which trace they belong to:

More buggily, as @chriddyp points out, if you change trace group names in the legend while in edit mode, they revert because there's nowhere in the schema for the input to go. One solution would be to add a names field for custom group names, e.g.:

"type": "groupby",
"target": ["morning", "morning", "evening", "evening"],
"names": [
  {
    "value": "morning",
    "name": "kale - morning"
  },
  {
    "value": "evening",
    "name": "kale - evening"
  }
]

That at least makes room for the input and seems much less corner-case bound than combining the names into a single string automatically.

On a more UX level, it would be possible to show the legend group name (i.e. parent trace name) and group the traces visually, as in:

+- radishes ---+
| o morning    |
| x evening    |
+--------------+

+- carrots ----+
| o morning    |
| x evening    |
+--------------+

+- kale -------+
| o morning    |
| x evening    |
+--------------+

This solution resolves the UX issue but not the nowhere-for-editmode-input-to-go issue.

/cc @chriddyp @alexcjohnson @etpinard @bpostlethwaite @cldougl for thoughts.

[rreusser]

I like @alexcjohnson's suggestion: nameformat: "kale - %g" that substitutes the group name into %g. The only problem is that we still don't have a place for edit mode input, though that could just be disabled.

[alexcjohnson]

My first reaction would be to do something analogous to tickvals/ticktext:

"type": "groupby",
"target": ["morning", "morning", "evening", "evening"],
"groupvals": ["morning", "evening"],
"groupnames": ["kale - morning", "kale - evening"]

A more concise but restricted way would be a custom string substitution:

"type": "groupby",
"target": ["morning", "morning", "evening", "evening"],
"nameformat": "kale - %t"

But yeah, that wouldn't allow editing via the legend, that would have to break out of the substitution format and convert it to the groupvals/groupnames version.

[rreusser]

Agreed, but to clarify, I'd favor just converting the one that was edited into groupvals/groupnames and consider those overrides. To get rid of it, you'd delete the text and it'd revert to the automatically named format.

[alexcjohnson]

I'd just convert the one that was edited into groupvals/groupnames and consider those overrides. To get rid of it, you'd delete the text and it'd revert to the automatically named format.

That could work. I wonder if there's some smart way we could figure out to have the first edit set nameformat (if the appropriate target value is in the name) and then subsequent edits generate overrides? Dunno though, I can think of a bunch of edge cases where that would be unhelpful so maybe not.

[cldougl]

did the financial types (ohlc and candlestick) have a similar problem?

[rreusser]

@cldougl I think perhaps they did. I'm not too familiar with them, but the legend naming code explicitly checks for and handles ohlc/candlestick plots.