[docs] initial docs for syncing state #159
Conversation
facebook-github-bot
added
the
CLA Signed
| ```jsx | ||
| function CurrentUserIDSubscription() { | ||
| const [currentUserID, setCurrentUserID] = useRecoilState(currentUserIDState); | ||
| let knownServerCurrentUserID; |
There was a problem hiding this comment.
knownServerCurrentUserID should be stored in React.useState so that changes to it will be able to trigger the useEffect
There was a problem hiding this comment.
I updated it with useRef; what I get for writing at 3am.. ;)
| const setStatus = useSetRecoilState(friendStatusState(id)); | ||
|
|
||
| useEffect(() => { | ||
| RemoteStateAPI.subscribeToFriendStatus(id, setStatus); |
There was a problem hiding this comment.
Is it worth making it explicitly clear that it should be taken into consideration that if this hook is used in multiple places, each instance will separately create a subscription?
There was a problem hiding this comment.
Yeah, I can add a note. So far, syncing remote mutable state via Recoil isn't a common use-case internally, so we can do some more iteration to provide a more robust example/approach for this use-case. It would be nice to incorporate more of a singleton pattern here. But, as also mentioned, lifetimes of components using a friend directly may not match lifetimes of selectors using a friend. The cleaner answer here may also be related to async query cancelation and memory management for atom/selector lifetime. If we have an API for that we could perhaps use it for this as well.
| }; | ||
| }, []); | ||
|
|
||
| // Subscribe atom changes to update server state |
There was a problem hiding this comment.
I wonder if it's worth making this a little bit more robust, e.g. by including timestamp comparisons, or version counters.
Right now I think there is a race condition if the Recoil state is updated at roughly the same time that the remote values changes.
There was a problem hiding this comment.
It also suffers from redundant setting of the local atom if the user sets it and the server mirrors back the change to all subscribers, though the value should be correct. Yeah, just wanted a simplified example, but I'm not very keen on it so far. Could definitely be improved.
resolves #143
resolves #149