rusackas commented on PR #43108: URL: https://github.com/apache/superset/pull/43108#issuecomment-5470873068
Tagging @kgabryje @michael-s-molina and @villebro on this one, since they might have the most institutional memory around native filter state/storage, and remember reasons we didn't do this before. Seems harmless as long as it's non-breaking for others dpeending on filter state persisted in the key/value store and retrieved via the filter key in the URL. If this is just additive like caching, it's probably a nice addition. Without having looked at the code yet, I'll note "some does it/should it" questions: • If a dashboard is loaded with no url filter key, and it applies the filters, does/should it ADD the filter key to the URL via push state? One of the benefits of having it there is that you can share that URL with others, so they can benefit from that filter config. Also, just a "truthiness" thing to show more accurately that these filters are applied • If someone sends you a URL with a key in the URL, does local storage USE those filters, or override them with your local filters? • If you keep editing filters locally, and the URL updates the filter key accordingly, are all URL and navigation aspects preserved (i.e. does hitting back go to the prior set values), or does this change behavior? • Are there any situations where the filter state stored locally might be obsolete compared to the data/filters available as fetched from the server in the normal workflow? I.e. might you be applying a filter on a column/value that no longer exists in the DB? Of course the normal native filter key might share this problem if it is indeed a problem. • Could any of the bug/feature as it exists today be improved by additional push state entries to make navigation more sensible? This also makes me think of a new feature... just since my brain is on this, I'll mention it... when we apply filters on a dashboard, we get the lovely Apply button that generates a native filters key in the URL. Maybe (if you're one of the dashboard owners, or a use with the permission to do so, which is not always the case) we should have a "Save filters as defaults" button near Apply... that cuold save a lot of time for dashboard authors compared to editing the filters and setting default values one by one. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
