Mastering the distinction between server and client components is crucial for any developer working with NextJS. This knowledge not only helps avoid common pitfalls but also plays a key role in enhancing application performance and user experience.

In this article, we’ll explore the essentials of server and client components in NextJS, shedding light on their unique roles and significance in modern web development. Whether you’re new to NextJS or seeking to refine your understanding, this guide aims to provide clear insights into these vital aspects of the framework.

Server

The server refers to the computer in a data centre that stores your application code, receives request from the client, does some computation, and sends back an appropriate response.

Client

The client refers to the browser on a user’s device, that sends a request to a server for your application code. It then turns the response from the server into an interface that the user can interact with.

React Server Components

React Server Components (RSC) represent a paradigm shift in how components are rendered in a React application. RSC allow you to write UI that can be rendered and optionally cached on the server.

Server Components are a way of executing React components on the server side and then sending the rendered output to React on the client side. This means that you don’t have to ship all of the dependencies that your project depends on, meaning they do not add to the bundle size sent to the client and resulting in a faster initial page load.

RSCs are still in the experimental phase, not yet ready for production at the time of writing this article. However, it is claimed that they have the potential to significantly improve the security, performance, and efficiency of React applications.

In NextJS, RSCs are available for use, offering developers the opportunity to experiment with these cutting-edge features in their projects. This integration into NextJS signifies an exciting step forward in the evolution of web development technologies.

Advantages of RSCs

As discussed above, RSCs are components that are stored and rendered on the server. This way of operating gives them three main advantages:

Direct access to the backend: Which makes fetching data from the databases faster
Smaller bundle size: RSCs contribute nothing to the overall bundle size of your application. This means you can even import large libraries without worrying about the overall application’s size
No confidential files are sent to the client: RSCs are not rendered on the client side, ensuring that the files are never exposed to the browser. This is important when working with API keys and auth tokens, as all of this sensitive data is kept on the server side

However, RSCs lack integration with the browser, which means they do not have client-side interactivity or state management capabilities. As a result, React Hooks such as useState, useEffect, and certain other NextJS APIs are not supported by RSCs.

Server components in NextJS

NextJS harnesses the power of React Server Components to enhance its capabilities offering a more efficient way to build and deploy web applications.

Server Components in NextJS are components that are rendered directly on the server. By default, all components in a NextJS application are treated as Server Components. This approach is transformative because it executes React components on the server side, sending only the rendered output to the client. This results in a minimal JavaScript footprint, as the dependencies and component code reside on the server, leading to a faster initial page load.

These components generate static HTML on the server, which is then sent to the client. This process significantly reduces the amount of JavaScript that needs to be shipped to the client, focusing on minimising the bundle size. The primary goal of Server Components is to streamline the user experience by ensuring that only necessary code is loaded on the client side.

As mentioned above, in NextJS, Server Components are the default. This means that server-side rendering is automatically implemented without any extra configuration. However, you have the flexibility to switch to Client Components as per the requirements of your application. This adaptability ensures that you can optimise each component based on its role and functionality.

Server Components can be made asynchronous for efficient data fetching. To demonstrate how Server Components in NextJS can be made asynchronous for efficient data fetching, let’s consider a simple example. In this scenario, we’ll create a Server Component that fetches data from an API asynchronously:

Note that you can async/await the server component which simplifies data fetching.

When it comes to user interactivity that relies on hooks like useState or useEffect, Server Components face limitations since they do not have access to client-side behaviours. In scenarios requiring user interactivity, transitioning to a Client Component becomes necessary to leverage the full capabilities of React on the client side.

Client components in NextJS

Client Components in NextJS allow for interactive UI elements that are rendered on the client side at request time. Unlike Server Components, which are the default in NextJS, Client Components are opt-in. This means you must explicitly specify which components React should render on the client by adding the use client directive. We will see the example below.

There are two key features of Client Components.

Interactivity: Client Components can utilise state, effects, and event listeners, enabling immediate feedback and dynamic UI updates.
Access to Browser APIs: They have access to browser-specific APIs, such as geolocation or localStorage, allowing for more tailored user experiences.

To use Client Components, we need to add the use client directive at the top of a file, above the imports.

use client directive establishes a boundary between Server and Client Component modules, ensuring that all modules imported into a file with use client are part of the client bundle.

Note: You don’t need to declare use client in every client-rendered component. Once defined, it creates a client boundary and applies to all child components and imported modules within that boundary as client components.

In the example, BlogSearch is a client-side component using React state and an event handler. The use client directive ensures that React renders this component on the client, where browser APIs and interactivity are available.

Note: As mentioned, in NextJS, all components are server components by default, so there is no need for a directive like use server. The use server directive is used for specific server actions, which will be covered in an upcoming article.

Now we’ve explored the distinctions between server and client components. The choice between server and client components in NextJS hinges on the specific needs of your application, such as interactivity, access to browser APIs, and performance considerations. Here is the guideline from the NextJS documentation.

Source: Server and Client Composition Patterns

Client components in Server components

So now we know the differences between the server and client components. And often times, we are composing client components and server components together.

Let’s revisit the code example.

Here the Blog is a server component and BlogSearch is a client component and we can import the client component into the server component and also the client component can be a child of the server component.

This integration is made possible because server components, when rendered, can include references to client components. This process informs the bundler to package the client component’s code separately, which is then sent to the browser for execution.

This combination allows us to leverage the strengths of both server-side efficiency and client-side interactivity in our applications such as the server component handles the initial rendering and data fetching, and the client component takes over for interactive elements.

Server components in client components

Importing a server component into a client component directly isn’t possible. Let’s take a look at the code below.

It’s not possible because client components, which execute in the browser, can’t dynamically call server-side code during their rendering. Furthermore, any component imported into a client component is treated as a client component, due to the use client directive which ensures that all components within its boundary are treated as client components.

To use server components in client components, we can pass a server component as a prop to a client component. Let’s see the updated code:

And from the parent component which is the server component,

It is possible because the client component treats the prop as static content, regardless of whether it was server-rendered or client- rendered.

So in the above code, BlogSearch, a client component, receives ServerComponent as a child. This setup allows BlogSearch to render dynamic content provided by ServerComponent while maintaining client-side interactivity.

Conclusion

Navigating the complexities of server and client components in NextJS offers a path to building more efficient, responsive, and user-friendly web applications. By understanding when and how to leverage each type of component, developers can optimise their applications for both server-side efficiency and client-side interactivity.

I hope this article was helpful and stay tuned for more insights on different rendering strategies in NextJS such as SSG, SSR, ISR and CSR, which will further enhance your development journey.