fix: update blog post title and enhance content clarity on React Server Components and bundler integration

Author: sankalpaacharya

content/blog/why-rsc-need-bundler.mdx

@@ -1,5 +1,5 @@
 ---
-title: "Why rsc need a bundler"
+title: "How React Server Component Integrates with Bundler"
 description: "A deep dive into how React state updates really work, from hooks to batching"
 date: "2026-02-24"
 topic: "React"
@@ -8,64 +8,105 @@ draft: true
 
 
 # Intro 
-I have been trying to build a react server component from a scratch for a learning and it's been a fun quite not gonna lie. 
-In this blog i wanna share with you all my learning, why RSC integrates with a bundler and how different is React server component 
-from the CSR app we build or the spa app we build 
 
-this blog is not going to be about why we need a RSC or benefite of RSC rather it will be on a internal implementation detail, 
-if you are nerdy about these things then buckle up we are going to see through those in this blog
+I have been experimenting with building a [small version](https://github.com/sankalpaacharya/drop) of React Server Components to understand how the system works internally.
 
+This blog is not about why RSC is useful or what benefits it brings. It’s more focused on how it actually works under the hood, 
+especially how the server and client parts of a React app end up split during build time.
 
 
-# Little History
+# Interesting parts
 
-Before we move to a react server component let's have a quick recap, For many years react has always been on 
-the client side only, if you needed a data from the database you would have to wait till the browser downloads all the JavaScript, 
-parse it compile it and react renders all components commit them and after that the fetch call will begin. This way SEO suffers, 
-user will just have to stare at the blank screen while all these things is being processed 
+React server component has a protocl called a flight protocol which genereates a flight stream. This is not real JSON, but it looks similar in structure. It is closer to a structured wire format that React can parse incrementally while streaming.
 
-considering a same problem react team during 2021 introduced a New Suspense SSR Architecture in React 18, RSC was still in experimental
-phase that time, but i guess react team prepared the new suspense SSR Architecture considering the RSC they were working that time. 
-tho the initial RSC accountment was already done during the 2020 ie [Introducing Zero-Bundle-Size React Server Components](https://react.dev/blog/2020/12/21/data-fetching-with-react-server-components)
+One reason this format is not plain JSON is that React needs to support values that JSON normally cannot represent cleanly during serialization, such as async boundaries and server-side computations that may resolve over time.
 
+```tsx 
 
-# Interesting parts
+const promise = new Promise((resolve) => {
+  setTimeout(() => resolve("Sanku"), 1000);
+});
 
-react server component introduced a new protocl called a flight protocol which genereates a flight stream which looks something 
+const json = JSON.stringify(promise); // => '{}'
 
-React server component needs a tight integreation with the bundler, In a RSC paradigm we can have a both client and a server components
+```
 
-RSC gives a ability to generate a UI on server side and send that built UI on the client side as a flight protocl and none 
-of the JavaScript for this component needs to be shipped to a browser, since RSC sends a serialized flight stream not a HTML, client 
-side state are also preserved as well.
-https://overreacted.io/jsx-over-the-wire/#composing-viewmodels
+ Instead of trying to force everything into JSON semantics, React uses a custom format that can represent these cases in a streaming way.
 
-This can be pretty much confusing to a lot of people, is RSC is just a new SSR but that's actually not the truth cause 
-when you are doing SSR you are sending a rendered HTML to a client side and after that react on the client side takes a full control 
-you can't just ask few portion of your UI to get revalidated in SSR, you would need a full page re-fresh on that.
+- [You can serialize a promise in React](https://twofoldframework.com/blog/you-can-serialize-a-promise-in-react)
 
-so what actually mean in RSC is that a new version of a server subtree is streamed to the client and reconciled into the existing React tree
 
-React server component paradigm we can have a client component and a server component both, 
+Take this as an example
 
-like this 
+```tsx 
+// Server-Component.tsx
+async function Page() {
+  const user = await db.user.findFirst()
 
-[why cleint component need ssrd](https://github.com/reactwg/server-components/discussions/4)
+  return (
+    <div>
+      <h1>Dashboard</h1>
+      <p>{user.name}</p>
+      <AddToCart />
+    </div>
+  )
+}
+```
 
-# Let's begin 
+Now during a runtime RSC renderer will generate a flight stream for this which would look something like this 
+
+```json 
+1:["$","div",null,{
+  "children":[
+    ["$","h1",null,{
+      "children":"Dashboard"
+    }],
+
+    ["$","p",null,{
+      "children":"Sanku"   // from DB result
+    }],
+
+    ["$","$L1",null,{}]
+  ]
+}]
+```
 
-React UI is a tree in itself, this UI tree has leaves 🍃 in this tree, some leaves is for browser(client components) and some leaves
-is for the server(server component). 
+On the client side, this stream is reconstructed back into a React tree. This is what allows React Server Components to send UI from the server without shipping the implementation code for server components to the browser. 
+Because you are sending a rendered UI as a flight stream which will be constructued on client side.
 
-when we are building RSC app we build app from two prespective from a client world and from a server world. 
+while client components are resolved later using the referenced modules.
+
+```json 
+1:["$","div",null,{
+  "children":[
+    ["$","h1",null,{
+      "children":"Counter"
+    }],
+
+    ["$","$L1",null,{}]
+  ]
+}]
+```
+
+
+This can be pretty much confusing to a lot of people, is RSC is just a new SSR but that's actually not the truth cause 
+when you are doing SSR you are sending a rendered HTML to a client side and after that react on the client side takes a full control 
+you can't just ask few portion of your UI to get revalidated in SSR, you would need a full page re-fresh on that.
+
+# Let's begin 
 
-when it's a client build it's it goes from your entry file and your module graph, it travers your module graph and when it 
-encounters a servre component it will execute 
+A React UI is a tree. Some parts of this tree run on the server, and some parts run in the browser.
 
+In a React Server Components setup, we are no longer dealing with a single build target. Instead, the same codebase is processed from two perspectives: a server world and a client world.
 
+On the server side, the application is executed starting from the entry file. React walks through the module graph and renders all Server Components. These components run in a Node.js environment using the server renderer from react-server-dom, which does not include browser APIs like useState or event handlers.
 
+Instead of rendering the component, the server emits something like a module reference using registerClientReference. This reference does not contain implementation details. It only points to where the component exists in the client bundle.
 
 
+```tsx
+  let out = `import { registerClientReference } from "react-server-dom-webpack/server";\n`;
+```