fix: WebSocket is closed before the connection is established warning
#8042
+28
−29
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
|
No changes to documentation |
|
Component Testing Report Updated Dec 13, 2024 4:31 PM (UTC) ❌ Failed Tests (6) -- expand for details
|
⚡️ Editor Performance ReportUpdated Fri, 13 Dec 2024 16:32:20 GMT
Detailed information🏠 Reference resultThe performance result of
🧪 Experiment resultThe performance result of this branch
📚 Glossary
|
stipsan
force-pushed
the
fix-websocket-disconnect-warning
branch
from
7705d14 to
8d2dc46
Compare
stipsan
commented
Dec 13, 2024
| @@ -16,7 +16,7 @@ export interface ResourceCacheProviderProps { | |||
|
|
|||
| /** @internal */ | |||
| export function ResourceCacheProvider({children}: ResourceCacheProviderProps) { | |||
| const resourceCache = useMemo((): ResourceCache => { | |||
| const [resourceCache] = useState((): ResourceCache => { | |||
There was a problem hiding this comment.
A great rule of thumb for determining wether a useMemo is safe and side-effects free is wether you can remove it and what happens to your app:
- a) it still works, but slower
- b) it breaks, or is so much slower it's unusable
In this case it's b), as the assumption here is that useMemo with zero dependencies means resourceCache will run exactly once, and have a stable instance for hte lifecycle of components calling it. This is false. In fact, it can choose to throw away the memoized value in certain suspense scenarios: https://react.dev/reference/react/useMemo#caveats
A better solution is to use useState, as it does have a guarantee that it's never throwing away the value, and it has a lazy init function so that our function that creates the map is still only run once.
This is also reflected in how much simpler the React Compiler optimization is for useState, compared to the useMemo.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Ever since I gave up on #7227 it's been in the back of my mind, and taunting me every time I've been in a studio and seen this warning:
That ends today, I've finally found a stable workaround!
At some point we should dive into
@sanity/bifur-clientand find out exactly why the observable teardown callingws.closecauses the warning, maybe we have to checkws.readyState? Maybe we can't avoid this warning if the observable is unsubscribed to before the connection is established, and while the warning is annoying it remains the right thing to do.Or maybe we should wait a tick
Promise.resolve().thenbefore creating the WebSocket, in case react does a new render asuserStorechanged so we avoid creating a resource that will be immediately closed anyway (we use this technique inreact-rx, as well as in@sanity/clientfor itsclient.listen()observable).I don't know, I'm not an WebSocket expert.
What I do know is that in #7227 the regression that lead to the WebSocket warning showing 3 times instead of just once, was because it shifted
useGlobalPresenceanduseDocumentPresencecompletely away fromuseEffecttouseObservablefromreact-rx.The benefits of
react-rx'suseObservableare many:useSyncExternalStore.rxjs, in a way that works with React 18 and 19 semantics and concurrent modes.But, since
useObservableis designed to allow synchronous emits, it warms up the observable you give it, and subscribes to it during render.Previously
useGlobalPresenceanduseDocumentPresencesubscribed much later, in auseEffect, causing the bifur websocket to be setup after react is done with initial renders.The reason why the issue is resolved this time around is because the observables aren't subscribed to until after an initial
useEffectruns and tracks mounted state. By the time this happens the dependencies forusePresenceStore(bifur,connectionStatusStore, anduserStore) have stabilized and we no longer see eager closing of the WebSocket.What to review
Hopefully this makes sense 🙌
Testing
I've tested manually with
pnpm dev, as well as the preview deployment and I've verified that the warning no longer happens.I've also verified on network devtools that there's only one websocket resource related to bifur.
Here's the before screenshot, that shows the eagerly closed resource with its
Finishedstatus, in addition to the live one with status 101, and withTimeset toPending(indicating it's open and active):And here's the after, showing only a single resource:
Notes for release