-
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 form data issue switching viz types #5100
Fix form data issue switching viz types #5100
Conversation
Codecov Report
@@ Coverage Diff @@
## master #5100 +/- ##
==========================================
+ Coverage 63.49% 63.51% +0.02%
==========================================
Files 360 360
Lines 22894 22888 -6
Branches 2551 2549 -2
==========================================
+ Hits 14537 14538 +1
+ Misses 8342 8335 -7
Partials 15 15
Continue to review full report at Codecov.
|
Actually this seems to solve part of the problem but not all of it. This is still a WIP. |
67b332f
to
455a6aa
Compare
Ok got it working now, sorry I had a few changes I thought were maybe not necessary but they were. This is my initial thought on how to solve this problem but I'm not sure if there is a better place to do this? |
@@ -299,14 +300,32 @@ class ExploreViewContainer extends React.Component { | |||
ExploreViewContainer.propTypes = propTypes; | |||
|
|||
function mapStateToProps({ explore, charts, impressionId }) { | |||
const form_data = getFormDataFromControls(explore.controls); | |||
const rawFormDataControls = getControlsState(explore, explore.rawFormData); |
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.
is this constant used anywhere?
const form_data = getFormDataFromControls(explore.controls); | ||
const rawFormDataControls = getControlsState(explore, explore.rawFormData); | ||
const controls = Object.assign({}, explore.controls); | ||
const formData = getFormDataFromControls(controls); |
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.
I think you can just getFormDataFromControls(explore.controls);
here and remove the previous line
It's becoming really hard to reason about how formData is flowing around the app, and I feel like this is adding yet another layer of complexity. I'd love to think of ways to fix the issue by removing a layer of complexity instead of adding one. I'm thinking we almost need to take the time and whiteboard how formData is flowing and think how to simplify things. Also Maybe we can take some time to talk about this at tomorrow's meeting. |
@mistercrunch I've started to document where we are changing form data. Before getting this in, I may think about how we handle formData on the front end and if there are any ways to clean it up. I don't have a clear picture of it yet, but we can discuss more at the meeting tomorrow. |
b616958
to
3ad80e6
Compare
I was experimenting with making some changes to how formData is stored/ flows around, but I found a simpler way to solve this problem. I'm making url_params a hidden control so that it will get stored in the explore controls and we don't need to change anything about the formData. On the python side, there's a problem where we were adding slice params to the form data It looks like this change was added here. And in some of the tests in that PR (and in PRs since) we've added the ability to add in specific form_data overrides to explore_json. Ideally it seems the data flow should be to pull the slice info on explore, then let the front end validate the controls from the raw form data, and always send the full validated form_data to explore_json (and not add much to form_data at that point). But in some of these tests like test_slice_url_overrides we pass slice_id and specific form data overrides to explore_json expecting get_form_data to pull the full slice params and override a specific param. Would we ever make a call to explore_json with form data like |
superset/views/core.py
Outdated
if slice_id: | ||
# Include the slice_form_data if form_data contains no datasource | ||
datasource_info = form_data.get('datasource') or datasource_id | ||
if slice_id and (use_slice_data or not datasource_info): |
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.
datasource_info
is the name of a local method and thus you probably should use a different name. Does form_data.get('datasource')
contain the datasource ID? I'm asking to try to understand why/when the form-data would reference a different datasource.
67209ac
to
fa60f9a
Compare
After our conversation I'm deprecating the undocumented feature for using overrides in explore_json. Explore_json should take in the full form_data and if someone in the future wants that feature they should add another endpoint that's similar to explore_json but calls I tried to only use the request.url when deciding whether to include the slice params but that breaks saving because the url is I updated the tests so they don't use overrides with explore_json calls, and instead make calls with full form_data. In your change Max, slc.form_data adds datasource to the form_data before returning it, but slc.viz.form_data does not contain datasource because we just set it to the slice params. So also changed tests to use slc.form_data. |
fa60f9a
to
c835031
Compare
@mistercrunch can you take a look? |
@@ -104,13 +104,6 @@ export function applyDefaultFormData(form_data) { | |||
formData[k] = form_data[k]; | |||
} | |||
}); | |||
// fill in additional params stored in form_data but not used by control | |||
Object.keys(form_data) |
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.
Doing forensics here: @graceguo-supercat added this as part of [Explore] Save custom url parameters when user save slices (#4578)
@@ -292,12 +292,6 @@ ExploreViewContainer.propTypes = propTypes; | |||
|
|||
function mapStateToProps({ explore, charts, impressionId }) { | |||
const form_data = getFormDataFromControls(explore.controls); | |||
// fill in additional params stored in form_data but not used by control |
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.
@graceguo-supercat added this as part of 9edbd64c5
I think this is fixing issues introduced by #4578, so deferring to @graceguo-supercat . I've hit the bugs quite a few times and we should get this through quickly |
1e21ddf
to
7081b4c
Compare
@graceguo-supercat after our discussion I made the change so explore_json can accept form data with only slice id. Slice params now get added on |
7081b4c
to
c02b65b
Compare
c02b65b
to
f7c48da
Compare
* Fixing issue with extra params in formData * Pass in param use_slice_data to decide whether to use slice data * Fixing core_tests to not use explore_json overrides (cherry picked from commit bf0afef)
* Fixing issue with extra params in formData * Pass in param use_slice_data to decide whether to use slice data * Fixing core_tests to not use explore_json overrides (cherry picked from commit bf0afef)
* Fixing issue with extra params in formData * Pass in param use_slice_data to decide whether to use slice data * Fixing core_tests to not use explore_json overrides (cherry picked from commit bf0afef)
* Fixing issue with extra params in formData * Pass in param use_slice_data to decide whether to use slice data * Fixing core_tests to not use explore_json overrides (cherry picked from commit bf0afef)
* Fixing issue with extra params in formData * Pass in param use_slice_data to decide whether to use slice data * Fixing core_tests to not use explore_json overrides (cherry picked from commit bf0afef)
* Fixing issue with extra params in formData * Pass in param use_slice_data to decide whether to use slice data * Fixing core_tests to not use explore_json overrides (cherry picked from commit bf0afef)
* Fixing issue with extra params in formData * Pass in param use_slice_data to decide whether to use slice data * Fixing core_tests to not use explore_json overrides (cherry picked from commit bf0afef)
* Fixing issue with extra params in formData * Pass in param use_slice_data to decide whether to use slice data * Fixing core_tests to not use explore_json overrides (cherry picked from commit bf0afef)
* Fixing issue with extra params in formData * Pass in param use_slice_data to decide whether to use slice data * Fixing core_tests to not use explore_json overrides (cherry picked from commit bf0afef)
* Fixing issue with extra params in formData * Pass in param use_slice_data to decide whether to use slice data * Fixing core_tests to not use explore_json overrides
We've been having an issue with extra params getting into the form data (that are not valid controls for a particular viz type), this breaks the query and there's no way to remove it from the controls. This happens when you switch from a time series with a group by to a big number. The group by in the rawFormData will get added to the form_data and create a query that's invalid for a big number chart (that doesn't have a group by control).
It looks like this was introduced here so I'm assuming that the only extra form data param is our url params section. If this is not true let me know.
@graceguo-supercat @mistercrunch