New `PersistenceManager` component

[amcclain]

I'd like to propose a new component and model to provide out-of-the-box support for user-managed collections of named, persisted state objects - e.g. grid states or dashboards. While the proposal below would not replace all of our current bespoke in-app implementations of similar features, it would aim to cover the "80%" use case, with room for future development.

• Proposed name (tentative): PersistenceManager / PersistenceManagerModel
• Overall goal: allow a user to select from and manage a library of persisted state bundles for common use cases such as grid views, dashboards, and other app-specific state, with a simple/intuitive UI and minimal requirements for app-level integration.

User-facing UI

• UI would be minimal - e.g. a button displaying the name of the currently selected state, with a drop-down menu and modal prompts/dialogs to support such user actions as:
  • Selecting another available state object to set as current.
  • Saving the current state, if modified, with the option to "Save As..." a copy with a new name.
  • Resetting the current state, if modified, back to its last-loaded version.
  • Deleting saved state objects that are no longer needed.
• When state is dirty (e.g. grid columns adjusted, dashboard widgets added/moved), the component should clearly indicate as much, providing the user with an option to Save/Save As - if they choose to do so.
  • The user can also choose not to save dirty state, in which case any changes will be discarded upon app reload or a switch to another state.
  • Deliberately not proposing any kind of autosave at this point.
  • Also would like to avoid "you have unsaved changes" prompts, which are often disruptive. Goal is to treat these states as relatively lightweight, easy-to-reconstruct objects that introduce minimal cognitive overhead or friction for the user - i.e. you can just not touch it, and you don't be prompted to make any decisions.
• Shared/centrally managed state options might also be displayed if available (see below). These should be clearly distinguished from user-created and managed options.
• We could target desktop initially, but should keep mobile in mind for a quick follow-on impl.

Developer API

• From the developer's perspective, the new model would expose the currently selected state as an observable and also via a PersistenceProvider that could be bound directly to any component/model that supports Hoist persistence.
  • Goal of the built-in persist provider is to make the component as easy to drop in and get started using as possible, leveraging the work we've already done around persistence.
• Backing storage of saved states could be provided by JsonBlobService, with minimal setup required to start listing and saving blobs of a particular type. We can discuss if an alternate or customizable storage mechanism is warranted for a first iteration.
• Centrally managed or shared state configs could be optionally supported by creating JsonBlobs (via Admin console or other means) of the configured type, not owned by the user, but with an open ACL.
  • The component would display these to the user, marking or styling them somehow as centrally managed / shared.
  • User can load a shared state and immediately start making changes. If they wish to persist their changes, they should have the option to "Save As" to create their own copy, now entirely independent from the shared blob, which they can go on to continue modifying and directly saving in place.
  • End-user-driven shared state is not proposed for an initial iteration.
• We can discuss if we want to support specifying default / starting state in-code, without the need to create a shared JsonBlob.