This Suspense boundary received an update before it finished hydrating
danilofuchs opened this issue · 12 comments
When adding <SpeedInsights /> component to our Next.js application, we receive this error on Sentry and locally:
This Suspense boundary received an update before it finished hydrating. This caused the boundary to switch to client rendering. The usual way to fix this is to wrap the original update in startTransition.
Seconded. Here is video of the error, and then when I comment out <SpeedInsights />, it goes away.
Error:
I think it's worth noting that we are still using the pages directory.
Hey all! Sorry for the inconvenience.
Can you please provide us a simple replication repository to dig into this? Thanks for your help!
Hey all! Sorry for the inconvenience.
Can you please provide us a simple replication repository to dig into this? Thanks for your help!
I could give you temporary access to our repo potentially, but I don't have time to spend debugging this honestly.
I can note some things we use: React Query, pages directory, styled-components, dynamic imports, etc. you can see in my shared video above that it is most definitely the SpeedInsights component causing the hydration error. I'm assuming it's the Suspense component being used within pages directory, as I've ran into that before.
Is there a bare minimum codesandbox for the pages directory? I am only seeing a codesandbox for the app router. Going to try and get something together because I am tired of seeing this issue.
Edit: please link it if there is
This was fun lol, spent all day trying to replicate by creating a small reproduction of our site in totality and by removing items from our build one by one to find a root cause. Found the culprit in our case, a hook we used that didn't handle an effect properly. Really wish the error had more info to deduce this easier, but glad to have figured it out! Sorry for the noise here.
this is happening to me as well: i'm getting the error message, and poking around the call stack reveals it occurs when rendering <SpeedInsights />, and sure enough, removing speed insights silences the error
i'm willing to accept that it might be caused by some other code, but speed insights is certainly a catalyst in some way
my app seems to change props.route rapidly on load, which triggers this effect:
i believe if that effect was a transition instead (or additionally), it would make react chill out a bit
i'm still investigating why app.route changes so often...
the other patch that might fix it for me (my two props.route changes are to the same string), is the script.dataset.route gets modified, even when the strings are equal, which creates an unnecessary dom change:
it might also resolve it to wrap that in a check
setRoute: (route: string | null): void => {
if (route !== script.dataset.route) {
script.dataset.route = route ?? undefined;
}
},
or you could put that check here:
else if (props.route && props.route !== currentRoute)
I'm having the same issue but I can't reproduce it, it occurs only at times as I found it in our logs. Is there any solution for this?
Additional information:
- Next.js 14.0.14
- Pages router
<SpeedInsights />is included in_app.tsx
Same issue for me with Next 14 and pages.
Added the SpeedInsights into _app.js
Hey all.
We were also facing the same issue with pages router in _app.js. This was happening because one of our providers was causing a re-render multiple times. For short term, I moved the <SpeedInsights /> component outside all providers. For long term, will be refactoring our provider to fix this properly.
Something like this.
export default function MyApp({ Component, pageProps }) {
return (
<>
<Providers>
<Layout>
<Component {...pageProps} />
</Layout>
</Providers>
<SpeedInsights />
</>
);
}Hope this helps someone.
Even moving <SpeedInsights /> outside the global providers and into a <React.Fragment> does not seem to solve this issue for our application using NextJS v13.5.6 and SpeedInsights 1.10.0.
Moving <SpeedInsights /> into _document.tsx does, however, seem to resolve this problem. Though, it will cause an error on the server instead.
EDIT: I managed to track down where the issue originated; as others have pointed out, it had to do with "bad effects". In this case, we accessed a global store in _app.tsx which was also updated shortly after rendering the page. Even though it resolved with the exact same value on the next render it still managed to cause issues.