[SIP-76] Proposal for custom dashboard component support

[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: https://github.com/apache/superset/pull/17153

[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!

[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.