Skip to content
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(key-value): lost url_params after long-url feature #18846

Merged
merged 2 commits into from
Feb 22, 2022

Conversation

zhaoyongjie
Copy link
Member

@zhaoyongjie zhaoyongjie commented Feb 22, 2022

SUMMARY

Currently, the parameters in the browser can't show in URL. This PR resolved it.

partial fix #16650

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

After

image

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

  • Has associated issue:
  • Required feature flags:
  • Changes UI
  • Includes DB Migration (follow approval process in SIP-59)
    • Migration is atomic, supports rollback & is backwards-compatible
    • Confirm DB migration upgrade and downgrade tested
    • Runtime estimates and downtime expectations provided
  • Introduces new feature or API
  • Removes existing feature or API

if value:
initial_form_data = json.loads(value)
initial_form_data = json.loads(value) if value else {}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just code smell

@zhaoyongjie zhaoyongjie changed the title fix: lost url_params after long-url feature fix(key-value): lost url_params after long-url feature Feb 22, 2022
@@ -175,6 +175,19 @@ const updateHistory = debounce(
additionalParam[URL_PARAMS.datasetId.name] = datasetId;
}

const urlParams = payload?.url_params || {};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't be cleaner to just initialize additionalParam with payload?.url_params? If some of the parameters are already in the URL they will be overridden anyway. This way you don't need the forEach and the if check.

Copy link
Member Author

@zhaoyongjie zhaoyongjie Feb 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't be cleaner to just initialize additionalParam with payload?.url_params?

  1. formDataKey in urlParams
  2. it isn't known which url_params don't need to be put into additionalParams in the future.

If some of the parameters are already in the URL they will be overridden anyway. This way you don't need the forEach and the if check.

There needs to be a pattern that controls which params can be put in, and which do not.

BTW, chartId and datasetId come from elsewhere even though they are the same as urlParams. (link)

Copy link
Member

@villebro villebro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for fixing this!

@zhaoyongjie zhaoyongjie merged commit 4c16586 into apache:master Feb 22, 2022
rosemarie-chiu pushed a commit to preset-io/superset that referenced this pull request Feb 22, 2022
@rosemarie-chiu
Copy link
Contributor

🏷 preset:2022.7

@mistercrunch mistercrunch added 🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels 🚢 1.5.0 labels Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels preset:2022.7 size/S 🚢 1.5.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Jinja template is not working when async query is enabled
5 participants