It is, isn’t it? 😮 Best I can come up with is: Like an owls hoot, but shorter, with one o. Still not quite right though. 🤔
Funnily enough the o in the English hot sounds like å. 😅
Introducing Public Beta for Shaders ✨
The wait is over 🎉 Try it now for @vuejs.org , @react.dev , @svelte.dev & @solidjs.com
We found that the fix to address the DoS vulnerability in React Server Components (CVE-2025-55184) was incomplete and does not prevent an attack in a specific case.
This is disclosed as CVE-2025-67779. New patches are available now, please update immediately.
Researchers have found two new vulnerabilities in React Server Components while attempting to exploit the patches last week.
These are new issues, separate from the critical CVE last week. The patch for React2Shell remains effective for the Remote Code Execution exploit.
There is critical vulnerability in React Server Components disclosed as CVE-2025-55182 that impacts React 19 and frameworks that use it.
A fix has been published in React versions 19.0.1, 19.1.2, and 19.2.1. We recommend upgrading immediately.
react.dev/blog/2025/12...
Just a headsup, I don't think that analysis tells the full story and might instil false confidence, see: react2shell.com
For anyone that missed it, the React Server Components critical vulnerability has a name and website now
Please refer to this before sharing any supposed POCs
react2shell.com
Does defer also guarantee rendering always happen on the client? My guess is no?
That's my understanding too, but it's not what I'm seeing at least in Next so might have been fixed there, or in general, or this only happens in certain conditions or for certain changes. 🤷♂️
Either way, I wont sweat about it until it becomes an actual problem. Still a good caveat to mention though!
Yeah, that’s a good point. I’ve never actually experienced this to be a problem in practice though. Maybe I’m just not observant enough but I like co-locating this kind of thing enough I wont stop doing it if I don’t have a strong enough reason. 😀
I've seen so many creative solutions to avoid hoisting, like mutating refs, misusing useImperativeHandle, syncing state in effects etc, etc, often leading to hard to catch bugs.
Just hoist it.
Hoisting state is so often the answer, but many devs avoid it because they want co-location.
Underrated solution: Export a hook alongside the component. Import and use the hook in a parent, pass the returned state down.
Now parent owns the state and can interact with it, but logic is co-located.
I finally found and fixed the unhandled promise rejection errors we've had in React Query for some time.
If you are using prefetchQuery() without awaiting in Server Components, you'll want to upgrade to 5.90.3 to get rid of those pesky "An error occurred in the Server Components render" errors.
Seems harder to work around, guess you would have to wrap the promise-generating API in something like const promise = alwaysSuspendInSSR(() => fetch(…))?
Besides being a bit ugly and not very straightforward to understand I’m sure this has other implications I’m not considering too though.
Only downside I see of this is that with const { promise } = useQuery(…); and use(promise) further down, we’d have to suspend with the ”useBrowserOnly” from the fetch and not the use, unless we build a wrapper around use() or leak calling the hook to userland which defeats the purpose.
React.use(React.isSSRInProgressPromise) 🙃😆
Landing an API that feels right for this might definitely take some thinking and iteration, I’m happy as long as it’s conditional! 🫶
Thanks, I agree. True algebraic effects in JS would be nice.
Do you know if there are any plans for notFound()/redirect() for these same reasons?
So if you prefetch, we render during SSR.
The conditionality would also let us make this behaviour configurable, so existing experiments with fetching in SSR would still work, and we could introduce this in a minor and keep existing behaviour and flip the default behaviour in next major.
For React Query it might be if it had useBrowserOnlyRender({ enabled: true|false }) or equivalent. If that hook does what I think (suspend on server, resolve in browser), we could use it in our useSuspenseQuery _if existing data or promise is missing_ to avoid fetching during SSR.
Isn’t that usually done by transporting the promise to the client, but still resolving it on the server though? Not sure I’ve seen any libs/solutions using infinite promises, so if you know any I would love to take a look!
In Next there is a super secret internal error you can throw to get around this.. 🫣🤫
I would never of course, let’s say I’ve heard it from a friend.
Getting the promise in there is no problem, what I worry about is, is it defined when React(/frameworks?) will stop waiting for that promise and release the stream? Even if stream is released, will request hang on the server and not close?
Btw, I don’t think this was an intentional API design choice. I think when useSuspenseQuery was built it just ended up doing the same thing on the server and client because SSR wasn’t part of the suspense story yet.
I agree with you that erroring by default in SSR would be less of a footgun.
I would also love a way to cleanly suspend on both server and client, but only fetch on the client. I’m not sure if this is possible though. We cant just suspend with an infinite promise on the server. Ideas are welcome. 😀
Depending on your retry settings, that error might get retried and fetched on the client instead. This kind of achieves what you want, but in an ugly way (via errors).
So we pass the option to you. I’m throwing a ”Missing prefetch: …” error in the app I’m working on, this is something we should document.
The swr and RQ APIs are quite similar in this regard with the exception you mention @tom.sherman.is, if you forget to provide data for a query via HydrationBoundary/initialData, RQ will actually fetch, while swr will error.
You can still error in userland by configuring your fetcher to do so.
Agreed, and also, some advice is great for new projects but not worth the change and/or fragmentation cost in existing ones. I will also definitely be having this in mind next time I set up tests.
Just to be clear, they are still very, very common and there is nothing wrong with them, it’s just the stats I’m pushing back on, not the conclusion. 😀
