feat: add persist middleware

[AnatoleLucet]

Hi 👋 I saw this comment so I've decided to open a pr for the middleware I've made and shared here.

I've been using it for multiples months on a project at work, and it actually works nicely given its simplicity.
But I still think there's some quite annoying drawbacks that we could probably improve:

• The obligation to give a name to the middleware. It'd be preferable to not hard code the name so the middleware could generate unique names/ids for the user. But I can't come up with a way to do this.
• Rehydration & merge & update of a stored state that has changed since. I don't think this is possible (?), but it still'd be nice to erase the old (incompatible) stored state by the new one (so there would be some data loss). I have some ideas on how to choose if the stored state needs to be erased or not, but I'd like to have the maintainers' opinions first.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit cced1a6:

Sandbox	Source
React	Configuration
React Typescript	Configuration

[dai-shi]

Thanks for opening up this. I'm happy to discuss and I also hope someone to chime in.

First things first, I would like to factor out localStorage and make it usable with AsyncStorage or any other storage implementations. How does that sound?

[AnatoleLucet]

For sure it sounds great. I've already responded to someone asking how he could port this to AsyncStorage.
I might need to give a glance at the hook first to understand how it works and how this could be done. But maybe you have something in mind?

[dai-shi]

Let me see, it shouldn't have to be a hook.

export const persist = (
  config,
  name,
  storage,
) => (set, get, api) => {
  const store = config(
    (payload) => {
      set(payload) // payload can be a function
      storage.setItem(name, JSON.stringify(get())
    },
    get,
    api
  )

  (async () => {
    const storedState = JSON.parse(await storage.getItem(name)) // needs error handling
    api.setState(storedState);
  })()

  return store
}

[AnatoleLucet]

That's nice. How should the error handling be done? By logging a message with the Error object?

[dai-shi]

Hm, don't know. It would be logged anyway. We need to think about the use case how we would recover from errors.

[AnatoleLucet]

Well, if an error is thrown during the parsing or the "getting" (getItem), it'll be caught (by our try/catch) before setting the state. So it shouldn't crash the user's app nor the store.

[dai-shi]

Are you sure? Not sure what is meant by "our try/catch".

Anyway, it can be an edge case. We can start trying our basic idea. How do we proceed? Does my code snippet really work? Would you try? Would you incorporate it in this PR?

[AnatoleLucet]

Are you sure? Not sure what is meant by "our try/catch".

  (async () => {
    try {
      const storedState = JSON.parse(await storage.getItem(name))
      api.setState(storedState);
    } catch (e) {
      // catches JSON.parse and storage.getItem errors
    }
  })()

Anyway, it can be an edge case. We can start trying our basic idea. How do we proceed? Does my code snippet really work? Would you try? Would you incorporate it in this PR?

I'll try it and if it does, I'll refactor the pr.

[AnatoleLucet]

How do you build the package so it can be linked? yarn prebuild && yarn build && yarn postbuild?

[dai-shi]

Just yarn build is fine.
Also, if you push the change into this PR, codesandbox ci will build it for you.

[AnatoleLucet]

@dai-shi it seems to work https://codesandbox.io/s/react-typescript-forked-rj85m?file=/src/App.tsx (you can try by commenting / uncommenting the useEffect).

[dai-shi]

Confirmed. 👍

[hmans]

I don't know if this would bust the scope of this change/feature wide open (I do suspect that it does, though), but how do you feel about expressing changes as JSON Patches (considering that atomic updates to a zustand store may affect more than 1 key)?

Having written this, I'm pretty sure that this would go beyond what you're trying to do here. I just wanted to point out that JSON Patch et al are a thing, and it would be great to have persistence glue based on it for zustand stores (it would allow some fun implementations of differential synchronisation.) If there is some interest in this stuff, I'd be happy to whip something up, as my current project is sort of heading into its general direction.

[dai-shi]

@hmans differential synchronization sounds interesting. we can try that road if someone is interested, but it can be another middleware as you implied.

This reminds me of something. How about factoring out JSON.parse/stringify and make them customizable? It should be easy if they are synchronous functions or even async doesn't matter. What do you think? @AnatoleLucet

[AnatoleLucet]

@dai-shi sure, why not. Do you think of a custom callback given through the arguments (then we might need to create an option object as the third argument of persist) like what we're doing with the storage? And only the parse/stringify or a whole set/get function?

[dai-shi]

Maybe parse/stringify only. We don't need to cover 100% use cases.
I might call it serialize/deserialize, but whichever is ok.
option object sounds good. I was thinking about two additional arguments, which can be too many.

[AnatoleLucet]

There you go.

[dai-shi]

Looks pretty good.

Feel like we should test it with RN. Any volunteers?

[dai-shi]

Should we have a small description in readme.md?

[AnatoleLucet]

Done https://github.com/AnatoleLucet/zustand/tree/feat/persit-middleware#persist-middleware

[dai-shi]

And only the parse/stringify or a whole set/get function?

Now, after looking at the readme, I understand what this really means.
If we customize the whole set/get, we don't need name and storage options, right?
But, maybe it's too much customization, and the current options are fine, I think.
Just want to make it sure if it's aligned with your thought.

[AnatoleLucet]

I was just thinking about letting the user do this whole async function :

  ;(async () => {
    try {
      const storedState = await storage.getItem(name)
      if (storedState) set(await deserialize(storedState))
    } catch (e) {
      console.error(new Error(`Unable to get to stored state in "${name}"`))
    }
  })()

But you're right, this is probably too much customization.

[dai-shi]

OK, we are on the same page. I'll think about again if we have a better option. I think our primary target is localStorage in web and AsyncStorage in RN.

Meanwhile, would you check #229 (comment) again? It's not resolved.

[AnatoleLucet]

Meanwhile, would you check #229 (comment) again? It's not resolved.

Done

[dai-shi]

Looks good!

[dai-shi]

I don't know why codesandbox ci doesn't finish until now, but let me merge it since all other tests are passing.

[calendee]

Thanks so much for adding this functionality! I had created my own wrapper for doing this in React Native & React Native Web. However, this is much more elegant!