React Server Components: A New Way to Build Fast and Interactive Web Apps

React Server Components are a new feature that lets you render React components on the server and stream them to the client. This enables you to build rich user interfaces with minimal client-side code, while still preserving interactivity and performance.

In this talk, you will learn how React Server Components work, how to use them in your web apps, and what benefits they offer over traditional approaches. You will also see some real-world examples of React Server Components in action and get some tips and best practices for adopting them in your projects.

Transcript

1. React Server Components: A New Way to Build Fast and Interactive Web Apps Aurora Scharff @aurorascharff
2. React Server Components: Why should you care?
3. Introduction > Aurora Walberg Scharff > Consultant at Inmeta > Norway, Oslo > Full-stack, web-focused: active RSC developer
4. Talking points > Rendering strategies > React Server Components > Next.js App Router > RSC in Next.js “the right way” > Demo > Real world experience > The future of RSC
5. Rendering strategies
6. Static website rendering > Pages are pre-assembled and uploaded to a static host > Simple and efficient > Struggles with dynamic data and impractical to maintain
7. Multi-page applications (MPAs) > HTML and data are dynamically merged on the server > Serves the merged result on page load > Page reloads per request
8. pros √ Optimized for SEO √ Unlimited scalability √ More website insights Multi-page applications (MPAs)
9. pros √ Optimized for SEO √ Unlimited scalability √ More website insights cons × Slower overall performance × Limited interactivity × Hard to maintain Multi-page applications (MPAs)
10. Single-page applications (SPAs, CSR)
11. Single-page applications, pros ✓ Instantaneous, app-like feel ✓ Easy to debug ✓ Caching capabilities
12. Single-page applications, cons × Slow initial load × SEO suffers × Needs JavaScript × Less secure
13. SPA vs. MPA lifecycle
14. Server-side rendering (SSR) > Pre-render the initial HTML on the server > Fully-formed HTML when opening the page > JavaScript is fetched alongside it
15. Static site generation (SSG) > Pages are pre-assembled and uploaded to a static host > Requires site redeployment whenever data changes > JavaScript is fetched alongside it
16. Server-side rendering (SSR) > Included feature in JavaScript “meta-frameworks” > Build time (SSG) and/or request time (SSR) > Pages generated in the build can be cached
17. Hydration
18. Hydration Hydration is like watering the “dry” HTML with the “water” of interactivity and event handlers. - React core team member Dan Abramov https://github.com/reactwg/react-18/discussions/37
19. Server-side rendering
20. The problem
21. The problem 1. You have to fetch everything before you can show anything 2. You have to load everything before you can hydrate anything 3. You have to hydrate everything before you can interact with anything
22. Strategies to improve it > Partial hydration: only attach JS to certain components > Progressive hydration: lazy load JS to certain components > Selective hydration: priority load JS to certain components based on user interactivity
23. Streaming > Split a request into chunks > Send each chunk as a stream to the client > Render each chunk as it is streamed in
24. React Server Components
25. What are they?
26. “The server”
30. Interactive/Client Components
32. https://nextjs.org/docs/ap p/building-your- application/rendering/com position-patterns
33. How do they work?
34. The RSC Payload
40. Benefits of using RSC
41. Benefits √ Data fetching + access to backend resources
42. Benefits √ Data fetching + access to backend resources √ Security
43. Benefits √ Data fetching + access to backend resources √ Security √ Caching
44. Benefits √ Data fetching + access to backend resources √ Security √ Caching √ Bundle size + performance
45. Benefits √ Data fetching + access to backend resources √ Security √ Caching √ Bundle size + performance √ Streaming + suspense integration
46. Benefits √ Data fetching + access to backend resources √ Security √ Caching √ Bundle size + performance √ Streaming + suspense integration √ Developer experience
47. Drawbacks of using RSC
48. Drawbacks × Require a framework
49. Drawbacks × Require a framework × Increased complexity
50. Drawbacks × Require a framework × Increased complexity × Learning curve
51. Drawbacks × Require a framework × Increased complexity × Learning curve × Early adoption
52. Next.js 13/14 and App Router
54. |
59. RSC in Next.js “the right way”
67. Data management
70. Server Actions
71. Server Actions > Mark a function/file with “use server” > Next.js creates a “hidden” API endpoint for you > Use the function in any component > Provides a type-safe RPC-experience
78. Demo
81. Real world experience
82. Requirements > Interactive dashboards > Complex forms and tables > Articles through a CMS, static data > Need for SEO > Mobile friendly and accessible > Multiple language support > Customer’s own UI library
83. cons × Wrappers for custom library × Trial and error i18n × Limited testing resources Experience
84. pros √ Performant app that fulfills requirements √ Maintainable app code √ Enjoyable DX Experience cons × Wrappers for custom library × Trial and error i18n × Limited testing resources
85. The future of RSC
87. The future of RSC
88. Resources My GitHub repo: aurorascharff/next14-remix-jokes-rebuild
89. Resources > React docs > Vercel Next.js App Router docs > Vercel template apps and examples > Vercel “Learn Next.js” free course
90. youtube.com/@codewithantonio youtube.com/@bytegrad
91. Thank you Twitter: @aurorascharff GitHub: @aurorascharff Blog: aurorascharff.no
92. Questions?