[SIP] Proposal for Modernizing Control Panel Architecture using React Components

Motivation

The current control panel architecture in Apache Superset relies on a configuration-driven design, where controlPanelSections define controlSetRows as arrays of strings or configuration objects in superset-frontend/plugins/plugin-chart-word-cloud/src/plugin/controlPanel.ts. While this approach is functional, it has become increasingly rigid, difficult to maintain, and misaligned with modern frontend development practices.

String-based controls (e.g., ['color_scheme']) are indirectly mapped to React components through control registries, creating unnecessary indirection and making the code harder to trace and refactor. Similarly, object-based configurations define control metadata but are not React components, which limits composability, reusability, and dynamic interactions.

By moving to a React component-based approach, Superset can modernize its control panel architecture to be more modular, testable, and maintainable. This change will improve developer experience, streamline debugging, and enable richer interactions using React’s state management features such as hooks and context.

Proposed Change

We propose to modernize the control panel architecture by incrementally replacing configuration objects and strings with React components.

The first step will be a proof of concept (POC) for the Word Cloud control panel, where each control (e.g., rotation, color scheme) will be defined directly as a React component such as <RotationControl /> or <ColorSchemeControl />.

The rendering logic in superset-frontend/src/explore/components/ControlPanelsContainer.tsx will be extended to detect and render both legacy configuration objects and React components. This ensures backward compatibility and allows for a gradual migration without breaking existing visualizations.

Example transformation:

Before:

[
  {
    name: 'rotation',
    config: {
      type: 'SelectControl',
      label: t('Word Rotation'),
      choices: [
        ['random', t('random')],
        ['flat', t('flat')],
        ['square', t('square')],
      ],
      renderTrigger: true,
      default: 'square',
      clearable: false,
      description: t('Rotation to apply to words in the cloud'),
    },
  },
]

After:

[
  <SelectControl name="rotation" ...{everything as props} />
]

New or Changed Public Interfaces

Frontend (React): - controlPanel.ts files will gradually transition from static configuration objects to React components. - ControlPanelsContainer.tsx will include updated logic to handle both legacy configurations and React component entries. - New reusable control components (e.g., RotationControl, ColorSchemeControl) will be implemented under src/explore/components/controls/. - No REST API or CLI-level changes are expected. - UI and user behavior will remain identical during migration.

Backward Compatibility: - Both configuration-based and component-based controls will coexist during the transition. - Older dashboards and visualizations will continue to render correctly.

Migration Plan and Compatibility

No database schema changes or migrations are required.
No updates to stored URLs or metadata will be needed.
Migration will begin with the Word Cloud control panel as a proof of concept.
Once validated, the same approach will be extended incrementally to other control panels.
The hybrid rendering system ensures full backward compatibility until all panels are migrated.

Additional Context

This proposal originated from discussions in the Apache Superset Slack community. Our team selected this task from a list of available backlog items for contribution. We then reached out to @rusackas who provided additional details and guidance on the implementation approach. Evan recommended beginning with a small proof of concept and progressing incrementally to ensure maintainability and alignment with Superset’s ongoing frontend modernization efforts.

Comment From: Yatin-Malhotra

This proposal’s incremental migration approach is smart, especially since Superset has a large set of plugin-specific control panels. One idea worth discussing is whether we can introduce a thin compatibility layer or adapter that converts legacy config objects into temporary React wrappers. This could accelerate adoption while reducing the risk of partial migrations introducing inconsistencies.

Comment From: GursimarSingh1

Curious how you'll verify that behaviour stays consistent after swapping controls to React components. Maybe you could set up a few Playwright or Cypress tests that capture basic interactions to ensure no regressions?

Comment From: AshwinM1523

While moving to component-based controls increases modularity, it might also increase rendering overhead in panels with many controls. Has there been any discussion about memoization or lazy loading strategies to maintain performance parity with the current configuration-based approach? Exploring this early might prevent regressions later during the migration.

Comment From: meliadamian17

This sounds like a great modernization move overall. My only small concern is whether having each control as a React component could cause too many re-renders when props update, maybe React.memo or a centralized state context could smooth that out?

Apache Superset [SIP] Proposal for Modernizing Control Panel Architecture using React Components