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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
