Newline Commerce demo app

Performance matters

The Rendering Triforce

Rendering in Newline Commerce (demo)

Introduction to the Course

Static RSC - the new default

Getting data, statically

Update data, with Server Actions

Static Pages with Dynamic data

Static is great, you want static

Page-level "revalidatePath"

Datasource-level "revalidateTag"

Up-To-Date Static Rendering

Client-side data fetching recap

Relaying with SWR

Client-Server Relaying

Mix Static and Dynamic Rendering

Partial Prerendering (PPR)

Congratulations!

Conclusion

The **Blazing Fast Next.js with React Server Components** course equips you with the skills needed to master Next.js Static Rendering, coupled with Server Actions but also client-side and dynamic rendering. From foundational concepts to practical implementation, you'll gain a deep understanding of how to leverage Next.js for optimal performance and dynamic content delivery.

## **Blazing Fast Next.js with React Server Components**

### Build a Content Application with Dynamic Data - Newline Commerce

Welcome to the "Blazing Fast Next.js with React Server Components - Design patterns to accelerate Next.js Apps with Static Rendering and Server Actions" course. Throughout this program, we will guide you through the intricacies of Next.js, focusing on Server Actions and static rendering techniques. In this informative journey, we will collaboratively construct a content application named Newline Commerce.

Join us as we explore the foundations of Next.js, implementing dynamic data and server-side actions to bring Newline Commerce to life. This course is your gateway to mastering the art of server actions and static rendering in the context of real-world web development.

### How The Course Works

- The Blazing Fast Next.js with React Server Components course is a 6-module online program where you will delve into Next.js powerful patterns such as Server Actions, Static Rendering, Client-Server Relaying or Partial Prerendering. Learn to deliver fresh content to your end users with optimal performances and cost efficiency.
- Remote: Take the course from anywhere, allowing you to participate from the comfort of your preferred location.
- Self-paced: Tailor the course to fit your schedule. With a self-paced structure, you have the flexibility to learn at your own pace, ensuring a stress-free educational experience.
- Community: Engage with other students in a collaborative learning environment. Share insights, discuss challenges, and expand your understanding within a supportive community.
- Structured: Experience a cohesive and organized learning journey. The course is structured to guide you through each module in a logical and progressive fashion, ensuring a comprehensive understanding of Next.js Server Actions and Static Rendering.

### The Challenge

Navigating the realm of Next.js can be a daunting endeavor for many aspiring developers. As you embark on your journey to master this powerful framework, you may encounter several challenges:

- **Complexity Overload:** Next.js, with its robust capabilities, can overwhelm newcomers. Understanding the intricate balance between Next.js server-centric features and data update requirements requires a structured approach.
- **Dynamic Content Dilemma:** Implementing dynamic content in web applications often poses a challenge, especially when it comes to delivering fresh data efficiently to end users.
- **Performance Concerns:** Ensuring optimal performance while maintaining cost efficiency is difficult. Achieving this balance with Next.js demands a nuanced understanding of its patterns and practices.
- **Lack of Cohesive Learning Resources:** Piecing together information from various sources can be time-consuming and confusing. A structured learning path is essential for a comprehensive understanding of Next.js.

### The Frustration

Newcomers often find themselves frustrated by the lack of clarity and guidance in mastering Next.js. The complexity of static rendering aside from trivial use cases can be a significant roadblock, leading to confusion and hindered progress.

### How This Course Helps

The "Blazing Fast Next.js with React Server Components" course is designed to address these challenges head-on. Through a carefully crafted curriculum, you will gain a clear understanding of Next.js, overcome common hurdles, and confidently apply static rendering with revalidation in your web development projects.


### Unlock the Potential of Next.js in 2024

In the dynamic landscape of web development, staying ahead is key. Here's why learning Next.js in 2024 is advantageous for you:

1. **Enhanced Performance:**
Next.js continues to evolve, offering enhanced performance features that cater to the growing demand for faster, more efficient web applications.
2. **Industry Relevance:**
As of 2024, Next.js maintains its position as a leading framework, backed by a vibrant community and widespread adoption in the industry. Learning it now ensures you align with current development trends.
3. **Scalability for Modern Applications:**
In an era where scalability is paramount, Next.js provides the tools to build scalable applications that adapt to the demands of modern web development.
4. **SEO Optimization:**
Next.js server-side rendering capabilities contribute to improved SEO performance, a crucial factor for ensuring your web applications are discoverable and accessible.
5. **Developer-Friendly Ecosystem:**
With an ever-expanding ecosystem and a focus on developer experience, learning Next.js in 2024 means immersing yourself in a framework designed to streamline your development workflow.

Equip yourself with the skills to thrive in the current web development landscape. Learning Next.js in 2024 positions you at the forefront of technology, offering a competitive edge in your professional journey.

Design patterns to accelerate Next.js Apps with Static Rendering and Server Actions

Learn how to build blazingly fast websites with Next.js. Static rendering is often underrated: it’s very fast, very cheap, but hard to use in advanced scenarios. This course introduces students to personalization with static rendering by using React Server Components, the latest paradigm shift in React. By the end of this course, you'll have learned advanced Next.js concepts like server actions, static revalidation, client-server relaying, or partial prerendering, and you'll know when and how to apply different server rendering strategies in large, production-grade Next.js applications. This course mixes recent advanced concepts like Server Action and static rendering in a way that students won’t find in the documentation. Not only will this apply to any content application but also it will apply to dashboards or multi-tenant SaaS.

Blazing Fast Next.js with React Server Components

Fetch and cache data from a database inside a React Server Component.

Handle form submissions using Next.js Server Actions.

Perform client-side data fetching in Next.js with SWR.

Why the performance of a content application matters and how it's related to different rendering strategies

How to statically fetch data on a server with React Server Components (RSC)

How to update static pages with fresh content via data revalidation in Server Actions

How to perform relaying with SWR, a React Hooks library for data fetching

How to mix dynamic and static rendering via Partial Prerendering (PPR), an experimental feature introduced in Next.js 14

As the landscape of web development evolves, new techniques and technologies emerge that can significantly improve the performance and user experience of web applications. 

One such technology that has recently been introduced is "React Server Components", aka RSCs. 

These components are themselves made possible thanks to the new architecture brought by Next.js 13, known as the App Router. 

RSCs represent the most tremendous paradigm shift in React since the introduction of hooks.

A React Server Components, in its simplest form, is really like a template written in JSX, a function that takes some data as parameters (the “props”) and returns HTML or more React Components.

// Hello world in Next.js App Router:
// this is a statically rendered React Server Component
export function HelloWorld(props) {
    return <p>Hello world! My name is: {props.name}</p>
}

Before RSCs, we only had one type of React components: Client Components. 

It was already possible to render client components on the server, but they still needed some client-side JavaScript to work.

This process of rendering a Client Component first on the server, and then in the browser, is called hydration. Hydration allows the server-rendered component to become interactive when it lands in the browser.

React Server Components on the other hand, are rendered only on the server and do not require any client-side JavaScript to work. 

 component above has no actual server requirements, so it can be rendered client-side too. The 

 calls such components "shared components", meaning they can be used by other server components or client components. 

This video from Lauren Tan (React Core team)

 gives great explanations. Later on we will meet "pure" RSCs with actual server requirements.

Static, server-only components are the new default

The fact that RSCs don't need any client-side JavaScript makes them more performant than Client Components. And in Next.js, performance is always the default, so all your React components are Server Components unless stated otherwise.

// This directive marks all components for this file
// as Client Components
"use client"
export function HelloWorldAlert(props) {
    // The "onClick" event handler
    // can't be used in a server component
    // That's why we need a client component
    return <button onClick={() => {
      alert("Hello World")
    }}>Click me</button>
}

Client component are needed when you need some JavaScript-based interactivity: using event handlers (

Pure HTML interactive elements are compatible with RSCs: forms, inputs, submit buttons. That's because they do not use client-side JavaScript but are instead features provided directly by the browser engine/HTML.

As a default, Next RSCs are also static. As long as they don’t use cookies, headers or basically any request-specific data, they are rendered only once at build-time.

Static + RSC is the default in Next.js and it also happens to be the most optimal combo for a website. It needs no server computations after the initial build step and no client computations either. 

They are rendered once for all when you build the application. You can have 3 million users accessing your website, there is only 1 computation needed to render a page HTML content when using only RSCs.

This is kind of a dream scenario that we want to maintain as long as possible, until we really really need to switch to dynamic or client-side rendering.

However you shouldn't feel disappointed when static RSCs fall short. 

Using client-side rendering is still perfectly fine: that's how you make the application interactive and interesting for the end user. 

In module 4, we will learn how to mix client-side rendering and static rendering. Dynamic (request-time) server-side rendering is also fine, we will use it in module 5 to display a component that is specific to the current user.

React Server Components have sparked debates about their similarity with PHP. Indeed, they render HTML and React components, which mirrors PHP's template-based approach. 

All languages with web servers have similar templating systems: Jinja in Python Django, “html/template” package in Go, EJS with Node.js, ERB for Ruby on Rails...

No, because RSCs are not just server templates like the other tools I’ve mentioned. A fundamental difference lies in the deep integration with React client components. 

That’s what we do in the "preorder-section" component, which is a Client Component rendered by a Server Component page.

// src/components/preorder-section.tsx

// This is a Client component 
// (the default BEFORE Next.js App Router)
// it uses a hook
export function PreorderSection({initialCount}){ 
const { data , error, isLoading } = useSWR<{ count: number }>(
  '/api/preorder/count',
  jsonFetch,
)
return (<p>
    Join the other {data.count} customers who have already preordered.
  </p>)
}
---
//src/app/preorder/page.tsx

// This is a React Server Component 
// (the default AFTER Next.js App Router)
// Note that it can be "async",
// and that it can render a Client component
export default async function PreorderPage() {
  const preordersCount = await rscCountPreorders()
  return <PreorderSection initialCount={preordersCount} />
}

Some may argue that Web Components can also bring interactivity to traditional server-side rendered content, so 

"React Server Components + Client-side React"

That’s not totally wrong and for instance Go + Lit + Tailwind is a very interesting mix I had the chance to explore in a previous professional experience. 

But that’s not totally true either, because the integration between PHP and web components is not as deep: 

Someone crafted a “use php” directive to allow using PHP within React Server Components: 

.
Obviously as a joke but the fact that it works is proving the incredible capabilities of React Server Components!

Guillermo Rauch tweeted a good summary of the differences between Next.js App Router and PHP 

. I've talked about deep integration with Client Components, but there are other aspects too that differentiate React like the ability to render components concurrently.

Towards Server-only applications in Next.js

Thanks to RSC, and Server Actions that we will discover in lesson 3, the App Router brings the possibility to write “full server” applications and bring client-side code only as a last resort.

---
title: Static RSC - the new default
privateVideoUrl: https://stream.mux.com/FdPbyFi3hqmG00j7h7CaPDC62006ZkAQbRm3rr02FVe02f4.m3u8
isPublicLesson: true
---

## Meet React Server Components

As the landscape of web development evolves, new techniques and technologies emerge that can significantly improve the performance and user experience of web applications. 

One such technology that has recently been introduced is "React Server Components", aka RSCs. 

These components are themselves made possible thanks to the new architecture brought by Next.js 13, known as the App Router. 

RSCs represent the most tremendous paradigm shift in React since the introduction of hooks.

A React Server Components, in its simplest form, is really like a template written in JSX, a function that takes some data as parameters (the “props”) and returns HTML or more React Components.

```jsx
// Hello world in Next.js App Router:
// this is a statically rendered React Server Component
export function HelloWorld(props) {
    return <p>Hello world! My name is: {props.name}</p>
}
```

## Server Components vs Client Components

Before RSCs, we only had one type of React components: Client Components. 

It was already possible to render client components on the server, but they still needed some client-side JavaScript to work.

This process of rendering a Client Component first on the server, and then in the browser, is called hydration. Hydration allows the server-rendered component to become interactive when it lands in the browser.

React Server Components on the other hand, are rendered only on the server and do not require any client-side JavaScript to work. 

:::info
The `HelloWorld` component above has no actual server requirements, so it can be rendered client-side too. The [RFC that introduces Server Components](https://github.com/reactjs/rfcs/blob/bf51f8755ddb38d92e23ad415fc4e3c02b95b331/text/0000-server-components.md#sharing-code-between-server-and-client) calls such components "shared components", meaning they can be used by other server components or client components. [This video from Lauren Tan (React Core team)](https://www.youtube.com/watch?v=TQQPAU21ZUw&t=1707s) gives great explanations. Later on we will meet "pure" RSCs with actual server requirements.
:::

## Static, server-only components are the new default

The fact that RSCs don't need any client-side JavaScript makes them more performant than Client Components. And in Next.js, performance is always the default, so all your React components are Server Components unless stated otherwise.

```jsx
// This directive marks all components for this file
// as Client Components
"use client"
export function HelloWorldAlert(props) {
    // The "onClick" event handler
    // can't be used in a server component
    // That's why we need a client component
    return <button onClick={() => {
      alert("Hello World")
    }}>Click me</button>
}
```

Client component are needed when you need some JavaScript-based interactivity: using event handlers (`onClick`) or React hooks.

:::tip
Pure HTML interactive elements are compatible with RSCs: forms, inputs, submit buttons. That's because they do not use client-side JavaScript but are instead features provided directly by the browser engine/HTML.
:::

As a default, Next RSCs are also static. As long as they don’t use cookies, headers or basically any request-specific data, they are rendered only once at build-time.

## Keep it as static as possible

Static + RSC is the default in Next.js and it also happens to be the most optimal combo for a website. It needs no server computations after the initial build step and no client computations either. 

They are rendered once for all when you build the application. You can have 3 million users accessing your website, there is only 1 computation needed to render a page HTML content when using only RSCs.

This is kind of a dream scenario that we want to maintain as long as possible, until we really really need to switch to dynamic or client-side rendering.

However you shouldn't feel disappointed when static RSCs fall short. 

Using client-side rendering is still perfectly fine: that's how you make the application interactive and interesting for the end user. 

In module 4, we will learn how to mix client-side rendering and static rendering. Dynamic (request-time) server-side rendering is also fine, we will use it in module 5 to display a component that is specific to the current user.

## Is React the new PHP?

React Server Components have sparked debates about their similarity with PHP. Indeed, they render HTML and React components, which mirrors PHP's template-based approach. 

All languages with web servers have similar templating systems: Jinja in Python Django, “html/template” package in Go, EJS with Node.js, ERB for Ruby on Rails...

So is React becoming PHP? 

No, because RSCs are not just server templates like the other tools I’ve mentioned. A fundamental difference lies in the deep integration with React client components. 

That’s what we do in the "preorder-section" component, which is a Client Component rendered by a Server Component page.

```tsx
// src/components/preorder-section.tsx

// This is a Client component 
// (the default BEFORE Next.js App Router)
// it uses a hook
export function PreorderSection({initialCount}){ 
const { data , error, isLoading } = useSWR<{ count: number }>(
  '/api/preorder/count',
  jsonFetch,
)
return (<p>
    Join the other {data.count} customers who have already preordered.
  </p>)
}
---
//src/app/preorder/page.tsx

// This is a React Server Component 
// (the default AFTER Next.js App Router)
// Note that it can be "async",
// and that it can render a Client component
export default async function PreorderPage() {
  const preordersCount = await rscCountPreorders()
  return <PreorderSection initialCount={preordersCount} />
}
```

Some may argue that Web Components can also bring interactivity to traditional server-side rendered content, so **"PHP + Web Component"** could be equivalent to **"React Server Components + Client-side React"**.

That’s not totally wrong and for instance Go + Lit + Tailwind is a very interesting mix I had the chance to explore in a previous professional experience. 

But that’s not totally true either, because the integration between PHP and web components is not as deep: 

-   You need to learn 2 languages
-   Server-side rendering web components is still in active development
-   In React, the server-rendered elements are “known” by the client-side elements (not just the HTML but their structure and props).

:::tip
Someone crafted a “use php” directive to allow using PHP within React Server Components: [nextjs-use-php](https://github.com/bufferhead-code/nextjs-use-php).
Obviously as a joke but the fact that it works is proving the incredible capabilities of React Server Components!
:::

Guillermo Rauch tweeted a good summary of the differences between Next.js App Router and PHP [here](https://twitter.com/rauchg/status/1728459008544272657). I've talked about deep integration with Client Components, but there are other aspects too that differentiate React like the ability to render components concurrently.

## Towards Server-only applications in Next.js

Thanks to RSC, and Server Actions that we will discover in lesson 3, the App Router brings the possibility to write “full server” applications and bring client-side code only as a last resort.


Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Blazing Fast Next.js with React Server Components

WELCOMEIntroduction

Introduction:

Start Here

Module 1: Introduction to the Course

Lesson 1: (1:51)

Newline Commerce demo app

Lesson 2: (1:31)

Performance matters

Lesson 3: (3:00)

The Rendering Triforce

Lesson 4: (1:37)

Rendering in Newline Commerce (demo)

Module 2: Static Pages with Dynamic data

Lesson 1: (6:51)

Static RSC - the new default

Lesson 2: (6:38)

Getting data, statically

Lesson 3: (6:30)

Update data, with Server Actions

Module 3: Up-To-Date Static Rendering

Lesson 1: (6:09)

Static is great, you want static

Lesson 2: (7:07)

Page-level "revalidatePath"

Lesson 3: (8:43)

Datasource-level "revalidateTag"

Module 4: Client-Server Relaying

Lesson 1: (10:18)

Client-side data fetching recap

Lesson 2: (9:16)

Relaying with SWR

Module 5: Partial Prerendering (PPR)

Lesson 1: (9:43)

Mix Static and Dynamic Rendering

Module 6: Conclusion

Lesson 1: (5:21)

Congratulations!

Static RSC - the new default