What parameters should be carried over or reset to default when chart types are switched?

[sfirke]

Bug description

In Superset 4.1.2, I make a pie chart (default row limit 100). Looks good. Then I switch to a line chart showing different dimensions over time. The values carry over - which is good, except the row limit is still 100. If I had started with a blank new line chart it would be the chart default value of 10000.

The value of 100 is good for a pie chart but on a line chart will likely cause the immediate truncation of data.

IMO the right behavior would be to not carry over the row limit when chart type is switched and instead adopt the new chart type's default.

Screenshots/recordings

No response

Superset version

4.1.2

Python version

3.9

Node version

16

Browser

Firefox

Additional context

No response

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[rusackas]

Interesting idea... I'm not sure if others will agree or not. You might want to change from one chart type to another to see the same data (including limits) in a different way... but in some cases not. Curious what @kasiazjc and @mistercrunch or @michael-s-molina (among others) think of the idea.

[mistercrunch]

+1 on that. I believe there are ways to define what should happen when switching viz type to another. Essentially we need to say which params should be carried over, reset to default, or where logic needs to be set specifically/confitionally.

For instance, I believe switching from the line chart to an area chart should probably force "stacked=true", but there are many instances of similar cases.

I'd almost re-title this issue (or open another one) which would be around "Improve control assignements when switching viz type while improving the underlying framework/hooks that support this type of logic"

[michael-s-molina]

I think @rusackas' comment is spot on, sometimes it will be desirable and sometimes not. It will depend on the type of charts involved in the transition. I do think though that we should always make very clear to the user when a control value changes during the transition.

[mistercrunch]

tagging @kasiazjc for design input. Clearly there's a need for a viz_type switcher logic. It seems the "receiving" or "destination" viz_type should state/host the logic for what to do with incoming control values, and the framework should notify the user about what's been altered or set.

Maybe message "toasts" is the way to.
Toast would go something like

Adjusted some controls while switching from {{ viz_type_label_source }} to {{ viz_type_label_destination }}:
- Row Limit was set from 10000 to 100. {{ reason "as bar chart can't typically accomodate more than N values" }}
- Stack config was set to "stacked" as it's generally a better option for area charts
- {{ ... }}

[rusackas]

@kasiazjc following up here, still curious for your design take on the viz_type switcher behavior mistercrunch outlined above (what should carry over vs reset to default when switching chart types). Thoughts?

This has been quiet for a long time and may be closed if it doesn't get any engagement soon-ish.

[sfirke]

I will convert to a discussion, given the above ... discussion. It feels like an area where Superset could be improved but it's not a simple bug to be closed.

[sfirke]

And I edited the title per suggestion from @mistercrunch