Related to: #84561

Problem

In the Time to Visualize project, embeddables can be stored by value inside dashboards. When a panel is stored by value, its state consists of all input required by the embeddable type instead of the panel's state consisting only of a saved object ID.

Currently, when a dashboard is in edit mode, the state of every panel is stored in the url, even the much larger by value panels.

To illustrate the problem, here is a quick comparison of edit url length:

Doing a rough estimate / extrapolation it seems like a dashboard with 200 complicated by value panels could potentially exceed chrome's 2MB limit.

It's important to stress that crashing chrome like this is an unlikely edge case, therefore I wouldn't consider this a blocker for flipping the allowByValueEmbeddables switch. That said, releasing a project which balloons the url length without a plan to mitigate it doesn't seem like a great idea, not to mention the aesthetics of gigantic urls.

A Solution

Recently, the state of dashboard panels in view mode was moved from the URL to state storage, which significantly cut down on the URL length in view mode.

I would suggest removing panels from the url in edit mode as well. Instead, the current state of the dashboards panels would be stored in sessionStorage, in a new object where the keys are dashboard Ids, and the values are listings of dashboard panels. When a panel is edited, removed or added, the sessionStorage is kept in sync. Saving would replace the panels in the saved object with the panels from session storage, and canceling the edit would do the reverse.

This would allow us to persist unsaved edits to multiple dashboards over reloads and navigations. If we go with this solution, we will have to take into account a number of considerations:

Considerations

Potential for Data Loss

There is a concern that removing the unsaved edits from the url could result in the loss of this data. This concern could be mitigated with the following changes:

• Storing unsaved panels in session storage would mean that the data would only be lost when the session is ended, i.e. when the browser tab is closed.
• The OnAppLeave handler will be used to ensure that the user doesn't leave dashboard with unsaved changes [Time to Visualize] Dashboard Warn on App Leave #81360

Snapshot sharing

Currently, users are able to share unsaved edits to a dashboard without using the short url function. This lets users without write privileges share unsaved edits to dashboards. This functionality could be retained with the following implementation details:

• When loading a dashboard: if panels were provided in the url from a snapshot share, push those panels into the session storage and remove them from the url. If there are panels in the session storage, load the dashboard using those panels, if not use the panels directly from the saved object.
• When sharing: Select short url by default. When snapshot share is selected and short url is deselected, show a warning that the url can be very long. Pull panels from the sessionStorage to create the full snapshot url as before.

Undo / Redo

Currently, panels in the url provide implicit undo / redo behaviour via the browser back and forward buttons. If they were removed from the url, we would have to provide an alternative means of achieving this such as memory based undo / redo #8887. This is an area with a big potential for improvement, since the current implementation has many problems that can be solved with this approach.

• Changes to the navigation can get lost because each panel added pushes a new url to the browser history.
• Pressing back accidentally (via a mouse button or a swipe maybe) can actually remove a panel. If a by value panel is removed like this the user could lose work.
• It's not obvious that the browser back and forward buttons provide this feature, because this is non-standard

UX Improvements this could unlock

• It could be implemented first in the dashboard_state_manager then standardized for use in other applications.
• We could potentially hook up this undo redo system to the shortcuts ctrl + z & ctrl + y which are industry standard
• We could provide a ui in the new dashboard toolbar that includes undo & redo buttons.

Open Questions

• If we implement in memory undo / redo, it would be a separate initiative from Time to Visualize? I would hope so.
• If that is the case, would it be acceptable if there was a minor in which undo / redo on dashboards was not possible?