[GitHub] [superset] rusackas commented on pull request #18780: [WIP] fix: default area chart to stacking

[GitBox <gi...@apache.org>]

rusackas commented on pull request #18780:
URL: https://github.com/apache/superset/pull/18780#issuecomment-1071886346


   @villebro These questions are a big part of what @zhaoyongjie is architecting (and we should put our heads together on). 
   
   When switching between viz components, I'm _leaning toward_ something like Option 3. But to restate or expand on the idea, here's one thing I'm _considering_:
   
   We may want to keep a piece of state that's merged snapshot of ALL formData accumulated as you switch viz types in Explore. For example: you're on an Area chart, and `stacked=true`, then you switch to a Pie chart. The `stacked` state has no meaning in this chart, but we _keep it in state anyway_ (in a superset of the formData in use). If you switch back to an Area chart, or perhaps to a Bar chart, the `stacked` preference again fits the formData schema, and is re-applied. 
   
   In regards to your question about whether Area chart should be two charts, I vote no. It seems like an unnecessary bifurcation. Stacked bar and split bar should be separate by this logic. I'm already on having second thoughts about the different stepped/smooth line charts being separate entities. I think that if you go from a Bar that's stacked to an Area, it should be a stacked Area. If you then unstack the Area and toggle to Bar, it should be unstacked there as well. That's my thinking, anyway.
   
   When switching from Area (stacked or not) that boolean would essentially be extraneous data, kept in that larger persisted formData superset, in case it's applicable in your next toggle. This kind of model would also allow you to experiment with viz types, fiddle with controls as you go, and restore some of the more unique/granular options you previously chose, when returning to the same (or similar) viz types.
   
   In all these cases, it would be a real win if we could use the shape/schema of form data when hopping from viz to viz in two ways:
   1) To reduce unnecessary queries, as you mentioned. E.g. if you switch from Line to Area, there are some cosmetic formData options to consider in drawing, but the query is essentially the same (if I'm not mistaken).
   2) Regardless of how many plugins a Superset deployment may have (some official, some custom or 3rd party), I'd love to see Superset introspect the formData of the current plugin, comparing it to the formData schema of all other loaded plugins. This "matchmaker" operation would enable fast-viz switching ("safe" switching), while that larger piece of formData state/history would provide enhanced "smooth" switching to/from currently incompatible viz types.
   
   I hope this makes sense, but I'm happy to compare notes with people and align on thinking.


-- 
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