From 3a53b1e2d49a6d0ddc8b931a399d30ff58da1e57 Mon Sep 17 00:00:00 2001 From: Tanner Linsley Date: Tue, 28 Apr 2026 10:52:46 -0600 Subject: [PATCH] docs(blog): rename RSC post to lead with "Who Owns the Tree?" Renames the draft post slug and asset folder, updates the title, and redirects the previous slug. --- .../flight_cache_pipeline.svg | 0 .../two_inversions_rsc.svg | 0 ...wns-the-tree-rsc-is-a-protocol-not-an-architecture.md} | 8 +++++--- 3 files changed, 5 insertions(+), 3 deletions(-) rename public/blog-assets/{rsc-is-a-protocol-before-it-is-an-architecture => who-owns-the-tree-rsc-is-a-protocol-not-an-architecture}/flight_cache_pipeline.svg (100%) rename public/blog-assets/{rsc-is-a-protocol-before-it-is-an-architecture => who-owns-the-tree-rsc-is-a-protocol-not-an-architecture}/two_inversions_rsc.svg (100%) rename src/blog/{rsc-is-a-protocol-before-it-is-an-architecture.md => who-owns-the-tree-rsc-is-a-protocol-not-an-architecture.md} (96%) diff --git a/public/blog-assets/rsc-is-a-protocol-before-it-is-an-architecture/flight_cache_pipeline.svg b/public/blog-assets/who-owns-the-tree-rsc-is-a-protocol-not-an-architecture/flight_cache_pipeline.svg similarity index 100% rename from public/blog-assets/rsc-is-a-protocol-before-it-is-an-architecture/flight_cache_pipeline.svg rename to public/blog-assets/who-owns-the-tree-rsc-is-a-protocol-not-an-architecture/flight_cache_pipeline.svg diff --git a/public/blog-assets/rsc-is-a-protocol-before-it-is-an-architecture/two_inversions_rsc.svg b/public/blog-assets/who-owns-the-tree-rsc-is-a-protocol-not-an-architecture/two_inversions_rsc.svg similarity index 100% rename from public/blog-assets/rsc-is-a-protocol-before-it-is-an-architecture/two_inversions_rsc.svg rename to public/blog-assets/who-owns-the-tree-rsc-is-a-protocol-not-an-architecture/two_inversions_rsc.svg diff --git a/src/blog/rsc-is-a-protocol-before-it-is-an-architecture.md b/src/blog/who-owns-the-tree-rsc-is-a-protocol-not-an-architecture.md similarity index 96% rename from src/blog/rsc-is-a-protocol-before-it-is-an-architecture.md rename to src/blog/who-owns-the-tree-rsc-is-a-protocol-not-an-architecture.md index 45ec0bf1..f8553f8f 100644 --- a/src/blog/rsc-is-a-protocol-before-it-is-an-architecture.md +++ b/src/blog/who-owns-the-tree-rsc-is-a-protocol-not-an-architecture.md @@ -1,10 +1,12 @@ --- -title: RSC Is a Protocol Before It Is an Architecture +title: 'Who Owns the Tree? RSC Is a Protocol, Not an Architecture' published: 2026-04-28 draft: true excerpt: RSC is usually framed as a single architecture where the server owns the tree. But it is also a protocol, and the protocol supports more than one composition model. The overlooked question is who owns the tree. authors: - Tanner Linsley +redirect_from: + - rsc-is-a-protocol-before-it-is-an-architecture --- React Server Components are usually discussed as if they describe one architecture: the server owns the tree, client boundaries are marked with `use client`, and the framework stitches everything together during hydration. @@ -66,7 +68,7 @@ The seam is placed by the client. The server says, "here is rendered content sha This is the symmetry:
- The two RSC composition models: server owned trees use client boundaries for interactivity, while client owned trees use server rendered slots for server regions. + The two RSC composition models: server owned trees use client boundaries for interactivity, while client owned trees use server rendered slots for server regions.
The two RSC composition models differ in which side owns the tree and which side fills regions of it.
@@ -205,7 +207,7 @@ That is the important distinction: the RSC output is not trapped inside a framew A server function can return a Flight stream as bytes. Those bytes can be cached at whatever layer the application already owns:
- Flight bytes passing through cache layers: render pass, server, network, and client, with decoding at render time after each cache boundary. + Flight bytes passing through cache layers: render pass, server, network, and client, with decoding at render time after each cache boundary.
Flight output can remain transparent through the cache layers the application already controls.