Open Dosant opened 1 year ago
Pinging @elastic/kibana-presentation (Team:Presentation)
Pinging @elastic/kibana-visualizations @elastic/kibana-visualizations-external (Team:Visualizations)
Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)
Thanks for opening this issue @Dosant 👍
I personally think that we should avoid as much as possible changing how a user interacts with the browser and what they expect from it. If the main menu link takes me to "/dashboard/home" I expect this link/behaviour to be consistent no mater what' I've been doing before.
If apps see the need to restore state, like you said there are different options, be it memory through a shared service or session storage.
For the UX it can be pretty cool to have a banner on top when navigating back: "Do you want to restore your previous
Pinging @elastic/appex-sharedux (Team:SharedUX)
+1 for not porting this functionality to Serverless, I've always found this "feature" very confusing in the on-prem Kibana; something that we should remove. So, hopefully if we can stop doing this in Serverless that is one step towards also removing it in on-prem.
+1 from the presentation team on removing this functionality. This will help a lot with removing complexity from the app, and will lead to more consistent behaviour.
@Dosant, are we considering moving forward with removing this on prem?
Currently Discover, Dashboard and Visualize app (not Lens) use the
kbnUrlTracker
helper to manipulate the URL to the app's link in the nav bar.https://github.com/elastic/kibana/blob/74e6282b243960e290865c68a1d0831cd86608f3/src/plugins/kibana_utils/public/state_management/url/kbn_url_tracker.ts#L46
Example usage in discover:
https://github.com/elastic/kibana/blob/74e6282b243960e290865c68a1d0831cd86608f3/src/plugins/discover/public/utils/initialize_kbn_url_tracking.ts#L44-L93
Original Goals
This functionality had two goals:
Restore app's state when navigating back
The first goal was to preserve app's state when navigating between apps. This is how it worked:
kbnUrlTracker
sees that the user navigates away from the Discover, picks the current URL with all the state, and updates the link to the Discover app putting all the state thereThis worked through the links because in the past Kibana had hard reloads when navigating between apps (no sure why not session storage). Today it would be more straightforward if this would be implemented simply in-memory. As I understand, since dashboard removed most of the state from the URL, this was re-implemented there using memory or session storage.
Transfer global state between apps (time range and pinned filters)
This was also used to transfer time range and pinned filters changes between apps. When the "global" state changed, all the links in the sidebar where updates with the current time range and pinned filters. This way when user navigated to the app, the state of those was restored from the link.
This is likely redundant now because this state can be kept in-memory in filter manager and time filter service
Why Remove This
Some reasons why I think we should consider removing that functionality. Then apps should decide if they want to drop the feature they got from this or re-implement in a more simple way:
cc @ThomThomson, @sebelga