Based on #2459 due to column settings sidebar refactors.
This PR introduces plugin.can_render_column_styles() in order to remove hardcoded string matching in the viewer.
/**
* Given a column's grouping (determined by indexing it in `plugin.config_column_names`)
* and its view type, determines whether or not to render column styles in the settings sidebar.
*/
can_render_column_styles(
view_type: perspective.Type,
group: string
): boolean;
(from rust/perspective-viewer/src/ts/plugin.ts)
I believe these two parameters are all the possible requirements to determine whether or not a plugin can render column styles. If not, we can always update the API. We need this information to determine whether or not to show the edit button in the settings panel's column selector and on update to determine whether or not to keep the column settings open for that particular column, e.g. if aggregating and the view type changes to something the plugin cannot style.
A future PR will take the same parameters and produce data about which style controls a particular column can have. This will replace #2469, so you can consider this a Part 1 for those changes.
Based on #2459 due to column settings sidebar refactors.
This PR introduces
plugin.can_render_column_styles()
in order to remove hardcoded string matching in the viewer.(from
rust/perspective-viewer/src/ts/plugin.ts
)I believe these two parameters are all the possible requirements to determine whether or not a plugin can render column styles. If not, we can always update the API. We need this information to determine whether or not to show the edit button in the settings panel's column selector and on update to determine whether or not to keep the column settings open for that particular column, e.g. if aggregating and the view type changes to something the plugin cannot style.
A future PR will take the same parameters and produce data about which style controls a particular column can have. This will replace #2469, so you can consider this a Part 1 for those changes.