Yeah, don't throw away the new gummies. :)

I do like Livewire, but I'll probably do htmx first because it's hot now (gotta love the YT algorithm) and it has that server-driven mechanic. :)

That is an awesome tip! Thanks!

`use` is cracking the promise and most likely throwing the promise on render and then React is getting that promise and subscribing to it itself so that when it resolves it will re-render the component. And all that is done on the server side. If you look at the RSC payload you can see a "promise type" marker with the data from the promise, so it's resolved on the server. Then on the client during hydation they use do a Promise.resolve(payload) and pass that in.

@@jherr Hi Jack, Thank you for explaining how the promise works both is RSC and client component! If everything rendered on the server side, would it be the same as SSR in page route and the page load should be fast? I thought I would not even see the loading stage when the html is ready to be served. However when I tried your example with image fetch instead, I would see a loading state before image loaded, rather than seeing the image right away (comparing to page route approach). Does it mean it is slow even when the promise gets resolved on the server?

@@afion113 So if you are going to get the image data on the server, and that image API is slow, then ask yourself, would you rather the customer have an interactive page with a spinner, or a page that is slow to respond? Because the App Router gives you the ability to have a fully interactive page where parts of it stream and become interactive. Where the pages router simply blocks on getServerSideProps which means that the page would simply be slow to repond.

Server compents can include client components. And client components can include server components and children or rendered props.

Copy and paste from a previously implemented correct version. I really don't see the need to make you watch me poorly type stuff. :)

@@jherr oh I see. Anyway nice video. I learn a lot of new stuff from you. Thanks man.

You can send a request directly to team@pronextjs.dev to get registered. The site is still new and there were some issues with the certificates.

You probably have competing React versions. So the components are on one version of React and the NextJS server is another. Is this 13? If so you want 18 across the board and probably more specific than that. FWIW, the best solve here is to bring everything into the monorepo.

@@jherr yes very good point and I checked it all projects are of the same version of react and common dependencies. You can easily test it by recreating two new projects from scratch (we tested it too). One strange thing is that when we where using nextjs 12 this issue was not present after upgrading it to 13 it appeared. I might be wrong but I think it is related to new transpile option in nextjs 13. Before we were using the withTM module.

I found using server actions for data fetching to have some important limitations. For me the deal breaker was having no built-in way to abort requests, like you would using an AbortController on normal fetch calls. This is a big issue with typeahead server validation or autocomplete requests, where promises may be resolved out of order

I need to investigate a little further how RQ is doing this.

I don't think streaming has anything to do with client component. It's fetching and rendering UI's after reaching the browser!

Does this mean the loading indicator for RQ is replaced with foods by client side bundle. It is not same rendering pattern as React streaming using Suspense ?@@r0mankon

@@r0mankon have a look at what’s coming out of the server. It’s holding the connection open then sending more HTML and JS as the streams are resolved. That’s not initiated by the client.

@@jherr Interesting how that might work! Let's wait for your findings.

The actual blocking in the "client" component happens on the server side, the rendered component is sent to the client when the server render of the client component is completed. "Client" components are rendered on both the client and the server.

@@jherr In that case, is there a way to render a loading state in place of the client component while the server component is performing the data fetching? Should I use a loading.tsx? Thank you so much!

@@DesolationPhoenix Yeah, if you use the `use` hook then wrap it in a Suspense as shown in the video. If you use the React-Query `useQuery` hook then look at the `isFetching` boolean and render a loading state if it's true (again, as shown in the video.)

@@jherrthank you so much!!!

That question was in my head the whole time while watching the video 😅 Honestly, the way that is handled with rsc is next level. That's so much more convenient. Btw. are the any good reasons for using react query etc over use + suspense?

Anything you pass to a client component as a property is serialized and serialized independently of any other component. That's why the multiple copies. The context is a single copy because we are only sending the prop to the provider client component and then it's sharing it around both on the server and on the client.

thanks for the answer 🙌 I believe some kind of lint rule is needed to avoid this. It is a mistake that a developer can easily make and it can realy hurt the perf. was it like this before app router?

No, it will simply re-request the original promise which will return the original data.

It's in the experimental build of React that the App Router uses.

@@jherr but its not production ready and NextJS don't recommend it in client. What is the alternative ?

try to use router.refresh on the client component or revalidatePath on api route

If you a requesting off the client then yeah, they would all pick up the same cache. But that's not going to SSR, so if you want SSR then you have to request the data in an RSC.

I was thinking the same thing, did you happen to find it?

@@SharunKumar console ninja

My recommendation is to use middleware to inject an API header key into the request header with the prefix for the API. It might be something like `X-API-Base-URL` or something like that, which you can set however you want in the middleware and then the components pick it up with `headers`.

Night Wolf [black]

@@jherr Thank you so much!

A big benefit is that you are making the request off the server. So you get better security and performance. In addition if you need SEO then there is a big benefit to rendering on the server because the HTML is generated on the server and is easier for the bots to handle.

@@jherr I'm talking about this specific use case in the video (promises for props). Performance would be the same since you wait for the promise to finish. I'm not sure about the security part, what security issues does this prevent that a separate backend wouldn't? The other flow (with tanstack query for example) would be to fetch from the client from a backend server, then that server can fetch the same way it's being done in the video, only less convenient I guess. And I might be wrong on this, but server components don't generate HTML on the server (that's being done by renderToString) but instead send the serialized react tree to the client (so not *directly* html)

@@Andreiu2011 So about whether the API is being called from the server or the client. There are several reasons why it's ideal to call from the server. First, NextJS servers are often deployed in the same VPC as the microservices they call, so it's a much faster connection. Second, the microservices don't need to be deployed to the open Internet because they are being called only by the NextJS servers within the VPC. And third, third party APIs often have access keys which shouldn't be sent to the client for security reasons. So making the requests from the server avoids the key leakage. There are more advantages, but those are some of the primary ones. And "server components don't generate HTML on the server" is pretty easy to test that yourself, just create a NextJS app, start it up and look at the page source in the browser. You will see all the rendered HTML (as well as the VDOM). "View Page Source" shows what comes back from the server, it does not show the current tree. For the current tree you can use the inspector. You can also see the HTML rendered from the server in the Network panel of the inspector as the response to the initial route request. Or you can just curl the server as see what comes back.

Night Wolf [black]

@@jherr thanks 👍

I only brought in the external library in the error case for simplicity. An error boundary is a single class component that is ~10 lines of code. But yeah, if you just want a catch-all you can do error.tsx.

Then have a single context that contains multiple promises.

@@jherr instead of using context, could we use Zustand or Jotai, to achieve the same thing?

@@rubendacostaesilva8442 I wouldn't use Zustand or Jotai in their default "global" mode since globals with App Router are a no-no. Instead I would provide Zustand or Jotai atoms via context so that you are guaranteed that the state managers are per-request. Zustand and Jotai totally support this model, it's just not as super-easy as it usually is. For Zustand for example, you first call a hook that gets the Zustand hook from the context, and then you call the Zustand hook just like before.

@@jherr that's sound kind of "gimmickly", but I'm going to give it a try. Thanks for the response, and keep up the great work you're doing!

No. Streaming doesn’t effect SEO.

@@jherr thanks :)

I don't think that's correct. All of the action is happening on the server. So client-side JS or not you would still get the error boundary content (or error.tsx) content coming off the server if there was an error.

@@jherr try to turn off js, you wont get any errors to render. In remix you will. Dan Abramov, explained that there was a missing part for sending errors as an action return. And it’s not implemenred

@@shadowfaxenator You are correct sir. Thanks for the heads up on that one.

It depends on what else you have going on. The await on the server blocks any other components that are also loading.

@@jherr Alright. So essentially you await on the client side using "use" hook instead of the server ! Right ?

@@rajeshdavide That's actually pretty complicated because it's both on the client and the server. "client" components run on BOTH the client and the server. That's number one. So when a "client" component on the server that uses `use` gets a fulfilled promise it renders on the SERVER. The HTML and the data are then both sent to the client where the component instance on the client is hydrated symmetrically and the `use` is run there too.

So if that's the case, can I assume that the fullfilled promise is streamed after the client renders the component ? Do you have a material where I can read more ?

In my mental model use hook was akin to await, if the client component that uses "use" runs on the server will it not wait until promise is resolved ?

Loading and error are great to handle the route level errors. Here I'm demonstrating how to manage errors and suspenses at whatever level of granularity you want within the component tree.

Yeah, I have to take another look at that. There might be a way to get that to work.

This demonstrates using error boundaries and suspenses within the component to all for a finer level of loading and error indication granularity. If you don't need that then feel free to use error and loading.

@@jherr one of the reasons I'm invested in next js is because I don't have to deal with all those states. But I get it 👍

@@josevsebastian2909 you can only use them in pages right , it will wrap up the whole page with the error fallback if something fails , but if u r only using that api response in particular component then I think its best to just wrap that piece of code with error boundary

@@yuvarajyuvi9691 in page router it works like that. Wrapping everything in error boundary and suspense. But one of the main advantages of app router is that, it respects the nested layouts of different routes, only the "page" leaf component is replaced by the boundary, all the "layout" is still rendered. And most often that's the result you want, except when you need granular loading or error handling inside the "page" and even that can be done using parallel routes.

What do you mean get no server rendering of data? I showed every time that the data is server rendered. Have a look at the HTML I showed from the page source. That's coming back from the server.

@@jherr I guess not if you disable js, as the promise has the data, and not the html? I guess I can see the value if the API is slow enough you wouldn't want it on initial render maybe

@@griffadev If you look at the output of the server, regardless of whether the client has disabled JavaScript or not, the HTML coming out of the server has all the rendered HTML including the HTML that comes in late off the suspense because the connection is held open until the suspense completes.

@@jherr that makes sense, still getting used to this react sever component world, thanks for the explanation

@@griffadev No problem. The whole client/server isomorphic thing has always been a little complicate when you look into the details. It was simpler with the Pages Router because the flow between getServerSideProps and then rendering, then sending it to the client, and hydrating and running there, blah blah blah, was pretty straightforward. Now, with RSCs and streaming, things are getting more complicated. They are CONSISTENT, which is cool, but complex.

You don't need to, but this makes it really explicit.

What's cached again? The only cache that is involved here is the fetch cache which is being turned off in the code.

error and loading are route level, using suspense gives you the ability to give skeletons/spinners at a component level. the addition of react-query is the basis of a nice pattern of re-fetch and valuable to folks who already use that library (or SWR) to manage promises. it's just further validation that the promises are indeed promises. as for common use case, there are lots of use cases. i've personally worked with very large data sets on both client and server side. the nice thing about the App Router is that we are no longer sending everything out of getServerSideProps to the client, now with RSCs some data can remain strictly on the server and we can limit the amount of data going to the client.

@@jherr would parallel routes be a better alternative to the suspense and error boundry situation? also what do you think of the long term use of something like react query and swr with next now pushing to have mutations with fetch? i had never faced this data issue so far (mostly cause we still use pages at work haha) but will keep this in mind!

@@MrZiyak99 parallel routes are for rendering separate sections of the page like the header/footer/nav or the cart, or something like that. And the idea is that each parallel route has its own sync/async behavior. I wouldn't create a parallel route for every component on the page. If you are going to do mutations via API route, then RQ or SWR would be fine. If you are going to do them via server action then RQ or SWR would not be necessary and you could use something like `useTransition` to monitor them.

@@jherr i use parallel routes for every independent section on my page with their own error.tsx and loading.tsx files 😭 will keep whatever you've said in mind incase work does decide to move from pages to app great content thanks for the help!

@@MrZiyak99 We are probably talking about the same thing. There is the main content section of the page and then other sections that can be independently rendered/streamed and that's what parallel routes are great for.

I think so

That's another option, but in this case that would mean blocking the RSC making the request because it would have to await the request. That would mean that any other components it contained that had additional requests would be blocked on the request.