-
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: dashboard->explore url generation #17145
Conversation
Codecov Report
@@ Coverage Diff @@
## master #17145 +/- ##
==========================================
+ Coverage 76.68% 76.90% +0.22%
==========================================
Files 1038 1038
Lines 55516 55544 +28
Branches 7564 7564
==========================================
+ Hits 42570 42717 +147
+ Misses 12696 12577 -119
Partials 250 250
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
Hi @suddjian thanks for the work. But I do not think from dashboard -> explore chart should use GET request with full form params in the url. Superset used to handle this issue very well, but was broken since #15668. I do not think this solution, reducing a couple of extra parameters from dashboard, can fix the root cause: browser has limits for the url length, and many companies with Nginx also limits the total length of GET request url. May i know why not use POST request to resolve this problem, as Superset did before? |
The goal with moving from I agree that this won't completely solve the long url issue, but it will help in certain cases. I'd really like to understand better what the differences are between the POST solution and this one, to be able to solve your issues. The I think a workable plan to get rid of the long url issue permanently could be to set up some kind of "exploration context" object in the db that has all this information and can be referenced by id. |
https://www.w3schools.com/tags/ref_httpmethods.asp
|
I think this is the center of the issue. With the click handler, the developer must decide to open in the same window or in a new tab/window. With an old-school An onClick handler might be able to capture modifier keys to emulate this behavior, but it would not have the same level of support (no right click menu, accessibility concerns). The longer term idea we're stewing on would be a combination... opening the context menu could do a POST to push all the context of the dashboard (or other superset object, potentially) into a database row, and return a URL with a slug. That short URL could be used in a conventional link to take you to Explore (or other superset area) which would look up all of the state/context needed to load as desired. Approving this PR since it improves the existing feature. Going back to a simple onClick/POST will just rekindle the usability discussions we've had before. I think if we build a system like I'm (only briefly) attempting to describe above, it will solve the long URL problem AND improve accessibility/usability for this instance, and perhaps several other areas of Superset. |
SUMMARY
Just a small refactor that I didn't get a chance to push before #17123 was merged. This separates the dashboard-specific function from the function used by Explore. Extending rather than modifying to minimize the footprint of this change.
TESTING INSTRUCTIONS
Go to a dashboard and Explore Chart on one of the charts.
ADDITIONAL INFORMATION