You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@superset.apache.org by "EnxDev (via GitHub)" <gi...@apache.org> on 2026/01/09 16:29:59 UTC
[I] [SIP] Homepage Layout Extensions [superset]
EnxDev opened a new issue, #37016:
URL: https://github.com/apache/superset/issues/37016
## [SIP] 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:
1. **Enterprise organizations** that want to display organization-specific content, KPIs, or prioritized dashboards
2. **End users** with different workflows who would prefer to see content relevant to their role
3. **Administrators** who want to add announcements, documentation links, or custom widgets
**Community Demand**
This is a frequently requested feature:
- [Discussion #18571](https://github.com/apache/superset/discussions/18571) - Customize Home Page option
- [Discussion #33761](https://github.com/apache/superset/discussions/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`:
```typescript
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 │ │ │
│ └───────────────────────────────┘ │ │
└─────────────────────────────────────────────────────────────────┘
```
<img width="1743" height="1299" alt="Image" src="https://github.com/user-attachments/assets/3723bb9c-d513-4f30-aeea-8d50a715e901" />
#### Interactive Demo
A working prototype demonstrating the proposed Homepage Builder is available here:
**[superset-homepage-builder-demo](https://github.com/EnxDev/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`:
```typescript
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:
1. **Phase 1**: Implement Homepage extensions using current pattern ← *this SIP*
2. **Phase 2**: Extract common layout engine
3. **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
- `HomepageViewContribution` enum (new)
- Component registration via existing `ExtensionsManager`
- `HomepageComponentProps` interface for widget implementations
#### Configuration
- `HOMEPAGE_EXTENSIONS_ENABLED` feature flag in `superset_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_layouts` table 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_ENABLED` controls 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](https://github.com/apache/superset/issues/31932)
- [SIP-177: SQL Lab Extensions](https://github.com/apache/superset/issues/34162)
- [PR #36644: SQL Lab action extensions](https://github.com/apache/superset/pull/36644)
- [Discussion #18571: Customize Home Page option](https://github.com/apache/superset/discussions/18571)
- [Superset Extensions Project Board](https://github.com/orgs/apache/projects/544)
---
### Open Questions
1. **Generic Page Builder**: How should Homepage extensions align with the broader page builder vision?
2. **Component Sharing**: Can components be reused across `homepage.*` and `dashboard.*` contexts?
3. **Edit Mode**: Should Homepage have its own edit mode, or integrate with a unified page builder UI?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] [SIP-198] Homepage Layout Extensions [superset]
Posted by "EnxDev (via GitHub)" <gi...@apache.org>.
EnxDev commented on issue #37016:
URL: https://github.com/apache/superset/issues/37016#issuecomment-3760499777
> [@EnxDev](https://github.com/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.
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:
- Users can manually build focused pages (Dashboard OR Utility)
- AI can dynamically assemble the optimal combination based on user intent
- The "type" of page becomes a template/preset, not a hard constraint
This doesn't mean we lose UX clarity; we could still offer:
- "Dashboard template" (pre-selected chart-focused components)
- "Homepage template" (pre-selected navigation components)
- "Custom" (full freedom)
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:
1. A contribution to the Generic Page Builder discussion, OR
2. The first concrete use case that helps validate the page builder pattern?
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:**
- Should the pub/sub system be part of @apache-superset/core or a separate package?
- How would this interact with the existing Dashboard cross-filtering?
- Would existing dashboards migrate to this new system, or coexist?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] [SIP-198] Homepage Layout Extensions [superset]
Posted by "rusackas (via GitHub)" <gi...@apache.org>.
rusackas commented on issue #37016:
URL: https://github.com/apache/superset/issues/37016#issuecomment-3751183987
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] [SIP-198] Homepage Layout Extensions [superset]
Posted by "EnxDev (via GitHub)" <gi...@apache.org>.
EnxDev commented on issue #37016:
URL: https://github.com/apache/superset/issues/37016#issuecomment-3760293141
> 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.
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:
- Dashboard = page with chart-extensions + filters
- Utility Page = page with widget-extensions + filters
- Both could share the same layout engine and extension system
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:
<img width="554" height="404" alt="Image" src="https://github.com/user-attachments/assets/5474b3eb-6e0d-49ba-be45-63d0b918d6c5" />
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:
- Dashboard focused on its strength (data viz)
- Utility Pages lightweight and purpose-driven
- Clear UX for users ("Am I analyzing data or organizing my workspace?")
Does this distinction make sense?
Happy to discuss further.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] [SIP-198] Homepage Layout Extensions [superset]
Posted by "michael-s-molina (via GitHub)" <gi...@apache.org>.
michael-s-molina commented on issue #37016:
URL: https://github.com/apache/superset/issues/37016#issuecomment-3738703297
Love this as well. Great SIP @EnxDev!
Some initial thoughts for your consideration:
- Perhaps we could consider renaming “sidebar” to “rightSidebar” or even “leftSidebar,” especially with the introduction of AI Chat. What do you think?
- Regarding homepage customization, do we know yet if this will be per user, or more of an admin feature that impacts all users? If possible, could we clarify this in the SIP?
- I found the Configuration Storage section a little unclear. Would it be possible to provide some additional details or clarification there?
- The “Toward a Generic Page Builder” section could fit within the Migration Plan and Compatibility section.
- It might be challenging to support both the current homepage implementation and an alternative one in parallel. For SQL Lab, we made the default implementation rely on built-in extensions and avoided a gradual rollout. Perhaps we could take a similar approach here, using the `ENABLE_EXTENSIONS` feature flag to control external extensions. We might need a small adjustment so that built-in extensions are always available—what do you think?
- We need to add `@apache-superset/core` to the dependencies list.
- For "Phase 2: Extract common layout engine", I noticed it's listed as a second phase, but there are also endpoints proposed to control the layout. I wonder if we’re thinking of the same thing here. Maybe we could sync up to clarify?
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](https://github.com/apache/superset/issues/35003).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] [SIP-198] Homepage Layout Extensions [superset]
Posted by "EnxDev (via GitHub)" <gi...@apache.org>.
EnxDev commented on issue #37016:
URL: https://github.com/apache/superset/issues/37016#issuecomment-3760933154
> * Perhaps we could consider renaming “sidebar” to “rightSidebar” or even “leftSidebar,” especially with the introduction of AI Chat. What do you think?
Agreed! I'll rename `sidebar` to `leftSidebar` to align with potential AI Chat placement and maintain consistency.
> * Regarding homepage customization, do we know yet if this will be per user, or more of an admin feature that impacts all users? If possible, could we clarify this in the SIP?
I'll clarify this. The intent is:
- Admins configure global/role defaults
- User customization is optional (controlled by admin setting)
- If user customization is disabled, all users see admin-defined layout
> * I found the Configuration Storage section a little unclear. Would it be possible to provide some additional details or clarification there?
“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
> * The “Toward a Generic Page Builder” section could fit within the Migration Plan and Compatibility section.
Makes sense to move it to Migration Plan section.
> * It might be challenging to support both the current homepage implementation and an alternative one in parallel. For SQL Lab, we made the default implementation rely on built-in extensions and avoided a gradual rollout. Perhaps we could take a similar approach here, using the `ENABLE_EXTENSIONS` feature flag to control external extensions. We might need a small adjustment so that built-in extensions are always available—what do you think?
I agree
> * We need to add `@apache-superset/core` to the dependencies list.
ok
> * For "Phase 2: Extract common layout engine", I noticed it's listed as a second phase, but there are also endpoints proposed to control the layout. I wonder if we’re thinking of the same thing here. Maybe we could sync up to clarify?
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] [SIP-198] Homepage Layout Extensions [superset]
Posted by "michael-s-molina (via GitHub)" <gi...@apache.org>.
michael-s-molina commented on issue #37016:
URL: https://github.com/apache/superset/issues/37016#issuecomment-3760805818
> Given this vision, should we reframe my SIP as:
> A contribution to the Generic Page Builder discussion, OR
> The first concrete use case that helps validate the page builder pattern?
I think your SIP will contribute to both 😄
> Should the pub/sub system be part of @apache-superset/core or a separate package?
Yes, part of the @apache-superset/core package to be available to built-in and external extensions.
> How would this interact with the existing Dashboard cross-filtering?
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.
> Would existing dashboards migrate to this new system, or coexist?
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] [SIP-198] Homepage Layout Extensions [superset]
Posted by "michael-s-molina (via GitHub)" <gi...@apache.org>.
michael-s-molina commented on issue #37016:
URL: https://github.com/apache/superset/issues/37016#issuecomment-3760416061
@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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] [SIP-198] Homepage Layout Extensions [superset]
Posted by "msyavuz (via GitHub)" <gi...@apache.org>.
msyavuz commented on issue #37016:
URL: https://github.com/apache/superset/issues/37016#issuecomment-3729798209
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
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org