Persist middleware: can I await on a set operation?

[vaharoni]

I'm using AsyncStorage and would like to use the Persist middleware. I have a React page where I'd like some user event to save the data to the store and navigate to another page when this completes. The guide discusses the recipe of using onRehydrateStorage to set a flag when the hydration process finishes. But I did not see a reference for awaiting for the set operation to complete. In this discussion, the OP calls await set({ fish: get().fish + 1 }) inside the persist callback, but typescript does not agree that the persist's set function returns a promise, so I'm assuming such usage is incorrect.

What's the best practice here? Does the API expose a way to await the set operation? Or do I need to implement a store action that calls AsyncStorage.setItem, using the middleware mostly for reading but not for setting? Or is the idea perhaps to assume it will eventually be consistent?

[dai-shi]

Can anyone help?

[dbritto-dev]

@vaharoni I believe that you should create a custom storage

[dbritto-dev]

@vaharoni @dai-shi seems that setItem is not supporting async operations but getItem does

[vaharoni]

@dbritto-dev It's a React Native app using Expo

[vaharoni]

@dbritto-dev in the "How can I use a custom storage engine" section of the FAQs it suggests setItem of a custom storage engine can be async. Though I'm not sure custom storage engine solves the key issue here of the store lifecycle per my previous comment.

[dbritto-dev]

@vaharoni yeah, but in the code doesn't do that but. The types tell you something else, so I believe we should fix that

[dbritto-dev]

@vaharoni it should fix that

[vaharoni]

Eventually I noticed persist behaved funky for me also in the hydration phase - it seemed to ignore for no obvious reason some values that I verified were present in the AsyncStore. This totally could have been a bug on my end, but I ended up moving away from persist and implementing a code with less magic. That said, I saved a branch on the side with persist to help further test and investigate the issue if necessary.

Here's the code I ended up with. It's likely only suitable for small stores, as saving the state independently for each action could get old very quickly.

import { createStore, useStore } from 'zustand'
import AsyncStorage from '@react-native-async-storage/async-storage'

interface DisplayNameState {
  hydrated: boolean
  displayName: string
  actions: {
    setDisplayName: (displayName: string) => Promise<void>
  }
}

const STORAGE_ITEM = 'display-name-store';

const displayNameStore = createStore<DisplayNameState>()(
  (set, get) => ({
    hydrated: false,
    displayName: '',
    actions: {
      // This being async allows us to await
      setDisplayName: async (displayName) => { 
        set({ displayName });
        // removing actions - they are not serialized and we don't want them to override our functions during hydration
        const { actions, ...newState } = get();
        await AsyncStorage.setItem(STORAGE_ITEM, JSON.stringify(newState));
      }
    }
  })
)

export const useDisplayNameStore = (selector: (selector: DisplayNameState) => any) => {
  const { getState, setState } = displayNameStore;
  if (!getState().hydrated) {
    AsyncStorage.getItem(STORAGE_ITEM)
      .then(data => {
        const object = data ? JSON.parse(data) : {}
        const initialState = { ...object, hydrated: true }
        setState(initialState)
      })
  }
  return useStore(displayNameStore, selector)
}

Usage:

export default function MyComponent() {
  const { setDisplayName } = useDisplayNameStore(state => state.actions)
  const router = useRouter();

  // ...

  async function onSomeEvent() {
    // await here guarantees it is saved to the store before navigating
    await setDisplayName('test')
    router.navigate('somewhere')
  }

  // ...
}

[dbritto-dev]

@vaharoni btw, did you check it out the example that I shared you?

[vaharoni]

Which example @dbritto-dev? I don't see one in the thread.

[dbritto-dev]

@vaharoni here you go -> https://stackblitz.com/edit/nextjs-and-zustand-persist?file=README.md

[vaharoni]

Thank you for sending, @dbritto-dev. This uses LocalStorage in a web context on next.js. LocalStorage is a synchronous storage engine, so you don't need to incorporate async-await considerations. As I am using AsyncStorage on React Native, I don't think this applies here. I believe the asynchronous nature of that storage engine is where all the issues stem from.

[dbritto-dev]

@vaharoni actually, you can use the same approach