-
Notifications
You must be signed in to change notification settings - Fork 14.3k
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
fix(explore): Prevent shared controls from checking feature flags outside React render #21315
Conversation
Codecov Report
@@ Coverage Diff @@
## master #21315 +/- ##
==========================================
+ Coverage 66.56% 66.62% +0.06%
==========================================
Files 1791 1791
Lines 68591 68520 -71
Branches 7319 7287 -32
==========================================
- Hits 45656 45651 -5
+ Misses 21046 21002 -44
+ Partials 1889 1867 -22
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
af98814
to
a0612e5
Compare
/testenv up |
Wow that's a tremendous piece of work @codyml! |
@kgabryje Ephemeral environment spinning up at http://54.202.40.35:8080. Credentials are |
@@ -125,7 +126,7 @@ const getMetricsMatchingCurrentDataset = ( | |||
}, []); | |||
}; | |||
|
|||
export const DndMetricSelect = (props: any) => { | |||
const DndMetricSelect = (props: any) => { |
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.
We definitely should improve typing here... (not in this PR, that's a general note)
default?: unknown; | ||
}; | ||
|
||
export const dndGroupByControl: SharedControlConfig< |
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.
Could you add a comment that will explain the idea behind using props from non-dnd component in dnd control definition? Might be useful for other contributors in the future
Looks fantastic! Though I can't wait to revert all this when we fully get rid of non-dnd interface 😄 |
I found an issue that for world map, after save for changes, the chart viz will be empty, i am not able to reproduce in master branch, it may be this PR releated. Screen.Recording.2022-09-12.at.10.22.05.AM.mov |
I can reproduce this issue with different types of charts, but only with a certain dataset "wb_health_population" |
QA verified. PR LGTM |
/testenv up |
@jinghua-qa Ephemeral environment spinning up at http://54.203.61.228:8080. Credentials are |
This issue is able to reproduce in other superset ephemeral, but not in superset master. It is not related to this PR. LGTM!
|
Ephemeral environment shutdown and build artifacts deleted. |
superset-frontend/packages/superset-ui-chart-controls/src/shared-controls/dndControls.tsx
Show resolved
Hide resolved
…side React render (apache#21315) (cherry picked from commit 2285ebe)
@@ -237,7 +237,7 @@ export interface BaseControlConfig< | |||
) => boolean; | |||
mapStateToProps?: ( | |||
state: ControlPanelState, | |||
controlState: ControlState, | |||
controlState?: ControlState, |
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.
@codyml why do you make this parameter optional?
This breaks all our custom override type checking.
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.
Hmm, I think that was a quick fix to stop the histogram viz plugin from complaining after I updated it to use shared controls. I opened a PR that reverts that change and instead updates the plugin – does that look like a better solution? Would be great to spin up an ephemeral env to check if there are any side-effects for Histogram charts.
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.
(Assuming it passes CI)
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.
#22014 was merged, let me know if that solves the issue!
SUMMARY
Feature flags are saved to a global window object and read using the
isFeatureEnabled
utility function, which returnstrue
orfalse
after checking the global window object. As noted in #21201, this process is prone to error because feature flags are set at JS module execution time and sometimes also read at JS module execution time, creating a race condition that can be triggered by a change in webpack bundling. This PR takes steps towards resolving one instance of this issue by moving the feature flag check to component render. Previously, shared chart controls were exported as an object of control config objects, each of which contained the control's React component to render, params used by the control-rendering engine, and props that the control's React component would be rendered with. For each shared control that had drag-and-drop functionality, a different config object would be exported at JS module execution time ifisFeatureEnabled
checks indicated that drag-and-drop functionality was enabled. This PR moves theisFeatureEnabled
check to inside a wrapper component, and uses a single config to render that wrapper component regardless of feature flag status. While there was some overlap between config objects, the DnD and non-DnD versions of some control components required different props, so some refactoring was required to make it possible to merge the two config objects' props to form one unified config object.TESTING INSTRUCTIONS
ENABLE_EXPLORE_DRAG_AND_DROP
feature flag is enabled and disabled. WhenENABLE_EXPLORE_DRAG_AND_DROP
is enabled, also ensure that everything works whenENABLE_DND_WITH_CLICK_UX
is enabled and disabled.ADDITIONAL INFORMATION
ENABLE_EXPLORE_DRAG_AND_DROP
,ENABLE_DND_WITH_CLICK_UX