Persist middleware keeping old versions of functions around. Breaking apps when deploying to prod #2556
-
SummaryI'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 ListPlease do not ask questions in issues.
Please include a minimal reproduction.
|
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 3 replies
-
Have you considered using |
Beta Was this translation helpful? Give feedback.
-
@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 |
Beta Was this translation helpful? Give feedback.
-
@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
to:
When the new code/app was rolled out, the old browser has a 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:
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 Solution here is:
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 |
Beta Was this translation helpful? Give feedback.
@PaulSender that works too, but sometimes you don't want to keep some data. In this case the no store actions pattern works well.