zustand-persist & Debouncing AsyncStorage #2400
Unanswered
KentonParton
asked this question in
Q&A
Replies: 3 comments
-
|
@KentonParton would you mind sharing us a minimal repro on stackblitz? I would like to help you |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@dbritto-dev Abian has done a great job implementing zustand-debouce which you will be interested in: https://github.com/AbianS/zustand-debounce |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hello Zustand Community,
I'm currently working on an application where I've integrated zustand along with its persist middleware for state management. The app tracks and updates certain user progress metrics (like audio progress in a podcast app) and persists these updates to AsyncStorage. Given the nature of my application, these updates occur very frequently (every 1s).
Here is a simplified version of my store setup:
I am concerned about the performance implications and the potential strain on the device's resources due to the high frequency of updates and writes to AsyncStorage.
Our requirement is that state updates in memory need to happen immediately to ensure the app's UI is responsive and reflects the latest user progress. However, considering the performance and resource utilization concerns with AsyncStorage, we're looking for a way to debounce these updates. Ideally, we'd like to accumulate changes and write them less frequently to storage.
Additionally, we have a specific case where we need to update AsyncStorage immediately: when a progress metric equals the duration (indicating the end of an audio track, for example), we want to ensure that this critical update is not delayed.
Question:
How can I implement debouncing for AsyncStorage updates in a zustand store, with the flexibility to bypass the debounce for immediate updates when necessary? Are there recommended patterns or practices within zustand for achieving this balance between efficiency and immediate data persistence needs? Any advice or examples on setting up such a mechanism would be highly valued.
Beta Was this translation helpful? Give feedback.
All reactions