Great video!; I love how it's focused on fundamental principles & APIs & gradually builds up, all while keeping the code & examples simple I think a lot of us are tired of the super high level framework videos, so seeing "under the hood" is refreshing!
Awesome and thank you! I've been toying around with making some videos that show off how a framework wires together some of the RSC APIs. I think that'll make for a nice under the hood video.
Great video Ryan. I love how you always take the time to explain the fundamentals before diving into the actual topic. One thing that I wish was talked about more would be how using Suspense and loading.tsx impacts SEO because now you're relying on the crawler executing Javascript to get the full contents of the page, even though it's streamed as one request from the server. Keep up the great work! You and Sam are killing it!
Thank you! And great point on SEO/crawlers! My understanding is that Google is able to read the DOM, so it can "see" all the client side JavaScript that runs. However, other bots still need HTML strings. Beyond that I don't know how to best serve up React's HTML for search crawlers. Are you running any sort of content / indexable site with RSC? Any advice?
@@RyanToronto My understanding is that the position in the DOM of your content is relevant to crawlers. For example, if your content is right after the H1 of your article Google will understand that it is relevant to the title. If it’s at the footer of your page there is a good chance Google will discard it as irrelevant, or even worse, as keyword stuffing. I’m not running a SEO optimized page right now running on the app router. We were considering migrating our website to the app router but these questions had to be answered as SEO is very important for my business. We decided to hold off migration at the moment, but even if we were to do it, I would avoid using any suspense or loading anywhere, which is a shame because they do provide a better UX for the user. I wish there was a way to disable out of order rendering conditionally on the server so you could block rendering for crawlers and users with no JS but use it for other users.
@@spiritz0r317 Ya I can totally understand wanting to hold off on anything that "changes" your HTML if your business relies on search traffic. Don't poke the Google bear :) Conditionally controlling streaming sounds like an awesome idea. I'm not sure if that's possible in Next, but it could be worth exploring. I think I might try to make a video on this! Btw, UA-cam sometimes makes it impossible for me to see these comments. If you want to reach out on Twitter (twitter.com/ryantotweets) feel free to!
I really appreciate this content about the features that come with app router, still can't understand when and where to use server actions vs route handlers, hopefully you soon find time to share the best practices. Again, thank you for this content!
Amazing! Just a question out of curiosity, will suspense affect cumulative layout shift? I suppose the loading skeleton of each component should be as close (meaning position and width/height) to the actual data as possible? Again I am not sure, just thinking out loud.
Great question! And yes you are right, CLS is something to watch out for when using Suspense. If you want to avoid layout shift then you need to make sure your Suspense fallbacks match your content... which can be tricky sometimes.
It's a single http connection. In fact, it's the same connection that renders the first html you see... so I guess its a bit like long polling. As soon as all suspense boundaries are resolved the connection closes.
Am I right in thinking that suspense is only available to async components, I.e just server components at the moment? For a client component, any pending ui would still need to be ‘baked’ into that client component itself self in some form, such as is loading from swr?
Great question! Suspense will work with client (non-async) components as well. If a client component throws a promise then it can be caught and handled by a parent Suspense boundary. However, if you're using a data fetching library like SWR then I think you're better off following what they recommend and sticking with isLoading.
Yup great question! I think this is a topic that deserves another video. For Google bot it hopefully shouldn't hurt SEO, but for other crawlers you might not want to send a streaming response.
Yup, what @frontendonly said! You get all the data for the page in a single HTTP request, but that request isn't blocked and it can stream in updates as data becomes available. With client side data fetching you generally have to have the browser make separate HTTP requests to fetch JSON payloads from your backend.
I love your approach to teaching where you progressively show more complexity with each example. I wish all teachers were this thoughtful.
Wow, thank you!
Great video!; I love how it's focused on fundamental principles & APIs & gradually builds up, all while keeping the code & examples simple
I think a lot of us are tired of the super high level framework videos, so seeing "under the hood" is refreshing!
Awesome and thank you! I've been toying around with making some videos that show off how a framework wires together some of the RSC APIs. I think that'll make for a nice under the hood video.
I can easily understand your explanation even though I am not a native English speaker. I really appreciate for your video.
That's so great to hear! Thank you!
Your content is soo clean, high quality. I enjoy so much especially when I watch your content. Alsa Sams, hope we’ll see more from you
Thank you so much!
That was so clean!! Beautiful delivery and nice example 🎉
Thank you!
Killing it lately with all of the recent vids Ryan! You've become must-watch for me. Amazing explanations and examples.
Wow that's great to hear! Thank you!
💯Wow the explanation was so crisp and clear to the point! You've got a new sub!
Thanks and welcome!
Thanks Ryan for explaining how this works behind scenes! 🙏
Thanks Edgaras!
Fantastic as always, Ryan. Really appreciate the content you are putting out. Very few I learn from to the level of depth that you put out
Thanks Jordan :)
I laughed in delight at the last example. Hahaha. This was great! Thanks for sharing!
Ha, me too! I had so much fun putting that example together.
@@RyanToronto watching your videos makes me wanna get in on the React 19 experimental stuff.
Awesone Ryan, Now we can wire all the suspense & streaming stuff
Great video Ryan. I love how you always take the time to explain the fundamentals before diving into the actual topic.
One thing that I wish was talked about more would be how using Suspense and loading.tsx impacts SEO because now you're relying on the crawler executing Javascript to get the full contents of the page, even though it's streamed as one request from the server.
Keep up the great work! You and Sam are killing it!
Thank you! And great point on SEO/crawlers! My understanding is that Google is able to read the DOM, so it can "see" all the client side JavaScript that runs. However, other bots still need HTML strings.
Beyond that I don't know how to best serve up React's HTML for search crawlers. Are you running any sort of content / indexable site with RSC? Any advice?
@@RyanToronto My understanding is that the position in the DOM of your content is relevant to crawlers. For example, if your content is right after the H1 of your article Google will understand that it is relevant to the title. If it’s at the footer of your page there is a good chance Google will discard it as irrelevant, or even worse, as keyword stuffing.
I’m not running a SEO optimized page right now running on the app router. We were considering migrating our website to the app router but these questions had to be answered as SEO is very important for my business.
We decided to hold off migration at the moment, but even if we were to do it, I would avoid using any suspense or loading anywhere, which is a shame because they do provide a better UX for the user.
I wish there was a way to disable out of order rendering conditionally on the server so you could block rendering for crawlers and users with no JS but use it for other users.
@@spiritz0r317 Ya I can totally understand wanting to hold off on anything that "changes" your HTML if your business relies on search traffic. Don't poke the Google bear :)
Conditionally controlling streaming sounds like an awesome idea. I'm not sure if that's possible in Next, but it could be worth exploring. I think I might try to make a video on this!
Btw, UA-cam sometimes makes it impossible for me to see these comments. If you want to reach out on Twitter (twitter.com/ryantotweets) feel free to!
Hey Toronto, I really appreciate for your efforts. They're absolutely helpful to get better understanding how everything works.
Literally Best Explanation 🙌
Thank you!
Really enjoyed the video and content, keep the great work Ryan!
Glad to hear it! Thank you!
Absolutely underrated
Thank you!
I really appreciate this content about the features that come with app router, still can't understand when and where to use server actions vs route handlers, hopefully you soon find time to share the best practices. Again, thank you for this content!
Thank you! It's a tricky question to answer, but I would say if you're using Next.js App Router then you should mostly be using server actions.
Thanks a lot, this is so cool, I recently watched Lee's video on streaming data, and this made me understand it really well, keep the videos comming
That's awesome! Glad it helped!
Thanks for sharing. Super helpful for a deeper understanding. I especiialy enjoyed the part where you started with the fundamentals of ReadableStream
That's awesome to hear!
wow nice explanation it's the best I watched on that topic, nice content
Much appreciated! Thank you!
Great explanation
9:12 So beautiful
Haha, yup! I had so much fun building that streaming grid.
Great content! loved it, great way of teaching!
Thank you so much!
Glad you liked it!
You voice. Masallah ❤
Amazing! Just a question out of curiosity, will suspense affect cumulative layout shift? I suppose the loading skeleton of each component should be as close (meaning position and width/height) to the actual data as possible? Again I am not sure, just thinking out loud.
Great question! And yes you are right, CLS is something to watch out for when using Suspense. If you want to avoid layout shift then you need to make sure your Suspense fallbacks match your content... which can be tricky sometimes.
@@RyanToronto Thank you so much man, love your content!
Very interesting. It is done through long lived http connection or websockets behind the scenes?
It's a single http connection. In fact, it's the same connection that renders the first html you see... so I guess its a bit like long polling. As soon as all suspense boundaries are resolved the connection closes.
Am I right in thinking that suspense is only available to async components, I.e just server components at the moment? For a client component, any pending ui would still need to be ‘baked’ into that client component itself self in some form, such as is loading from swr?
Great question! Suspense will work with client (non-async) components as well. If a client component throws a promise then it can be caught and handled by a parent Suspense boundary.
However, if you're using a data fetching library like SWR then I think you're better off following what they recommend and sticking with isLoading.
Why does this not work on a barebone react-app created using npm create vite@latest? Is there something I am missing?
Oops, my apologies! This is a new feature in React that's only available when using React Server Components.
@@RyanToronto Thank you. I was scratching my head with this :D
FYI you don't even need javascript, you can use webcomponents/slots to achieve the same thing. No client side JS needed.
Nice. The slot element looks very cool
Doesn't it affect SEO since the original page gets edited by Javascript ?
Ow you already talked about it with someone else on comments!. Thanks
Yup great question! I think this is a topic that deserves another video. For Google bot it hopefully shouldn't hurt SEO, but for other crawlers you might not want to send a streaming response.
what's the difference betwee that and the old way of using react query and showinga loading component while it's fetching ? is SSR that is
Yes,it provides SSR rendered page but not blocking the UI and show the loader where react query do it in client side.
Yup, what @frontendonly said! You get all the data for the page in a single HTTP request, but that request isn't blocked and it can stream in updates as data becomes available.
With client side data fetching you generally have to have the browser make separate HTTP requests to fetch JSON payloads from your backend.
Very curious how this works under the hood