amaannawab923 commented on issue #33448: URL: https://github.com/apache/superset/issues/33448#issuecomment-3195049885
Thanks a lot for the thoughtful feedback! 🙏 I completely agree with the points you raised, and I’d like to clarify how I see this evolving so that we’re not building a parallel subsystem but rather moving toward the unified direction you outlined. How I see this approach fitting in: Easy Charts as MVP / Proof of Concept The current POC is intentionally very minimal: dataset, viz type, metric, and groupby only. The goal here was to validate how inline chart creation inside dashboards feels from a UX perspective. And i think this flow is compelling for casual users and embedded SaaS scenarios, so it proves the value of “lightweight charting” without committing to a full duplicate of Explore , Please suggest if you feel the same - Commitment to Explore as the Core I agree Explore should remain the single core chart builder. The long-term home for this functionality is not a separate subsystem, but rather a “Simple Mode” inside Explore that exposes only essential query controls. Easy Charts should essentially become a dashboard entry point into this Simple Mode, with a clear path to “Open in Full Explore” for advanced editing. - Path Forward I would Abstract the query-only controls into a mode="simple" variant of Explore, so we reuse the same building blocks and avoid duplication. Long-term: Work toward unifying Explore + Dashboard apps (reducer composition or reduced Redux reliance), which would make embedding Explore directly inside dashboards clean and maintainable. <- Though i still need to think deep about this but i aggree on this as well Next Steps I see in pivot for this POC Start experimenting with refactoring the control panel to support a simple mode flag. Adjust the POC so that the Easy Charts container uses this simple Explore instead of its own query form. Keep the UX consistent: quick creation in dashboard, with an escape hatch into full Explore for customization. Thanks for Pivoting/Guidance in the right direction, i will implement all the points suggest above and come back with possibly better outcomes , i do understand the concern, that creating a sub system will create a maintainance hell and its best to avoid that, Let me rework it properly as suggested and i will keep the thread updated Thanks @mistercrunch -- 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-unsubscr...@superset.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org For additional commands, e-mail: notifications-h...@superset.apache.org
