[SIP-76] Proposal for custom dashboard component support

[amitmiran137]

[SIP-76] Proposal for Dynamic dashboard components

Motivation

Today there is a very narrow list of components that can live within dashboards: charts, Row, column , tabs, header, markdown and divider
as part of our dashboard requirements at Nielsen we want to add another non-chart component that shows a summary of the active filters within the dashboard for display purposes as described in here
but shortly we understood that it would be hard to get those accepted and aligned with the superset community and adding such components would require maintenance and burden over time.

Proposed Change

So we decided on a less invasive approach that allows adding custom dashboard components into the dashboard similar to
the plugins system that exists for charts and native filters today
each custom component will have access to the dashboard state and would be able to leverage its state.
the advantage here, comparing the filter summary bar is that dashboard components can be written externally to superset and will not be part of the superset-frontend system which will keep it stable

similar to custom plugins, it will be up to the developer to integrate those components into superset and load them into superset they way they see fit
this will open a new type of ideas that can leverage the dashboard state and show dashboard in ways that we're never seen before

New or Changed Public Interfaces

setupDashboardComponents.ts file would be a file in which you would register your custom components in the following approach

import dashboardComponentsRegistry from '../visualizations/presets/dashboardComponents';

export default function setupDashboardComponents() {
  dashboardComponentsRegistry.set('test', test);
}

the interface for any component will as the following

type DashboardData = {
  nativeFilters: NativeFiltersState;
  dataMask: DataMaskStateWithId;
};

we will decide about interface expansions as we evolve
there would be a conversion function from the dashboard state to the interface mentioned above

Migration Plan and Compatibility

Rejected Alternatives

creating dashboard components directly into the superset source code like the following PR:
#17153

[suddjian]

I love the idea of adding more capabilities for plugins!

Maybe we can add more detail on exactly what kind of props should be passed to these components. Do we pass the entire dashboard state? That would make any refactor to dashboard state a breaking change. The dashboard state and component structure is an area with a lot of unpaid technical debt that makes things excessively complex, so hardening that by making it public is somewhat concerning.

[EBoisseauSierra]

What a great idea!

Do you envision these components could accept user inputs (e.g. via HTML's <input />) that could be passed back to charts/queries?

[amitmiran137]

I love the idea of adding more capabilities for plugins!

Maybe we can add more detail on exactly what kind of props should be passed to these components. Do we pass the entire dashboard state? That would make any refactor to dashboard state a breaking change. The dashboard state and component structure is an area with a lot of unpaid technical debt that makes things excessively complex, so hardening that by making it public is somewhat concerning.

I've added an example on the dashboardState param we intend to pass to the components
all was taken from the ready to review PR for this SIP:
#17208

[villebro]

I think this is a really nice idea! One thing that I think we should add clarity to is what type of customizable metadata/state (=formData) the dashboard components will support. Based on the description, IIUC, it appears the dashboard plugin wouldn't have any formData similar to the current markdown component or regular chart plugins. However, I'm sure this need will inevitably come up. Also, if we can agree on a system that supports similar customizable metadata to current viz plugins, maybe dashboard components could evolve to become the viz plugin 2.0 over time, providing e.g. inline editing in the dashboard (as opposed to Explore view) etc.

[cccs-jc]

Agreed opening up the dashboard components would enable these usecases. Love it!

Dynamic header component in dashboards
#15006

Add a vertical header control to the dashboard
#13646

[amitmiran137]

So much excitement this is nice !!
We are having a meetup on Monday to discuss the topic in details

If anyone interested joining let me know

[villebro]

Another idea that came to mind for a nice dashboard component: a legend component showing the colors for labels on the currently active tab/hovered chart. Since Superset charts on a dashboard always share the same color (this is coordinated by the color registry), it would be nice to have just one legend component as opposed to having a dedicated legend on each and every chart.

[amitmiran137]

We have just had our first focused meetup around this proposal
the open issues are:

1. decide open the interface between superset and custom dashboard components
2. we would version that interface by announcing breaking changes in superset
3. we would have a conversion function between the actual dashboard state props to the interface mentioned above

[mail2lawi]

Agreed opening up the dashboard components would enable these usecases. Love it!

Dynamic header component in dashboards #15006

Add a vertical header control to the dashboard #13646

#17233 as well

[amitmiran137]

I'm share a doc which inside we will collaborate on the final interface that a dashboard component should have
https://docs.google.com/document/d/1ixGJNToIA51m88VrU_oAj7GopsUq9jcvX_w6ZXOC3OA/edit?usp=sharing

@suddjian @villebro @rusackas @michael-s-molina

[amitmiran137]

Vote has started

[rusackas]

Closing the issue due to a successful vote! 🎉 Thank you for taking this on!

I think there will be more and more and more reasons to add plugin capabilities to Superset. The part that interests me greatly about all of this would be a chance to revisit the architecture for a Dynamic Plugin ecosystem, where references to external modules could be stored/managed in a table. We started doing this for Dyanamic Viz Plugins, but this is due for a revisit now that superset uses Webpack 5 and is capable of Module Federation and promise-based dynamic remotes.

I don't want to put any undue burden on your efforts to achieve your business goals, but I think Superset and its community would benefit greatly from such an architecture revamp. In effect, anyone could publish a plugin on GitHub, and any Superset User could use leverage all of this work/capability. If you'd like to explore further, let's talk on Slack!