-
-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Custom function to apply future and past states #152
Comments
Hey @alexanderhorner, Thanks for the comment! Have you checked out the I should update the readme, but this can support diffs or patches. |
Yes, I've tried to implement patches with that, but i didn't manage to get it to work with deeper objects. Are you sure this supports this? The example in the documentation saves patches like "path.to.deeper.object.poperty", but this will just create a key named |
Ah, you're right. The example documentation isn't helpful in your case. I believe achieving your intended use case is possible, but the docs provide an example for a different use case. Have you looked into doing something like this? https://stackoverflow.com/a/20240290/9931154 I'll update the docs to support this method because I think it's what developers usually want. Thanks! |
I have looked into something like this. The problem I have is I don't know how you would actually implement that, but maybe I just didn't understand something correctly? The diff method is only usefully when saving past states/pushing new states, right? When applying (so when calling undo) it will just take whatever is in the past state array and call the set() method of zustand, wich uses Object assign I think. Object.assign(
{ a: { b: 1 }},
{ a: { c: 2 }, d: 3 }
); will just result in {
a: {
c: 2
},
d: 3
} |
I've been playing around with the The user could then use optics-ts or Ramda as mentioned in the zustand docs. |
A few hours later, I got a diff-based temporal middleware working, after dropping zundo's files into my project. I didn't have the time to make it non-intrusive and make a PR, and it may be a bit brute-forced (with the help of GPT): Additional
|
When invoking the undo or redo actions, the current implementation sets the state using the default set function provided by Zustand, which, if I recall correctly, relies on Object.assign. Enhancing this by allowing customization of the set function would be helpful.
A practical application of this could be optimizing the size of future and past states by storing only differences or 'patches'. This is already feasible for shallow state structures but poses challenges for deeper objects. By enabling the set function to be customizable, one could apply changes using a bespoke function before updating the currentState.
The text was updated successfully, but these errors were encountered: