-
Notifications
You must be signed in to change notification settings - Fork 5
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
support API for subscribeWithSelector
#2
Comments
Thanks for opening the issue. From what I found there are two possible ways to handle this:
This would result in the synchronisation across tabs happening whenever any value of the store changes. Obviously this would be completely overkill and unnecessary. But we could adopt this behavior so all properties of a store are synchronized, chancing the usage example in the README from This would probably make migration to the new version the easiest and maybe guide the user to create separate stores for synchronized and non-synchronized stores. I liked the old API and having both types of properties alongside each other, but forcing a separation of the two might make sense.
In this case the new version would be incompatible with older versions of zustand, but I guess this could work without any API changes, so I would tend towards this. If there aren’t any other comments until the end of march, I will move forward with implementing option 2. Sincerely, Tom |
Thank u so much for finding out the solution |
A little ahead of my self-set schedule, but I found the time to write the little note and guide on this issue to the readme here. |
Refs: pmndrs/zustand#603
The text was updated successfully, but these errors were encountered: