Accessing previous value in persist setItem

[TeemuKoivisto]

Hey, I've been a happy user for a zustand for some time now. Just now I've started to integrate my zustand stores with IndexedDB (through Dexie) and I noticed one rather annoying aspect of it.

Mainly, as I am using import { persist } from 'zustand/middleware' and setItem: (name, newValue: StorageValue<State>) => { to update my IndexedDB, there's no built-in way of accessing the previous value of the state.

This would be rather useful as I can't reliably check what has changed so I have to run complicated db.table.bulkPut logic for every tiniest change that might not change anything in IDB. The performance implications of this might not be huge although with large in-memory datasets and lot of updates to the store, it could cause unnecessary CPU & memory use on mobile devices especially.

Could this value be provided as 3rd argument?

[dai-shi]

I wonder if creating a custom storage would work it around:

const createCustomStorage = () => {
  let prevValue;
  return {
    getItem: (name) => {
      ...
    },
    setItem: (name, newValue) => {
      ...
      prevValue = newValue;
    },
    removeItem: (name) => {
      ...
    },
  };
};

[TeemuKoivisto]

Here's a sandbox https://codesandbox.io/p/sandbox/fwq5dr Inside store.ts you should get a TypeScript error. LocalStorage doesn't work inside an iframe so don't mind that

[dai-shi]

Here's the same one with TS playground: https://tsplay.dev/WYxAQm

Here's the modified one using partialize: https://tsplay.dev/WkZ4lm
(We don't need merge because the default merging is fine in this case.)

[TeemuKoivisto]

There is something seriously wrong with that type checking as this compiles Playground Link But, I see there's a partialize method and second generic argument for the persisted state.

Although if you have them defined as generics in the interface, you should use that instead of manually typing the function parameters. satisfies operator is basically made for this Playground Link

But this doesn't seem optimal to me also. Well, for some reason partialize breaks with satisfies but now within setItem I can no longer see the complete state—only the persisted value. So if I have some local variable that I use for eg. caching the persisted values, I no longer can see it. As a side-note, doing this PersistOptions<S, PersistedState = S> and then storage?: PersistStorage<PersistedState> | undefined; export interface PersistStorage<S> { breaks my brain. Is PersistStorage<S> now PersistOptions S or PersistedState?

Anyway. I think I've had enough and just manually type the values and be done with it. I don't think either of us ends up any wiser.

[dai-shi]

Yeah, { foo: 1, bar: 'a' } is assignable to { bar: string }, so we have to do runtime type check. In this case, it's easier to avoid objects and use primitive values instead.

In summary, this is what I would do: https://tsplay.dev/NrZ0zN

Thanks for raising this up.

[TeemuKoivisto]

That looks better! Thanks for the help