[ENHANCEMENT] Table: organize column settings in groups

[andreasgerstmayr]

I'm going to add a few new settings to the column settings page (formatting settings, panel kind), and it would get a bit unorganized, therefore I updated the column settings editor to use the standard grouped options we have in the other panel editors:

Screenshots

Before:

After:

[Gladorme]

LGTM.
Note for myself, find a way to improve readability of desc inputs

[AntoineThebaud]

This is a bit a hack / not aligned with what we have for e.g TimeSeriesChart, where the different categories map to an attribute in the model, cf

and

With Dashboard-as-Code in mind this might get confusing if the UI and the model start to shift to much from each other. I dont say we should revert this, but that's something to consider when doing such change imho

[andreasgerstmayr]

With Dashboard-as-Code in mind this might get confusing if the UI and the model start to shift to much from each other. I dont say we should revert this, but that's something to consider when doing such change imho

I think the column settings grew organically. What do you suggest to sync them?

• ungroup the settings, at the expense of a less organized UI, or
• update the schema and write a migration script?

We already have few migrations here: https://github.com/perses/plugins/blob/main/table/schemas/migrate/migrate.cue but I'm not sure how it works, as we don't version the schemas. Is the migration code looking if some property exists and then infers that this was a valid schema at time X?

[AntoineThebaud]

I think the column settings grew organically. What do you suggest to sync them?

* ungroup the settings, at the expense of a less organized UI, or

* update the schema and write a migration script?

We already have few migrations here: https://github.com/perses/plugins/blob/main/table/schemas/migrate/migrate.cue but I'm not sure how it works, as we don't version the schemas. Is the migration code looking if some property exists and then infers that this was a valid schema at time X?

Sorry for the delay in replying, had to take some time to organize my thoughts here :D

The migration schema you mentioned is exclusively for grafana to perses migration. Although it's foreseen we may need this at some point we don't have yet schemas for perses vN -> perses vN+1 migrations.

The solution is definitely not to ungroup the settings on the UI, I think your change here was great. So yes I'm talking about breaking change(s) on the model side..

I tried to come up with a solution that satisfies these aspects:

• achieve the best possible consistency between UI & model,
• achieve the best possible consistency across all official plugin models,
• minimize the chances of future breaking changes.

..And in the end I think the most robust solution is to avoid having a visual attribute on the model side. This category is quite ambiguous, actually most if not all settings of a panel plugin spec are "visual" settings somehow.. So on the UI you could use this Visual category to group "standalone" settings that don't fit in a better category, but in the model side we should define parent attributes only when it really makes sense & there's no ambiguity about where a setting should go. Because anyway if at some point we continue adding customization options to a given panel, then the Visual part may get to big on the UI and you may want to further split it, causing either new breaking change OR misalignement between UI & model..

So all in all I think the Table panel is fine as is, and that we should align the other panel plugins on it by ungrouping the settings currently gathered under visual?: #visual (currently concerns 4 plugins)