Best way to memoize the data being persisted through middleware?

[denno020]

I have the persist middleware set up with a custom partialize function that will only return properties that I actually want to persist. The issue I'm seeing is that setItem is still called even if the properties being persisted haven't changed.

For example, lets take this dummy state object:

{
  currentUser: {/* User data */},
  links: [ /* ... */ ],
  theme: '#8dfd61'
}

Within the partialize function, we add:

Object.fromEntries(
  Object.entries(state).filter(([key]) => ['links', 'theme'].includes(key))
)

Effectively saying that we don't want to persist the currentUser property.

However, whenever the currentUser property changes, the setItem function in getStorage of persist will still be called, even though the data being stored hasn't actually changed.

I assume it's likely due to Object.fromEntries creating a new object, so a shallow comparison will always indicate false.

Is there a way to memoize this data at the partialize step, so setItem isn't called unless the data being saved has actually changed?

[AnatoleLucet]

Currently, if the Zustand state is set, persist stores the value in the storage. There's no memoization whatsoever.

For the same reason we introduced the merge option, I don't think it's a good idea to bring memoization as a built-in feature, it'd be a bit bloated. But something similar to #405 for a new callback (onPersistState for instance) would enable you to implement a memoization mechanism.
Feel free to open an issue/pr or add a comment on #405

[denno020]

Thanks @AnatoleLucet. I guess my main question is does it make sense for setItem to still be called, even though the data that is going to be set hasn't changed? Personally I didn't expect that to happen.

The side effect of this is if a user is doing an API call in the middleware and using a remote DB as their persistence store. If Zustand is calling setState every time any part of the store changes, then there will be API calls to store data even if it's the exact same data that is already in the DB. For one user this isn't a big deal, but at scale, when multiple users are using the app and hitting the DB, that could potentially add up to quite a cost for the applications backend.

[AnatoleLucet]

If by "making sense" you mean "having a purpose", it's no. There's no user requirement for this behavior.

[denno020]

Sorry, I don't quite follow.
Are you indicating that there's no requirement for setItem to be called after partialize if the data that is being stored is the same?
Or there is no requirement to prevent calls to setItem even when the data is the same?

[AnatoleLucet]

Sorry, yes, I meant there are no reasons not to prevent calls to setItem when the data is the same.

[denno020]

Okay great, we're on the same page! As for next steps, is it best that I create a detailed Issue outlining the feature request?

[AnatoleLucet]

Yes please, so we can track this feature request 👍