Open amcclain opened 2 years ago
Sounds great to me! Will be awesome to build the generic version of this, and start standardising our somewhat haphazard implementations. Particularly like the emphasis on making it easy to ignore w.r.t "you have unsaved changes" - catching and blocking on those actions is always problematic.
A couple of thoughts / questions:
PersistenceManager
context? Current behaviour would go back to code defaults, but a user could reasonably expect it to go back to the saved state (or switch to a centrally managed 'default' state). Especially weird since in most cases "Restore Grid Defaults" would actually make a 'clean' managed state > 'dirty'. Perhaps the easiest solution is to provide a way for components to detect when they are being managed by a PersistenceManager
, and drop such affordances, relying entirely on the managed state?Have set up something very much like this in a client app, using JsonBlobs for storage - happy to demo/review that anytime
Thanks for looking over this carefully.
Should we always allow the user to "Save As", even if they don't have local modifications?
Yes, agree - no reason to prevent that, very standard operation to save as before editing.
We need to be careful about built in affordances that claim to reset state, e.g. "Restore Grid Defaults" in the context menu. [...] Perhaps the easiest solution is to provide a way for components to detect when they are being managed by a
PersistenceManager
, and drop such affordances, relying entirely on the managed state?
Great point. and agree that we need to have a plan here. I think we support hiding the restore option on colChooserModel, and you can pass in a custom grid context menu, but doing that every time would be tiresome. Might cause us to revisit the work we just did around support for custom restoreDefaultsFn
- in this case, you might wish to completely intercept/override the default behavior...
Let's make some time next week to discuss in more detail - I will loop back with @lbwexler and get his thoughts on priority. The use case in the client app doesn't look like it's urgent - still important, but we have some time - and while I think this will be a great win for Hoist, we don't want to rush it!
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.
PersistenceManager
/PersistenceManagerModel
User-facing UI
Developer API
observable
and also via aPersistenceProvider
that could be bound directly to any component/model that supports Hoist persistence.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.