Files
superset2/docs/developer_docs
Claude Code f1c7ec60ce feat(extensions): register the built-in dashboard renderer as the default provider
Follow the SQL Lab pattern one step further: instead of the host
hardcoding the built-in renderer as a fallback branch, the built-in
renderer is now registered through the same contribution point as the
default-tier provider (superset.dashboard-renderer).

- DashboardRendererProviders gains a default tier: setDefaultProvider
  (host-internal, idempotent by id), getDefaultProvider,
  getOverrideProvider; getProvider() resolves override ?? default. The
  default is never displaced by extension registrations, and disposing
  an override falls back to it through the registry.
- The default registers via a lazy side-effect module
  (src/core/dashboards/defaultRenderer.ts) imported by both the host
  component and the namespace impl, so it is set wherever dashboards
  render (app + embedded) without pulling the dashboard stack into the
  startup bundle. Registration is independent of ExtensionsStartup and
  ENABLE_EXTENSIONS: dashboards always render with the flag off.
- DashboardRendererHost renders the resolved provider: extension
  override (ErrorBoundary-wrapped, view mode + flag on only) or the
  lazy default under a local Suspense.
- Public contract adds getDefaultDashboardRenderer() so extensions can
  wrap/augment the built-in renderer rather than fully replace it.
- Tests updated/extended for the default tier (registry fallback
  semantics, idempotency, reset behavior, namespace API); the E2E spec
  now asserts live that the built-in is the registered default.

The oxlint hook is skipped in this commit only because the local
node_modules currently holds linux bindings (docker bind mount); the
exact hook command was run clean inside the container instead.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-03 10:08:50 -07:00
..