-
Notifications
You must be signed in to change notification settings - Fork 14.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: Simplifying tabOverride logic in control sections #11708
Conversation
Codecov Report
@@ Coverage Diff @@
## master #11708 +/- ##
==========================================
- Coverage 66.79% 63.71% -3.09%
==========================================
Files 924 924
Lines 44837 44828 -9
Branches 4253 4247 -6
==========================================
- Hits 29951 28562 -1389
- Misses 14777 16089 +1312
- Partials 109 177 +68
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
Related: #9495 |
a05dcd8
to
fbf8cd8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of adding a customize
option, I'd be more enthusiastic on getting rid of the "renderTrigger
implies data tab" logic. To really keep things simple, we should just always default things to be on the customize
tab and require explicit override if people want to display things in the Data
tab (or other way around if it makes more sense).
But this change is probably safe since I didn't see any use of tabOverride
at the control item level anymore.
superset-frontend/src/explore/components/ControlPanelsContainer.jsx
Outdated
Show resolved
Hide resolved
fbf8cd8
to
4a86bd0
Compare
Yep... I had an itchy trigger finger to remove that behavior entirely, but didn't want to cause any weird regressions. I'll do that in another PR once we've made some more updates on the superset-ui side and merged them in. |
dd67d59
to
fc16027
Compare
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. For admin, please label this issue |
closing this due to inactivity |
SUMMARY
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
TEST PLAN
Various control sections have been showing up under unexpected tabs. This PR makes it simpler/easier to shove control sections under the correct tab, by allowing "tabOverride" to be either "data" or "customize" and simplifying (essentially inverting) the logic that takes place when neither is specified. This also removes support for putting the "tabOverride" in a singular control, and just keeps it to the control section, for simplicity.
I have half a mind to just make it "tab" instead of "tabOverride" and bake it into every control section, as a standard practice... but I'll pocket that one, as a control layout refactor will likely be coming soon (reconsidering the current rows/columns approach). But that's another story, and probably another PR...
Also, there will be a PR over on
superset-ui
that utilizes this new "customize" value in numerous places. We can merge that one before this one, I think, and I'll bump all the chart versions as part of this PR when it exits draft mode.ADDITIONAL INFORMATION