Repository navigation
[SIP-198] Homepage Layout Extensions #37016
Description
[SIP-198] Proposal for Homepage Layout Extensions
Note: This proposal is intended as an input for the Generic Page Builder. The architecture described here is designed to align with and contribute to the broader vision outlined in SIP-151. Interfaces and patterns are indicative rather than final, and should be refined through collaboration with the Extensions SDK maintainers.
Motivation
The core idea is not to add another animal to the zoo, but to extend what we already have.
The current Superset homepage presents fixed sections (Recent Dashboards, Recent Charts, Recent Activity, Saved Queries) that cannot be customized without modifying the core frontend codebase. This creates friction for:
- Enterprise organizations that want to display organization-specific content, KPIs, or prioritized dashboards
- End users with different workflows who would prefer to see content relevant to their role
- Administrators who want to add announcements, documentation links, or custom widgets
Community Demand
This is a frequently requested feature:
- Discussion #18571 - Customize Home Page option
- Discussion #33761 - Customizing the Welcome Page
Why Homepage First?
Homepage is an ideal proving ground for layout extensions because:
- Simpler than Dashboard: No cross-filtering, no slice management, fewer edge cases
- High community demand: Frequently requested feature
- Validates the pattern: Success here paves the way for Dashboard component extensions
Proposed Change
This SIP proposes Homepage customization as an implementation of the Extensions SDK (SIP-151), following the same ViewContribution pattern established by SQL Lab Extensions (SIP-177, PR #36644).
Alignment with Extensions Architecture
| SQL Lab Pattern | Homepage Equivalent |
|---|---|
sqllab.rightSidebar |
homepage.sidebar |
sqllab.panels |
homepage.main |
sqllab.editor |
homepage.header |
ExtensionsManager |
Same ExtensionsManager |
View Contributions
Following the SQL Lab pattern, we define Homepage regions as ViewContribution:
export enum HomepageViewContribution {
Header = 'homepage.header',
Main = 'homepage.main',
Sidebar = 'homepage.sidebar',
}Visual Layout
┌─────────────────────────────────────────────────────────────────┐
│ HEADER (homepage.header) │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Welcome Banner / Announcements │ │
│ └─────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────┤
│ MAIN (homepage.main) │ SIDEBAR (homepage.sidebar) │
│ ┌───────────────────────────────┐ │ ┌─────────────────────────┐ │
│ │ Recent Dashboards │ │ │ Favorites │ │
│ ├───────────────────────────────┤ │ ├─────────────────────────┤ │
│ │ Recent Charts │ │ │ Quick Actions │ │
│ ├───────────────────────────────┤ │ └─────────────────────────┘ │
│ │ Activity │ Saved Queries │ │ │
│ └───────────────────────────────┘ │ │
└─────────────────────────────────────────────────────────────────┘
Interactive Demo
A working prototype demonstrating the proposed Homepage Builder is available here:
superset-homepage-builder-demo
The demo showcases:
- Drag-and-drop widget reordering
- Widget configuration modal
- Add/remove widgets
- Preset layouts
- Edit mode toggle
Integration with ExtensionsManager
Components are registered through the existing ExtensionsManager:
import { extensionsManager } from '@superset-ui/core';
import { HomepageViewContribution } from './contributions';
extensionsManager.register({
id: 'recent-dashboards',
viewId: HomepageViewContribution.Main,
component: RecentDashboards,
name: t('Recent Dashboards'),
configSchema: recentDashboardsConfigSchema,
defaultConfig: { limit: 6, showFavorites: true },
});Built-in Components
The existing homepage sections become built-in extensions:
| Component ID | View Contribution | Description |
|---|---|---|
welcome-banner |
homepage.header |
Customizable welcome message |
recent-dashboards |
homepage.main |
Recently accessed dashboards |
recent-charts |
homepage.main |
Recently accessed charts |
recent-activity |
homepage.main |
Activity feed |
saved-queries |
homepage.main |
Saved SQL queries |
favorites |
homepage.sidebar |
Favorited items |
markdown |
any | Custom Markdown content |
Configuration Storage
| Scope | Storage | Who Can Edit |
|---|---|---|
| Default | Code/Config | Developers |
| Global | Database | Admin |
| Role-based | Database | Admin |
| User | Database | User (if enabled) |
Toward a Generic Page Builder
As discussed with the Extensions working group, there's potential for a generic page builder serving both Homepage and Dashboards. This SIP focuses on Phase 1:
- Phase 1: Implement Homepage extensions using current pattern ← this SIP
- Phase 2: Extract common layout engine
- Phase 3: Unify with Dashboard builder
New or Changed Public Interfaces
REST API
| Endpoint | Method | Description |
|---|---|---|
/api/v1/homepage/layout |
GET | Get effective layout for current user |
/api/v1/homepage/layout |
PUT | Save user's layout |
/api/v1/homepage/components |
GET | List available components |
/api/v1/homepage/layout/global |
GET/PUT | Admin: manage global layout |
Frontend
HomepageViewContributionenum (new)- Component registration via existing
ExtensionsManager HomepageComponentPropsinterface for widget implementations
Configuration
HOMEPAGE_EXTENSIONS_ENABLEDfeature flag insuperset_config.py
New Dependencies
No new third-party dependencies required. The implementation leverages existing Superset infrastructure:
| Package | Status | License | Notes |
|---|---|---|---|
react-dnd |
Already in use | MIT | Used by Dashboard builder |
@superset-ui/core |
Already in use | Apache 2.0 | ExtensionsManager |
Migration Plan and Compatibility
Database Migrations
- New
homepage_layoutstable for storing layout configurations (scope, layout JSON, timestamps) - No changes to existing tables
Backward Compatibility
- No breaking changes: Current homepage remains the default
- Feature flag:
HOMEPAGE_EXTENSIONS_ENABLEDcontrols activation - Gradual rollout: Can be enabled per-organization
- Existing bookmarks: Homepage URLs remain unchanged
Rollback Strategy
- Feature flag can be disabled to revert to classic homepage
- Layout data preserved in database for re-activation
Rejected Alternatives
| Alternative | Why Rejected |
|---|---|
| Dashboard as Homepage | Loses homepage-specific features (recent items, activity feed). Already possible via redirect but incomplete solution. |
| Extend existing extension points only | Current welcome.* points don't allow reordering or drag-drop. Insufficient flexibility for real customization. |
| Homepage as Dashboard type | Over-engineered. Dashboard infrastructure too heavyweight for homepage use cases. Confusing UX. |
| Standalone system (not Extensions SDK) | Creates "another animal in the zoo". Against PMC direction for unified Extensions architecture (SIP-151). |
References
- SIP-151: Vision for new Superset Plugins Architecture
- SIP-177: SQL Lab Extensions
- PR #36644: SQL Lab action extensions
- Discussion #18571: Customize Home Page option
- Superset Extensions Project Board
Open Questions
- Generic Page Builder: How should Homepage extensions align with the broader page builder vision?
- Component Sharing: Can components be reused across
homepage.*anddashboard.*contexts? - Edit Mode: Should Homepage have its own edit mode, or integrate with a unified page builder UI?
Activity
[-][SIP] Homepage Layout Extensions[/-][+][SIP-198] Homepage Layout Extensions[/+]msyavuz commentedon Jan 9, 2026
Love this (especially the first phase! Tagging @justinpark and @michael-s-molina for opinions on this. I am sure they have designs and ideas around it. It would be nice to make different part of the app extensible in parallel.
michael-s-molina commentedon Jan 12, 2026
Love this as well. Great SIP @EnxDev!
Some initial thoughts for your consideration:
ENABLE_EXTENSIONSfeature flag to control external extensions. We might need a small adjustment so that built-in extensions are always available—what do you think?@apache-superset/coreto the dependencies list.We would love if you can join one of our Extensions meeting (public meeting available on Superset's calendar) to talk about this SIP and discuss some of the open questions. Recently, @betodealmeida joined and we had a very inspiring meeting about [SIP-182] Semantic Layer Support in Apache Superset.
rusackas commentedon Jan 14, 2026
This should be put up for a DISCUSS thread... in general I love the idea, but there are some things to sort out.
I've been wondering about an alternate universe where we REMOVE the welcome page, and replace it with a pre-rolled dashboard. Then you could see all your assets, customize the layout, use filters (edited between dates, owned by filter, etc). At the end of the day, Mine/Recent/Favorites are really just filters.
Dashboards would need a few new features to make it COOL, but I've been wanting many of them anyway.
At the very least Dashboard Components and Welcome Components would likely have a lot of compatible components and layout zones.
EnxDev commentedon Jan 16, 2026
I think we're converging on the same vision from different angles.
What I'm calling "Homepage Builder" could really be a more generic
"Utility Page Builder"; a way to create pages composed of widget-extensions
(asset lists, KPIs, announcements, embedded charts, etc.).
The current "homepage" is just ONE instance of such a page; perhaps a
pre-configured default.
This aligns with your Dashboard idea:
The user (or admin) simply chooses which page is their landing page.
At that point, whether we "remove the homepage" or "make homepage a
utility page" becomes a semantic distinction; the underlying infrastructure
is the same Generic Page Builder.
Should we reframe the SIP around this broader "Utility Page" concept,
with the current homepage as the first use case?
Also I'd like to clarify an architectural distinction that I think is important:
While I agree that Dashboard and Utility Pages could share the same
underlying layout engine (Generic Page Builder), I believe they should
remain conceptually separate:
Dashboard = Superset's core: charts, slices, cross-filtering, data analysis
Utility Page = Organizational layer: asset lists, KPIs, announcements, navigation
The "Homepage Builder" I'm proposing is really a Utility Page; focused on
helping users organize and navigate their Superset environment, not on
data visualization.
An "Embedded Chart" widget could bridge the two worlds, but the core
Dashboard functionality (cross-filtering, drill-down, query caching)
shouldn't be mixed with utility widgets.
This separation keeps:
Does this distinction make sense?
Happy to discuss further.
michael-s-molina commentedon Jan 16, 2026
@EnxDev Yesterday, in our weekly extensions meeting, we had a productive discussion about this SIP and the possibility of making the homepage function as a dashboard.
Here’s what I’m currently envisioning—though I’m not sure yet if it’s technically feasible (we’d need to prototype to find out):
Imagine a generic page builder that provides a toolbar filled with a variety of elements: charts, filters, markdown, links, tabs, built-in extensions (like favorites or preset asset lists), external extensions, layout tools/algorithms, and more. Each tool would operate independently but could also respond to events from other tools using a pub/sub model or something similar. The concept shares similarities with microfrontends: each tool manages its own data fetching and can publish or listen to events. For example, a filter component could emit an event that a chart component listens for.
If we can build something like this, the separation you suggested would actually be handled by users as they assemble their pages. So, if I’m creating a homepage, I’d choose certain tools, and if I’m building a dashboard, I might select a different set—or even reuse the same ones.
What we realized in yesterday’s meeting is that as soon as we start working on making dashboards extendable, we’ll face these challenges anyway. So, it might make sense to tackle them now and use this page builder approach for the homepage as well.
EnxDev commentedon Jan 16, 2026
I've been reflecting on this, and I think I've evolved my position.
My initial concern was UX clarity; too many choices can overwhelm users,
and mixing everything could make Superset unrecognizable.
But I now see a bigger picture, especially considering AI integration:
Modular components enable AI-driven assembly.
If every element (charts, filters, asset lists, markdown) is an independent
extension that communicates via pub/sub, then:
This doesn't mean we lose UX clarity; we could still offer:
The separation becomes a UX layer (templates/presets), not an
architectural constraint.
A few thoughts:
On the architecture:
The pub/sub / microfrontend approach makes a lot of sense. Each tool being
independent but able to communicate via events solves the "Dashboard vs
Utility Page" separation elegantly — it becomes a user choice, not an
architectural constraint.
On the Homepage SIP:
Given this vision, should we reframe my SIP as:
I'm happy to pivot the SIP to align with this broader scope.
On prototyping:
I'd be glad to help prototype this.
I could contribute to a proof-of-concept branch for testing the pub/sub model within
the Superset codebase.
My standalone demo (https://github.com/EnxDev/superset-homepage-builder-demo)
is available as a UX reference for the page builder interface.
Questions:
michael-s-molina commentedon Jan 16, 2026
I think your SIP will contribute to both 😄
Yes, part of the @apache-superset/core package to be available to built-in and external extensions.
We need to prototype but I'm thinking a mix of built-in features with cross-filter events that charts/other components can react too.
Given that I think the metadata supporting this model would be completely different the existing dashboard metadata, my initial thinking would be to make different dashboard versions coexist. Once we figure everything out, if possible, we could offer a migration tool.
EnxDev commentedon Jan 16, 2026
Agreed! I'll rename
sidebartoleftSidebarto align with potential AI Chat placement and maintain consistency.I'll clarify this. The intent is:
“Do you like the idea of storing pre-built pages and switching between them via a selector?
Do you think it’s useful given our considerations?
If so, I’ll try to clarify this functionality in the SIP
Makes sense to move it to Migration Plan section.
I agree
ok
You're right to flag this. Looking at it now, the phased approach in my
SIP assumed we'd build Homepage-specific infrastructure first, then
generalize it.
But given the Generic Page Builder direction, that distinction doesn't
make sense anymore. The layout engine and endpoints should be designed
as shared infrastructure from the start; Homepage would simply be the
first use case.