Pockit
Back

A Deep Dive into React Server Components: The End of `useEffect`?

If you’ve been following the React ecosystem lately, particularly with the release of Next.js 13 and 14, you’ve likely felt the tremors of a massive paradigm shift. It’s no longer just about hooks and virtual DOMs. We are entering the era of React Server Components (RSC).

For many developers, this transition has been... confusing. We're seeing errors about "serialization," grappling with strict boundaries between "client" and "server," and relearning how to fetch data. The most jarring realization? The tool we’ve relied on for years to handle side effects and data fetching—useEffect—is suddenly being pushed to the sidelines.

Is useEffect dead? No. But for data fetching, it’s on life support.

In this deep dive, we’re going to peel back the layers of abstraction. We won't just look at how to use Server Components, but how they actually work under the hood, the architectural problems they solve, and why this new mental model is superior for building large-scale applications.

The Old World: Client-Side Waterfalls

To understand the "why" of RSC, we must look at the "how" of the past few years.

In a typical React Single Page Application (SPA), or even in standard implementation of getServerSideProps in older Next.js versions, the browser receives a large JavaScript bundle. React boots up, the component tree mounts, and then—triggering from useEffect—we start fetching data.

// The "Old" Way
function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch(`/api/users/${userId}`).then(data => {
      setUser(data);
      setLoading(false);
    });
  }, [userId]);

  if (loading) return <Spinner />;
  
  return (
    <div>
       <h1>{user.name}</h1>
       <UserPosts userId={userId} />
    </div>
  );
}

Wait, look at <UserPosts />. Usually, that component also has a useEffect to fetch posts.

  1. Browser loads JS.
  2. UserProfile mounts. useEffect runs. Network request for User.
  3. User data arrives. UserProfile re-renders.
  4. UserPosts mounts. useEffect runs. Network request for Posts.
  5. Posts data arrives. UserPosts re-renders.

This is a Network Waterfall. The child cannot finish loading until the parent has finished loading. As your application grows, these waterfalls cascade down, resulting in a sluggish user experience (high Interaction to Next Paint) and a "loading spinner hell."

We tried to patch this with libraries like React Query or SWR, or by hoisting data fetching to the route level. But the fundamental issue remained: The logic for what data to fetch was coupled to the component using it, but purely executed on the client.

Enter React Server Components

React Server Components allow components to render exclusively on the server. They have direct access to your backend infrastructure. They can read from the file system, query a database directly, or call internal microservices—all without sending a single byte of that logic to the client.

Here is the same component in the RSC world:

// app/users/[id]/page.tsx
import db from '@/lib/db';

async function UserProfile({ params }) {
  const user = await db.user.findUnique({ where: { id: params.id } });

  return (
    <div>
      <h1>{user.name}</h1>
      <UserPosts userId={params.id} />
    </div>
  );
}

async function UserPosts({ userId }) {
  const posts = await db.post.findMany({ where: { authorId: userId } });

  return (
    <ul>
      {posts.map(post => <li key={post.id}>{post.title}</li>)}
    </ul>
  );
}

Notice something?

  1. No useState.
  2. No useEffect.
  3. Async components.

The data fetching happens during the render pass on the server. When the server renders UserProfile, it hits the await. It pauses. It fetches the data. Then it continues. It reaches UserPosts. It hits await. It fetches data.

Because this happens on the server (low latency to the DB), these waterfalls are extremely fast, often negligible compared to a client-server roundtrip. More importantly, we can use Promise.all or parallel routing to parallelize these requests easily.

But the real magic is what gets sent to the browser.

The Secret Protocol: "Flight"

When you request a page using RSC, the server doesn't send HTML (that's SSR, specifically). It doesn't send JSON (that's an API). It sends a special serialized format often nicknamed "Flight".

If you curl a Next.js App Router page, you might see something like this mixed in:

1:I["./src/components/ClientCounter.js",["234","345"],"ClientCounter"]
0:["$","div",null,{"children":[["$","h1",null,{"children":"Hello World"}],["$","$L1",null,{}]]}]

This is the serialized React tree.

  • It describes the HTML elements (div, h1).
  • It contains the props passed to them.
  • Crucially, for Client Components, it sends a reference (the huge ID I["..."]) telling the browser: "Hey, put the code for ClientCounter here."

Server Components are resolved on the server. Their code is never sent to the browser. If you import a heavy date formatting library like moment.js in a Server Component, use it to format a date, and render the string—the browser only receives the string. The library cost is 0kb.

This is a massive win for bundle sizes.

The Boundary: Server vs. Client

Since Server Components run on the server, they cannot do "interactive" things.

  • They cannot use useState or useEffect.
  • They cannot add event listeners (onClick).
  • They cannot access browser APIs like localStorage or window.

When you need interactivity, you must opt-in to the client side using the "use client" directive.

// src/components/LikeButton.tsx
'use client'; // 👈 This makes it a Client Component

import { useState } from 'react';

export default function LikeButton() {
  const [likes, setLikes] = useState(0);
  return <button onClick={() => setLikes(likes + 1)}>Like {likes}</button>;
}

A common misconception is that "use client" makes the component typically "CSR" (Client-Side Rendered only). This is false. Client Components are also pre-rendered on the server to generate initial HTML (SSR) for SEO and First Contentful Paint. The difference is that their code is sent to the browser so they can "hydrate" and become interactive.

The "Composition" Pattern

You might think, "If I add a Context Provider at the root, doesn't my whole app become client-side?"

Yes, if you wrap your children directly in the file with "use client". But there is a pattern to mix them.

You can pass Server Components as children to Client Components.

// app/page.tsx (Server Component)
import ClientLayout from './ClientLayout';
import ServerPostList from './ServerPostList';

export default function Page() {
  return (
    <ClientLayout>
      <ServerPostList /> {/* This remains a Server Component! */}
    </ClientLayout>
  );
}
// app/ClientLayout.tsx (Client Component)
'use client';

export default function ClientLayout({ children }) {
  const [theme, setTheme] = useState('dark');
  return (
    <div className={theme}>
      {children} {/* We don't know what this is, we just render it */}
    </div>
  );
}

In the "Flight" data, ClientLayout receives a children prop that is already resolved "slots" or JSX descriptions of ServerPostList. The ClientLayout doesn't need to know ServerPostList's logic. It just renders the slot.

Why useEffect is Dying for Data Fetching

We used useEffect for data fetching because we had no other place to put side effects in the render flow. But useEffect has issues:

  1. It runs after paint. The user sees the UI, then the spinner starts.
  2. It causes layout shifts if not handled carefully with skeleton states.
  3. It suffers from race conditions. (What if the first request returns after the second one?)

With RSC, we fetch data before we render. We await the data.

const data = await getData();
return <View data={data} />;

The data is there. Guaranteed. No loading state to manage inside the component logic (though you use Suspense for the UI loading state). No race conditions. No "mount check" to prevent double validation in React 18 strict mode.

It’s cleaner. It’s synchronous-looking code. It’s beautiful.

Challenges and Pitfalls

It's not all sunshine.

1. Serialization Boundaries: You cannot pass a function (like a callback) from a Server Component to a Client Component.

// ❌ Error: Functions cannot be passed directly to Client Components
<ClientButton onClick={() => console.log('server log')} />

Why? Because functions aren't serializable JSON. You must use Server Actions to communicate back, or keep the logic inside the Client Component.

2. Third-Party Libraries: Many libraries (like CSS-in-JS solution styled-components or older slider libraries) assume they run in a browser. They might access window at the top level. Using them in RSCs will crash the build. You often have to wrap them in a generic Client Component to "shield" the server.

3. The Initial Load: While data fetching is faster, the "Time to First Byte" (TTFB) can increase if you block the server render on a slow database query. Streaming (via Suspense) becomes critical here. You wrap your slow component in <Suspense fallback={<Skeleton />}> so the server can send the rest of the page first and stream in the slow chunk later.

Conclusion

React Server Components are more than a feature; they are a correction. They bring the "Server" back into the "Client" framework, acknowledging that most modern apps are distributed systems, not just isolated desktop apps running in a browser tab.

The mental model is simpler:

  • Server Component: Fetch data, access secrets, keep code off the client. Default choice.
  • Client Component: Interactivity, hooks, browser APIs. Opt-in choice.

So, is useEffect dead? For synchronizing external systems like subscriptions, WebSockets, or manual DOM manipulation—absolutely not. But for standard data fetching? Yes. And good riddance. We are trading disparate useEffect hooks for async/await and Request/Response flows, and the web is better for it.

The next time you reach for useEffect to call an API, stop. Ask yourself: "Could this just be an await on the server?"

If you are migrating your large-scale app to Next.js App Router, start from the leaves (buttons, inputs) and work your way up. Don't try to rewrite the whole page at once. The hybrid model is powerful, but unforgiving if you fight the paradigm.

ReactNext.jsServer ComponentsPerformanceWeb Development