Replies: 2 comments
-
It was a bug with the order in which I open a socket, start synchronizing, start auto saving/loading and registering the participant on the store. But I'm starting to realize that this order is not straight forward and simply using the useCreate* hooks lead me to this bug. I'm working on a React application that shows how many people are connected to the same "room" you are. There is a I have a room provider component that:
All using the UiReact hooks provided and that's how I got the bug described in the origin post above. It seems to be due to the order of operations, since I get different behavior when I move hooks up and down. I only managed to get it working after I abandoned the hooks and made a single effect that sets it all up. I still have a few kinks to iron since I mount/unmount the provider when the users move between rooms and I need to clean up the promises and lingering connection but I'm working on it. |
Beta Was this translation helpful? Give feedback.
-
OK, this is interesting. I'm going to turn it into issue #167 to track - ok with you? |
Beta Was this translation helpful? Give feedback.
-
So here's the situation; I have a typed store with a key
x
in Values, and I also am using a WebSocket synchronizer. Whenever a new client connects to the synchronizer server, the current value ofx
is overwritten with its default value.I was expecting the new client to receive the latest value instead of zeroing it for everyone.
Is that by design or a bug?
Beta Was this translation helpful? Give feedback.
All reactions