Reconcile server data, local state, session storage.
I'll try to be as succinct as possible:
The app I'm working on requires different views to be persisted for an ag-grid instance. We are loading all data (columns, filters, sorting etc.) from our API. But the client has the ability to lock a view - this will prevent any changes from persisting in the database, but will need to reflect in local state. A further complication - if the view is a master view, changes need to persist in session storage but will never update the db. So we are looking at three different states. I'm looking for a clean way to manage these states. I was thinking a custom zustand hook with an optional persist for master view, that can be passed as select function on data returning from the server (privileging local changes to column widths etc, but adding/removing deleted columns). If a view is locked, we update the state in this hook but don't trigger the rq-mutation.
Grateful in advance for any suggestions!
3 Replies
sensitive-blue•2mo ago
Have you had a look at https://tanstack.com/query/latest/docs/framework/react/plugins/persistQueryClient ?
persistQueryClient | TanStack Query React Docs
This is set of utilities for interacting with "persisters" which save your queryClient for later use. Different persisters can be used to store your client and cache to many different storage layers....
deep-jadeOP•2mo ago
Hmmm @Joshua I did take a look at it. What I'm not sure about is reconciling the two sets of data (eg. a column added to a project comes from server data, and all other column properties such as reordering or hide/show or width come from the persisted store). And then the further step of manipulating data but not updating the server with those changes.
required functionality is as follows:
Master view: all changes persisted in storage, but no changes sent to server. Changes to the master view (added/deleted columns) added to state - but local sorting/hiding etc privileged.
Saved view (unlocked): all changes in sync with server state (regular RQ functionality)
Saved view (locked): same as master view but not saved in storage, rather in local state (no need to persist). Unlocking a locked view updates the db with all current changes.
The thing I'm struggling with is that we are not just deriving state, we are changing it. So we have a necessary disconnect between server and local state.
exotic-emerald•2mo ago
Perhaps you could run all mutations through a single function which references what mode you are in and just performs the necessary actions.
You would only need to have some global state accessible to your function about whether it should:
A) only mutate the cache
B) only mutate cache and local storage
C) mutate cache, local storage and server.
Then just make sure that the only "entry point" for changes is through said function and all of your state can continue to be derived where the source of truth is TSQ.
There would likely be some extra technicalities involved of course but that's the first approach that comes to my mind.