Persist middleware keeping old versions of functions around. Breaking apps when deploying to prod

[PaulSender]

Summary

I'm using the persist middleware to keep data available through multiple browser tabs. I recently made some changes to my store that uses the persist middleware. Mainly, I'm no longer exporting the entire store but just custom hooks as described here: https://tkdodo.eu/blog/working-with-zustand#only-export-custom-hooks. After I made this change I noticed my local browser environment was unable to find the new function changes I made. I checked localStorage and saw the new functions were not there but the old ones still were. This is the root of the issue. In dev land I simply cleared my localStorage and continued on. When I deployed the changes though, I naively assumed the browser storage would get recreated with a new build which it did not. As a result, user's saw the function not found error when trying to execute code that attempted to use it.

This doesn't seem like a bug really so my question is, how should I be maintaining a persisted store? I should be able to make changes to functions/state and have it not brick prod once deployed. Is there a way to clear localStorage when store changes are made? Is that even the right move? Also wondering what the best way to test something like this would be? Our E2E test pipeline didn't pick up the error bc cypress creates new browser windows for every tests (therefore side stepping this issue).

Any guidance would be appreciated.

Check List

Please do not ask questions in issues.

• I've already opened a discussion before opening this issue, or already discussed in other media.

Please include a minimal reproduction.

• Not sure how to repo this with a sandbox since its depended on localStorage functionality

[dai-shi]

Have you considered using migrate option?
Hm, I'm not sure if I understand the question. I hope someone can help.

[dbritto-dev]

@PaulSender you shouldn't persist functions, that could happen when you move functions into an object. So in order to exclude them, you should use partialize

[PaulSender]

@dai-shi @dbritto-dev thank you for the suggestions. I think either would work but let me explain a bit more.

At one point a function setTurns was in the store state. I learned this isn't a good practice so I moved it into an 'actions' obejct and exported it as its own hook (I should take it two steps further and remove the actions object all together and then update it from a setter to an event but that's a diff topic). So From:

export const useStore = create()(
  persist(
    (set) => ({
      ...initialState,
        setTurns: (newTurnsOrSetterFn: ReactStyleStateSetter<Turn[]>) => {
          set(({ turns }) => {
            if (isArray(newTurnsOrSetterFn)) {
              const newTurns = newTurnsOrSetterFn;
              return { turns: newTurns };
            }
            const setterFn = newTurnsOrSetterFn;
            return { turns: setterFn(turns) };
          });
        reset: () => set({ ...initialState }),
      },
    }),
    {
      name: 'store',
    }
  )
);

to:

const useStore = create()(
  persist(
    (set) => ({
      ...initialState, 
      actions: {
        setTurns: (newTurnsOrSetterFn: ReactStyleStateSetter<Turn[]>) => {
          set(({ turns }) => {
            if (isArray(newTurnsOrSetterFn)) {
              const newTurns = newTurnsOrSetterFn;
              return { turns: newTurns };
            }
            const setterFn = newTurnsOrSetterFn;
            return { turns: setterFn(turns) };
          });
        reset: () => set({ ...initialState }),
      }
      },
    }),
    {
      name: 'store',
    }
  )
);

export const useTurns = () => useStore((state) => state.turns);
export const useStoreActions = () =>
  useStore((state) => state.actions);

When the new code/app was rolled out, the old browser has a localStorage item that didn't have actions.setTurns which cause the app to crash.

So yes migrating to update specific keys or partializing to only persist actual state would work too.

I had thought I solved it by resetting the localStorage's store item to be whatever the current definition is onRehydrateStorage:

const useStore = create()(
  persist(
    (set) => ({
      ...initialState,
      actions: {
        setTurns: (newTurnsOrSetterFn: ReactStyleStateSetter<Turn[]>) => {
          set(({ turns }) => {
            if (isArray(newTurnsOrSetterFn)) {
              const newTurns = newTurnsOrSetterFn;
              return { turns: newTurns };
            }
            const setterFn = newTurnsOrSetterFn;
            return { turns: setterFn(turns) };
          });
        },
        reset: () => set({ ...initialState }),
      },
    }),
    {
      name: 'store',
      onRehydrateStorage: (state) => {
        localStorage.setItem('store', JSON.stringify(state));
      },
    }
  )
);

export const useTurns = () => useStore((state) => state.turns);
export const useStoreActions = () =>
  useStore((state) => state.actions);

but what that actually did was defeat the entire purpose of persist lol.

After some trial and error I figured out that separating actions from the store was the real solution here. Even when using partialize to only select the turns item and ignore actions it resulted in undesired behavior because the actions were still in the state and were therefore unset when loading the store from an old localStorage instance.

Solution here is:

const useStore = create()(
  persist(
    () => ({
      ...initialState,
    }),
    {
      name: 'store',
    }
  )
);

export const useTurns = () => useStore((state) => state.turns);
export const useStoreActions = () =>
  useStore((state) => {
    return {
      setTurns: (newTurnsOrSetterFn: ReactStyleStateSetter<Turn[]>) => {
        useStore.setState(({ turns }) => {
          if (isArray(newTurnsOrSetterFn)) {
            const newTurns = newTurnsOrSetterFn;
            return { turns: newTurns };
          }
          const setterFn = newTurnsOrSetterFn;
          return { turns: setterFn(turns) };
        });
      },
      reset: () => {
        useStore.setState({ ...initialState });
      },
    };
  });

I'm going to change this code to not have it in "actions" at all but wanted to share this code to help visualize what was going on. So totally agree that functions/actions should not be persisted, to take it one step further they shouldn't be in the store state at all. That's really the best way to use persist IMO. Much more simple than trying to fix persist things with partialize or migrate, but still very open to your thoughts. Still a noob at zustand

[dbritto-dev]

@PaulSender partialize is the right way to deal with that

[PaulSender]

What's the advantage to keeping setter functions within the state for persist use cases? Why not just move them out of state and avoid using partialize all together

[dbritto-dev]

@PaulSender that works too, but sometimes you don't want to keep some data. In this case the no store actions pattern works well.