[Discuss] URL/Undo handling in applications

[timroes]

We currently have no aligned implementation and behavior of handling state via URLs and undo in Kibana. This means every application handles this slightly different leading us to an overall bad usability, since a user might need to change adopt when switching applications within Kibana to different behaviors, which can also be harmful in a way, that if they try to use one pattern in another app (like pressing browsers back button), they'll suddenly lose all their progress. I think we should start discussion about aligning those behaviors across apps.

The current ways we do state/undo handling:

Complete state handling via URL

This is the current behavior in Visualize/Dashboard/Discover (aka the initial way Kibana handled that). We'll basically store the whole state of your (unsaved) work into the URL. Undo will thus work by just pressing the browser back button.

Pros:

• Undo works "out of the box" (aka by using your browser)
• You can simply share your temporary state by sharing the URL

Cons:

• You can accidentally share your temporary state via URL
• You are tricked into believing that the temporary state is saved, because even when navigating between apps we'll keep that URL for you, even though the state is not persisted (outside your browser so far)
• It's hard to "nest applications" (e.g. show an in-place editor on a dashboard) since both of them need to mangle with the URL
• It's hard (and doesn't work in IE11) to have a large state, due to URL length limits, e.g. in IE11 you cannot use Vega with that URL version and need to switch over to using hashed ids instead and store the full URL in the localStorage instead. In general putting large states in the URL might not be a good idea.

Auto-saving state (the Canvas way)

The canvas URL will stay to an id of the saved canvas worksheet and every change will immediately persisted to that save sheet. Undo is handled internally by the application and will be saved to the same workpad again.

Pros:

• Short URLs that are working in all browsers and are easily shareable (contains no weird characters)
• The URL always represents the latest state and sharing will reveal the same workpad that one is seeing/editing

Cons:

• In case of network partition (or in general just bad network/connection) it's easier to lose progress
• Even playing around and just creating some "experiments" can easily leave you up with a lot of saved "garbage", e.g. our cloud instances seem to look like:
  
• Every state is immediately saved meaning no chance for "private"/"draft" experimentation

Manual saving, short URLs (the Maps way)

Maps require the user to save their state. At this point the URL will point to that saved map, which will always represent the latest saved state of that Map. Temporary changes are not represented in the URL. Undo needs to be handled by the application internally.

Pros:

• Short URLs that are working in all browsers and are easily shareable

Cons:

• Temporary state is easily lost by pressing back in your browser
• No way to share unsaved state with someone

---

I personally think the approach of Maps is my most favorite one right now, if we would extend it for something like (local) auto-drafts (to prevent easy loss of your unsaved state), and potentially give the user a manual possibility to create a URL pointing to your unsaved state, that they can share.

cc @peterschretlen @rayafratkina @stacey-gammon @thomasneirynck @clintandrewhall @ppisljar @skearns64

I won't label all application teams for now, to prevent pinging all team members, so please subscribe if you want to follow.

[lukeelmers]

I personally think the approach of Maps is my most favorite one right now, if we would extend it for something like (local) auto-drafts (to prevent easy loss of your unsaved state), and potentially give the user a manual possibility to create a URL pointing to your unsaved state, that they can share.

++

I could see a scenario where we develop some sort of unified interface for managing transient application state, which is provided to all application developers as a service.

Such a service could abstract away the actual caching of the data (in localStorage or wherever), while also managing changes to the state to allow for undo/redo functionality.

As an application developer, you just throw the objects at it that you want to cache. When a user returns to your app, you can use the service to check for any unsaved state that you wish to restore.

[thomasneirynck]

To add some context to the Maps-app approach.

It does not accomodate two use-cases, which would be valuable for maps.

• undo functionality. The backing imho should not be managed by the URL-state, as it severely limits the size of the state we want to put in there, but the functionality itself is valuable. so +1 on @lukeelmers suggestion.
• seed new maps with URL. e.g. share a link to an unsaved map, but with some default config. Imagine e.g. a "map this" link for content listed in other parts of Kibana

[cjcenizal]

This is related to #8887. Feel free to close it if you feel it's outdated.

[stacey-gammon]

also somewhat related: #25247