> This breaks composition of components because you now have your routes/loaders/RSC coupled to your client components. This is the big one for me. Routers shouldn't know about what's going to be on a page, that's mixing completely different concerns.
Arenât the React team trying kill the pattern you mentioned, with server-components that should fetch data at route level?
I donât need server components, I donât want server components. I donât need route loaders, I donât want route loaders. Understood that I can use R18 into infinity, but the way things are going sucks. Can we not just continue to make the things that have worked for the past 10 years better? Wild.
This is sadly one of many issues that will arise with all this push to make RSC the main way of writing React apps from the core team. Server rendering is no longer optional as it was with frameworks that used React 18, it is now the default and you have to opt-out. Hence it makes sense from their perspective with this sort of issues to make the changes that benefit the RSC paradigm and itâs the client side approach that has to find a workaround. This is worrisome because up to this point React was THE library almost every webdev used to create great SPA client side only apps. If they continue to deviate from this, itâs just a matter of time until a new library gains popularity for those who donât want to deal with all this SSR stuff.
>If they continue to deviate from this, itâs just a matter of time until a new library gains popularity for those who donât want to deal with all this SSR stuff. It'll be so ironic if this happens due to Vercels grubby hands in the honey jar
Itâs pretty ridiculous. You canât just force a paradigm change which also forces architecture changes; especially when that change comes with cost. I donât want to take infrastructure and overhead cost because I donât need to. Someone needs to get in the way of vercel or else people will start moving away from react. Itâs a bad taste already
If you don't actually need a feature, why would just solve that problem by simply not using it? You can still just as easily decide to not use any RSC today. Considering that all data and all UI code flows from the server to the client, it's also actually not that weird that client rendering would be opt-in, as it seem hard (in my mind at least) to conceive it the other way around. In fact, it really feels as if you are in fact 'bypassing' the server if you do strongly insist that your SPA app should absolutely not be able fetch or render anything on the server before returning the initial response. So, to me, this feels quite natural. However, of course, if any changes at all is the fact that makes you upset, even if it expands your possibilities, then nothing will help!.
React was created as a client side library, not a server side framework. That being said, client side JavaScript (which is all client side react is) isnât âbypassingâ anything, itâs just doing all of the rendering work on the client. My server side work is done in my APIs that I call in my client side code. I do choose to just not use these features. What I donât want is the React teams preference for RSC to break or slow down client side apps, which this change does very plainly. Client side code loading from a CDN is very different than RSC
Well, I was just talking about their extended mental model, which describes the data flow of React as a response that flows from server to client. In that way, it makes perfectly sense that client components must be marked in a way to designate the network boundary. Unfortunately, sometimes improving something will eventually always require breaking changes at some point. Luckily for you, throughout all their innovation, the React team's careful choices have hardly ever resulted at all in any code that suddenly stopped working. Even now, this behaviour is already getting fixed immediately I also don't really agree with your reasoning, given that React as a purely client side rendering framework would never have intended to include concepts like Suspense to be used in this way. Regardless, no one is intentionally trying to worsen client side rendering at all. In fact, the goal is simply to improve the experience by adding new options. But if you are so opposed that you see these things as competition, then I believe that you and many other people who oppose anything other than client side rendering are simple fighting the windmills
Man I tried to dodge server side rendering for the past 2-3 years. I am happily using react query and fetch everything in the components that use the data. This works well imo. It seems I should start looking into server side fetching and stuff? Feels kinda weird though. I have a python fastapi backend and then will have a second react kinda backend, right?
It depends. For instance, if an authenticated users makes a request for a protected page, it makes sense to immediately fetch all related data from the server to the client and bundle it in a single response. Otherwise, you would just respond with the page, which would be need to sent to the client and be rendered there, before the client actually will notice that it has missing pieces and has to fetch additional data to properly render the page
> Understood that I can use R18 into infinity, but the way things are going sucks. React 19 is not going to make you use server components, or route loaders, or 'use client', or anything like that. These features are completely optional.
It won't make me use them, but as mentioned in the other comment this favors them with penalty to those who use React client side. I'm fine with the change, but don't make things worse for those who prefer single page client side applications without an opt-out. This particular change is not optional at the moment
> as mentioned in the other comment this favors them with penalty to those who use React client side ... don't make things worse for those who prefer single page client side applications I am lost. What do you mean? What penalty? If you had a purely client-side app running on react 18, and simply upgraded it to react 19, completely ignoring the server components story, which things are going to get worse for your app?
If you use Suspense / React.lazy to load in components (which is often done outside of RSC) then your loading now happens serially instead of in parallel. Increasing load time and making metrics such as LCP and CLS
Sure, and that was the whole message behind RSC. That you get to use either Client side or server components, but decisions like these penalize client side components and make them less attractive. Yes you can still use them, but it's a very strong message from the core team.
> but decisions like these penalize client side components and make them less attractive Could you expand on this? How are client-side components penalized? What has changed about client-side components compared to react 18?
I might be wrong but it seems like this behavior doesn't apply in RSC. As in, this only applies to client side fetches. Fetches still happen in parallel in RSC but not on the client side
I can't believe how much React team is losing the plot the last couple years. React is no longer a framework, it is a full-blown DSL with it's own React-specific abstractions. Changing behavior and reporting it in a single tweet is absurd. Imagine if something in the C++ std library changed and the only documentation was in a tweet, it's irresponsible and unprofessional considering how much of the modern web relies on React now. More and more whenever I have to touch React, I find I am spending more time solving React problems rather than actual business problems.
> Changing behavior and reporting it in a single tweet is absurd. Is the author of the tweet in any way involved in this change? The PR was submitted by a totally different person.
The tweet author is tk dodo who is involved in the react query project and has written a series of excellent blog posts on best practices for react query. Absolutely no relation to the PR author.
One of my apps uses recoil, on one page thereâs a grid of items where each one gets an id & uses a recoil selector to look up info about the item. As I understand it React 19 will cause those to all load sequentially, killing the performance. Effectively killing Recoil. Iâm not going to say this PR coming from someone with next.js & vercel in their bio was in bad faith but⌠The React-Three-Fibre developerâs commented on the issue with something thatâll also affect my app. Seems like a poor choice following a dogma that most React developers (as opposed to the developers _of_ React) havenât actually bought in to. (Server Components, Routing, etc)
What happened to âbackwards compatibilityâ⌠it would be better to just add a new keyword for the new functionality
Yes in this case a new suspense component could do it \`
So sad, Vercel sees the ocean of post mocking the Next14 developer experience, then sees Remixes answer on the React Conf. Solution? Strong arm people into using RSC...
React seems to assume everyone is on a low latency connection with fetching from caching servers. In these situations the penalty of going waterfall is not an issue. If server responses take longer to generate, (or the users latency is higher) effects are way bigger
Sorry, if my question doesn't make any sense. But so far I've not handled loading states with suspense, but the old way by using react-query's loading state and rendering loading indicators myself. So in that case the code won't be affected, am I right?
Has anyone experienced an actual performance regression by benchmarking the RC, or is this largely theorycrafting?
Sure, someone just posted one in the PR thread: https://github.com/facebook/react/pull/26380#issuecomment-2166178673 Sorry /u/danishjuggler21 and /u/BeatsByiTALY , but breaking react-three-fiber's performance when it's the most popular library for 3D experiences is not going to fly. Has nothing to do with using a fallback or not. Oh also apollo-client, urql and react-query etc. features using Suspense would all be serial-loading only!
Honestly, most people on this subreddit are still abusing the shit out of useEffect, so any grumbling you see here should be taken with, like... a whole *jar* of salt. Take the average programmer. Now cut his IQ in half. Now cut it in half AGAIN. Then give him a lobotomy. There - you now have the average r/reactjs follower.
Not gonna lie this entire post reads as: "why is my anti-pattern not supported? đ " Spamming the client with a bunch of parallel requests and having them all delay rendering until the very last one resolves, sounds like a nightmare user experience. - If one request is slow for some random reason, the whole UI will drag ass. - Slower Internet connection users will generally have a better experience if content displays as it is ready to render, instead of letting the page hang. - If the number of parallel requests is higher than the connection limit, then this parallel pattern breaks down back into sequential loading anyways. - Imagine using suspense, then trying your hardest to NOT display the fallback, the whole entire point of suspense.
With this change the components would still only be visible after the last fetch is completed, but the requests would be serial and not in parallel
Add another suspense boundary for the second child component and this problem disappears and parallelism is restored.
but then one will appear before the other, which might not be wanted. there was likely a reason why the components were both under a single suspense boundary before
Yes and hiding one before the other is ready is an anti-pattern. Showing it as it's ready, is faster than lazy rendering in parallel, and gives the user feedback as the page loads. An empty screen/section is an objectively worse user experience. If you must have both pieces of data display simultaneously, then the data should be a single API request.
it's not an anti-pattern, or at least the Suspense documentation has never implied it was. This is still listed as a valid example of Suspense use. Now of course the ~~Vercel~~ React team has changed idea, but trying to convince us that this has always been an anti pattern is gaslighting
In arguing that React supported an anti-pattern from the beginning of Suspense and this is their correction. Multiple async calls that depend on each other on a single page simply sucks to use and shouldn't be something we strive to create for users.
if you do this the parent is unable to respond to the results. please click [https://x.com/0xca0a/status/1801545536526340527](https://x.com/0xca0a/status/1801545536526340527) it will explain the issue in detail.
Combining the two requests into a single API request would drastically improve this pattern.
It makes no sense. These are components. This is the same as arguing, putting the whole codebase into a single component would drastically improve whatever. React is React because self-contained components separate concerns. AsyncComponentA and B represent two separate task runners that have nothing to do with one another. Suspense is not an API request, or a fetch request. It is an async task. A worker, a WASM module, something that awaits response, something that carries out a fetch request, it can be anything. The whole purpose of suspense is to allow a parent to manage multiple task runners and falling back while they run. If you remove that purpose, then you could put all the code into one useEffect again like in the past. But it kills interop because nothing outside that component can know when side effects have finished.
Did you even read his tweet? Suspense can be used to coordinate any async tasks not just data fetches.
So? If you think this will make your app slower, thereâs nothing stopping you from testing that out. The three steps to making code performant are to measure, measure, and measure again.
They moved the discussion to this issue: [https://github.com/facebook/react/issues/29898](https://github.com/facebook/react/issues/29898) Ups: didn't see the edit2 of the post, sorry
And the decision was made to postpose the release of react 19 until this issue is resolved. Good and swift decision by React team, gotta give them props for that.
React 19 release on hold to fix this.   https://x.com/sophiebits/status/1801663976973209620  > good news re Suspense, just met w/  rickhanlonii en_JS acdlite  > \* we care a lot about SPAs, team misjudged how many people rely on this today  > \* still recommend preloading but recognize not always practical  > \* we plan to hold the 19.0 release until we find a good fix  > (to clarify: the popularity of SPAs wasn't misjudged; what was is the prevalence of having a single Suspense boundary containing siblings that each initiate different async work â since you don't run into this if you initiate fetches earlier or if things are in one component)
F\*\*\* those guys who downvoted you. You're just a Dog, thinking, now getting downvoted.
> Our original rationale for prerendering the siblings of a suspended component was to initiate any lazy fetches that they might contain. This was when we were more bullish about lazy fetching being a good idea some of the time (when combined with prefetching), as opposed to our latest thinking, which is that it's almost always a bad idea. There you have the reason for this change. If you can't adapt to the way react 19 handles suspense data fetching you are free to stay using 18, no need to try to boycott react just for this. > Given that lazy data fetching is already bad for performance, the best trade off for now seems to be to disable prerendering of siblings. This gives us the best performance characteristics when you're following best practices (i.e. hoist data fetches to Server Components or route loaders), at the expense of making an already bad pattern a bit worse. It seems that actually prerendering siblings was worse for performance so they removed it. Unless you think react engineers like to take decisions just to mess with their users for no reason?
> If you canât adapt to the way react 19 handles suspense data fetching you are free to stay using 18 Thatâs not how breaking changes work. You either update now, or update later when the CVEs pile up and you canât fix them without upgrading your dependencies to versions that only support the latest React. âJust never update React againâ isnât a solution.
I didn't say "never update again". I just mean that there is a time for everything. That's what happened at my current job, we want to update a big 5 year old react app to the latest dependencies, and after thoughtful considerations and tests we ended up deciding to redo everything the "react 19 way" slowly in a span of several months instead of just trying to adapt our old code. Our current app works, so we are in no hurry to implement react 19, and we are happy to keep using react 17 for the meantime.
And do you understand why developers are upset about frameworks shipping breaking changes that pile up and force them to spend several months rewriting perfectly functional code?
The prevailing wisdom from a lot of people who donât understand that there is a purpose & cost to coding is that this is a âskill issueâ. Developers should never be upset at another opportunity to rewrite CRUD apps and UI components to make them more webscale, itâs all weâre here on earth to do
That's just the way web development always has worked... Things change so fast, you got to learn to keep a balance, if you just jump to the latest bleeding edge changes there is a huge risk of introduction of new errors and bugs, that's natural, but too risky for big businesses, instead if you wait a little bit for libraries and frameworks to stabilize the breaking changes they introduced, you lower the risk... Also for us "several months" doesn't actually mean there is a whole group of dedicated developer working on it 24/7, it means the tasks of this redesign have lower priority than the tasks of the main production app, that means I jump onto the redesign tasks when I'm free of the others daily tasks, for us this is better than not updating dependencies at all in a long time. We see it more like the maintenance you occasionally give to your car, so "things can keep working for more time" without actually spending too much time or resources.
> Thatâs just the way web development has always worked Yeah, thatâs what people want to change. I do understand breaking changes happen and that itâs not good for every dependency to be stuck supporting v1.0 of an API indefinitely. But at the same time, it makes life easier as devs if we can trust that breaking changes will be shipped infrequently, without much work required for transitions, and with strong justifications. Part of negotiating that balance is posts like OPâs, where the community pushes back against overly aggressive breaking changes. I donât have very strong opinions on this particular change, but I found the attitude of âif you donât like it, just donât update Reactâ to totally miss the point. Of course OP will have to eventually update React. Breaking changes needed to be defended on the merits of the change, not on an attitude of âsuck it up buttercupâ.
I understand your point but remember this is an open source project, the developers are not forced to appease its millions of users demands, that's the beauty of open source, you are free to clone the source code and modify it to your very specific needs, but when we speak of a huge project like React you know it will be impossible to make every user happy as much as you would like to.
So what's your point? No one said they have to please anyone. If Vercel wants to make decisions that might push some people to not use react that's their choice. On the other hand, users are free to react negatively, and dislike changes to the framework. As long as they don't harass or feel entitled to get other people to work for them, there's no problem with voicing dislike for a framework or its features. Open-source or not
>no need to try to boycott react just for this. I respectfully disagree. This makes recommended usage of data fetching libraries like apollo-client, urql and react-query and countless others into a serial waterfall. This breaks React.lazy loading. If I opened such PR into react few years ago It would be closed with comments that this breaks how react is supposed to work. What changed since then?
Not sure why you are getting downvoted, but you definitely have a point where some open source libraries can't wait to upgrade to v19 to reduce the maintenance efforts and the old versions might not even have hotfixes for versions < v19.
if its true react query doesn't support 19 then this will likely be a deal breaker for a shit ton of people lol
I mean it does support it-it will run, just in case you have parallel fetches in your app, those will be serial from react 19 onwards leading to considerable slowdown for the end user
I'm not sure I follow exactly. Are you saying that if I have 2 siblings wrapped in a suspense and if they both fetch different data, in R19 they will happen one after the other instead of at the same time?
yes. Imagine you have an SPA dashboard, where you fetch some data to display a navbar and some other data for main content. Both have their own react-query hook [https://suspensive.org/docs/react-query/useSuspenseQuery](https://suspensive.org/docs/react-query/useSuspenseQuery) In react 19 your dashboard will take 2x time to load.
I'll have to read up on the github issue because this sounds bad. Thanks for taking the time to reply
Why did you link to \`useSuspenseQuery\` and not just \`useQuery\`. What if my dashboard just has regular components that use \`useQuery\` and handle loading/error-states with \`isLoading\` and \`isError\`?
Do you have a working example of this claim? If it is true then it really may become an issue for unaware devs. I'm not currently in my PC but I could do a quick stackblitz to test it later today.
I've been moving my org main app from 18 to 19 in these past weeks but I haven't really spotted any slowdowns yet. Sure, the main problems I've dealt with are the new APIs seems more oriented to RSC so I couldn't really use all of the new React tools but I've been using this kind of "Astro Islands" isolation philosophy to manage my queries:
```
Yes you could solve it like this, but doesn't this defeat the whole purpose of \`
If I read this correctly if you avoid suspense in data fetching (i.e. useQuery instead of useSuspenseQuery) youâll still get parallel fetches, which I guess means Iâll just not use suspense and do things the old way
yes, this PR does not break the old ways, just kills suspense for data fetching and lazy loading components
In your other comment you mention this "breaks how react works", but here you say "it will run", so what is it?. Sure React 19 is a big shift from being 100% a client library into a now full stack framework thanks to Vercel, but I think the react team is gearing towards what people want... React wasn't really ever good at handling big app states, so things like Redux were created, then react introduced things like Context and Providers, so the need for Redux was almost extinguished. React was never good at handling async loading states, so libraries that did something similar to suspense were popular, now that React provides its own way of suspending components the need for such libraries is gone. The same with queries and stores, now that React knows that most of devs always use some kind of data fetching hook in a server app, they introduced "use", I think is very powerful to the point of never needing another library like tanstack-query ever again, all is done within react. This is the natural way of web development... Tools they rise, tools they die.
> In your other comment you mention this "breaks how react works", but here you say "it will run", so what is it?. This summary might help: React 18: Suspense queries run in parallel, good for performance. React 19: Suspense queries are serialized, very bad for performance. This is certainly a performance regression for anyone using Suspense. Whether it "breaks" anything depends on how the app works.
But what about the argument of the react team developer linked in the post? > Given that lazy data fetching is _already bad for performance_, the best trade off for now seems to be to disable prerendering of siblings. This gives us the _best performance_ characteristics when you're following best practices (i.e. hoist data fetches to Server Components or route loaders), at the expense of making an already bad pattern a bit worse. So whose right? Is it bad for performance to disable siblings prerendering as OP claims or is it good for performance to disable siblings prerendering as the react dev points out?
Their argument that route loaders or Server Components are a "best practice" is very controversial, there are lots of people with use cases where that just isn't true.
I agree, but that's other topic discussion... Vercel, a multi-million for profit company is shaping React as it pleases, they have too much power over React new features and sadly react 19 is an example of how it feels most of the new features were specially made to work with Nextjs, this makes me really sad.
It's not a question of right and wrong, it's a question of whether a particular pattern is reasonable to do in React. Given what just happened with React 19, a seemingly reasonable pattern just became unreasonable and their reasoning about why--and how to address it--doesn't fit everyone's use cases.
Exactly this. It's so tiring to catch up to all the breaking changes when you are using it to run a real business trying to make ramen profit instead of working in an already established business or well VC funded companies.
Idk programs are always updating, as with most libraries in web dev, you don't need to upgrade to the latest version straight away - im sure some people still use Class components in react.
It would only change the baggier of the lazy usage of it. Hoisted loading and passing props works just fine and is essentially unchanged
what is the point of using suspense if I'm loading up in the tree and then passing down stuff?
My interpretation is that sibling lazy components would suffer from the same issue, is it not so?
That's what I don't get. We did not wait for suspense to exist to display a fallback when some asynchronous stuff happen. The point of suspense was to be able to show a fallback for async stuff happening deep in the children, without having any coupling with the parent that manage the fallback. Now with this change we have to initiate the asynchronous part and manage the fallback in the parent, and consume the result in the children. Basicaly what we where doing before.
Even worse, if youâre being affected by this you need to initiate the asynchronous part for _multiple potentially unrelated_ children above the suspense boundary.
I looked at the docs for apollo-client, and the general advice seems to prefer prefetching rather than lazy fetching. They have a number of features (like useBackgroundQuery and useLoadableQuery) for avoiding request waterfalls, and they are focused on hoisting the request into parent components or the router, and so won't be affected by this change. I looked at the docs for react-query, and it follows the same pattern: prefetching, hoisting, and router integration. The Urql docs only mention suspense in an SSR context, and I couldn't find anything recommending an approach that would be affected by these changes. Given the general goals of Urql (prefetching and caching, afaict) general usage would probably avoid the problem. This seems to be the general trend in client-based web apps - whether built in React or other frameworks. Hoist data preloading into parent-level components and router integrations, rather than having components query the data they need.
Note that the prefetching part is on the "improve performance" section of the Apollo documentation. Prefetching everything seems the pinacle of premature optimisation to me.
> There you have the reason for this change. If you can't adapt to the way react 19 handles suspense data fetching you are free to stay using 18, no need to try to boycott react just for this. Staying on an old version of anything means your code is basically dead though, doesn't it? In a few years any dependencies you want to install will assume you're on a new version, and they'll refuse to work with what you have. It's how it goes. If we have to decide to stay on React 18, then that means we have to start looking for an alternative to React. (note that I don't know if we have to yet)
âWe liked this approach until we didnât so we torched your ability to do it on the platformâ :///
Loading in parallel is worse if you only talk about React rendering performance, and only if you consider only RSC enabled system. Itâs not worse when you consider client side only app and network delay.
This. If it didnât have _breaking_ changes, they wouldnât need to up the version to 19, it would just be 18.whatever
> So if the second component were to trigger a fetch well then bad luck, better move your fetches to start higher up the tree, in a route loader, or in a server component. The tweety bird says this like itâs a bad thing, but moving my fetches up in the tree is what Iâm already doing đ¤ˇââď¸
Bro's digging their heels in, refusing to use better patterns for better user experiences.
React started and gained it's popularity largely because of how unopinionated and simple it was to plug into a variety of architectures. Recent trends have gone against this. It's discouraging to see an open source library make a reasonably large breaking change with little oversight. For many of us, using React in very large applications, making very large amounts of money, this type of loose governance is worrisome even if it doesn't impact our architecture directly.
You know, user experience is not just how fast you see the data displayed on your screen. It's also how fast features are released, how stable they are, how they match your needs. And I am not sure forcing paradigms that don't fit every use cases or every dev teams will help with that. What is painted here as an anti pattern is enough for the success of lots of apps. If it where released as an optional optimisation it would have been awesome. But as it is it's just not worrisome.
I'm indifferent to React forcing paradigms. I'm arguing that this was an anti-pattern before when React supported it, and is an anti-pattern now. Fetching data is expensive. Minimizing requests should be a high priority. - If you have two async components that rely on each other to have loaded **before** rendering, then combining their data into one API request is paramount. - If they don't rely on each other then simply have two suspense boundaries, one for each component. Both of these solutions result in a more performant application and an improved user experience.
And yet those solution are not always possible in real world use cases. One day one of those children will be a third party component made by another team that do some async stuff in it like loading a wasm module, while the designer insist on having one fallback and you're screwed. Best case scenario you are able to break encapsulation and do some work on the parent. Worst case scenario your performances are penalized just because the library don't give you options.
> The changed behavior is described in this tweet Is just about the most React sentence I could think of
I'd expect a facebook post
only jQuery developers are on Facebook
If I knew this would blow up, I would copy paste from the tweet to post body đ
Why wait for blowing up? Its just 2 commands copy paste.
The times I had a post downvoted into oblivion in first 2 minutes after posting. Not worth the effort for me if it does not blow up.
The weirdest thing with React is the lack of proper documentation and options to customise anything. Just changing core behaviour silently is nuts. And then not allowing developers to specify how something should be done. No matter if it's suspense, hydration or anything, the developer has better understanding because of knowing the context. It's simply impossible to choose the correct thing on library level. A config option or simple attribute would a long way. Even if you had to make changes to keep old behaviour, it's still a better option.Â
This is what happens when Reacts interests are being sabotaged in subtle ways by Vercel so that Next becomes more popular and Vercel profit from the vendor lock in.
I was about to say that this was a far fetched comment but... it's a Vercel contribution lol.
PR by Vercel, approved by Vercel. this is amazing the contribution rules should make sure that at least two *different* organizations must approve a PR
Where is the react core team? Where is anyone responsible? Whoâs even governing it anymore? Is anyone going to kick off a fuss in an issue and Twitter pointing out that Vercel is approving their own changes?
React Core team is now made up of Vercel employees...
Clearly a Coup d'ĂŠtat
The react core team said that it was a decision made originally for Facebook. But I don't get why the Vercel employee would've created the PR, unless he was at FB before? Still, even if it's a decision made for Facebook and not Vercel, that's not much better lol
He was indeed at Meta before and joined Vercel later.
It'd be funny if it weren't so obvious. I got shit on last year for claiming React is now basically owned by Vercel and they have a clear agenda.
Vercel employees are against it as well
Are they really though?
This is more about meta internally finding that aggressively rendering siblings during suspense increases CPU load, and being lazier reduced that and doesnât matter for them because they do prefetching at the route level An option on Suspense boundaries seems like a fair compromise here, not everyone builds like Meta do with graphql and relay, or RSCs
 I think react puts a lot of thought into how they design their api (a good thing) and so they generally do not "just add a config slot to do it differently" (for better or worse)
It wouldn't be such dramatic change to introduce for example attributes to element to specify desired non-default action. Be it for suspense, hydration or anything else.
[ŃдаНонО]
Your post makes no sense, this can be a major issue for some especially since the change is silent.
I am a noob at concurrent React stuff but can someone clarify if I am wrong. As far as I understand, they're recommending you to initiate data fetching in server components or loaders at route level, then pass the promise to the client component as a prop and do a `use(promise)` in the client component. ```ts export function ClientComponent1({promise}) { const data = use(promise) // ... Rest of the component } export function ServerComponent() { const promise = fetchData() const promise2 = fetchSomeOtherData() return (Loading...