What happens with a multi-store model?

[feuersteiner]

Hi, well done for the work on Zundo, love it.
question if self-explanatory, I am using zustand with a multi-store schema, example:

• bear store
• honey store
  I like them separate to minimize the surface of error (rerenders, mistakes, cleaner code...).
  I looked into the demos you provided, yet, not sure how that works if I have multiple stores.
  Thanks for your help!

P.S. if not implemented yet, would love to help when time allows

[charkour]

Hi @feuersteiner,

Glad you appreciate zundo!

If you have two stores, you can wrap each of them in the zundo middleware. Do you want to undo them at the same time? If so, there isn't a built-in way to do that, but you can create a function that calls undo in both stores.

If you provide a code sandbox, that will give me a better idea of the context of your question. Thanks!

[feuersteiner]

thanks for your response @charkour

I'll better explain it:

• I have a design app, with multiple stores for different types of design params
• the stores are independent
• changes are triggered by the user, mutating one store at a time

the expected behavior is, being able to deliver do and undo to the user, i.e. :

• undo knowing which store have been mutated last
• keeping track of the changes
• reverting if needed (the typical redo)

as I understand, Zundo delivers that on a "per store" basis, so my understanding is that, in my case, I am going to handle which store was mutated last, and call its undo/redo.
While I can do that, I just wanted to check with you if you plan to have this implemented (again, would love to contribute)

[charkour]

Hi @feuersteiner,

This is a great explanation of the problem you're facing. I think zundo should be able to support this in the future, but currently, it does not.

I'm nearing the completion of v2 of zundo (#43) and you can see the progress there. I'd love to discuss with you how we can best implement this feature. And I'm happy to have you contribute that to version two.

What sort of API would you like?

const useTemporalStore = trackHistory(store1, store2, store);

const { undo, redo, clear } = useTemporalStore();

[feuersteiner]

I think that looks neat, there's a case where some stores addition to the "undo stack" is useless (example: settings store).

I agree with the design.

Once V2 is shipped let's talk, don't want to overwhelm you.

But yeah, we can have an issue somewhere where we can spec the feature and open it to other input from the community, what do you think ?

[charkour]

Sounds great! If you want, you can create an issue and start to spec it out whenever you want.

I think it's a fantastic feature and not one I needed when I originally started the project, but I can see others requesting it as well. Thanks!

[ohthepain]

I would also like to implement undo and multiple stores or slices.

[charkour]

Thanks, @ohthepain

If you make a PR, I'd love to review it!

[feuersteiner]

hey @charkour, although I had different stores at first, I pivoted to a single store strategy concerning the main features, and considered adding more "actions" and using Immer's "produce" to ease the headache. Will be using the package as is once the site's is up. Thought you'd want to know that.

[charkour]

Thanks for letting me know!

[maliuta-oleksandr]

Is it also about Slices Pattern / BoundStore ?

[alexanderhorner]

The great thing about Zustand is that it's so flexible, so really no wrong day of doing it if it works.

I think generally Zustand recommends having one big store in favor of multiple. I split my big store into multiple slices to make it cleaner and more readable, but its still one store and changes are tracked together. Semantically i think this makes more sense, since you have one application state you want to react to and track. Having multiple stores can also introduce race conditions and zombie children and annoying stuff like that. I experienced this in my app wich manages its state in one big store, but also uses reactflow (graph library) wich also uses zustand under the hood. Just something to consider :)