Os novos compoñentes do servidor de React poderían ser a morte das aplicacións web inundadas

queFunción RSC (React Server Components) SSR (Server-Side Rendering) CSR (Client-Side Rendering) Render location Server Server Client JavaScript enviado ao navegador 🔸 None ✅ Si ✅ Si Require hidratación 🔸 Non ✅ Si ✅ Si Interactividade 🔸 Non ✅ Full ✅ Full Access to server resources ✅ Direct ✅ Via getServerSideProps 🔸 Necesita chamadas API Cando se executa On-demand ou Streamed Per request On load in browser Ideal case use Estática ou datos-bound views Personalizado ou dinámico UI Fluxos interactivos, local UX Características RSC (Compoñentes do servidor de reacción) SSR (Rendering do lado do servidor) CSR (Rendering do lado do cliente)quequeEnviar localizaciónqueServizosqueServizosqueclientequequeJavaScript enviado ao navegador Ningún ✅ Si ✅ SiqueRequire hidratación Non ✅ Si ✅ SiqueInteractividade Non ✅ Completo ✅ CompletoqueAcceso aos recursos do servidor ✅ Directo ✅ A través de getServerSideProps ❌ Necesita chamadas de APIqueCando se executa On-demand ou transmitido por petición En carga no navegadorqueCaso de uso ideal Visións estáticas ou baseadas en datos UI personalizado ou dinámico Fluxos interactivos, UX localqueCaracterísticas RSC (Compoñentes do servidor de reacción) SSR (Rendering do lado do servidor) CSR (Rendering do lado do cliente)Características RSC (compoñentes de servidor de reacción) que queEnviar localizaciónqueServizosqueServizosqueclientequeEnviar localización que Servizos cliente JavaScript enviado ao navegador Ningún ✅ Si ✅ SiJavaScript enviado ao navegador Ningunha que que Require hidratación Non ✅ Si ✅ SiRequire hidratación non Si Si que Interactividade Non ✅ Completo ✅ Completoque que que que Acceso aos recursos do servidor ✅ Directo ✅ A través de getServerSideProps ❌ Necesita chamadas de APIAcceso aos recursos do servidor Directamente ✅ A través de getServerSideProps Precisa de chamadas API Cando se executa On-demand ou transmitido por petición En carga no navegadorcando se corre On Demand ou Streamed Por petición que Caso de uso ideal Visións estáticas ou baseadas en datos UI personalizado ou dinámico Fluxos interactivos, UX localCaso de uso ideal que que Fluxos interactivos, UX local queCompoñente de servidor Compoñente de clientequequeO efectoqueusoContexto ✅ (se estático) ✅queasync/await ✅ (debería envolverse en efectos)Xogadores Compoñente de servidor Compoñente de clienteque Utilización que O efectoqueusoContexto ✅ (se estático) ✅queasync/await ✅ (debería envolverse en efectos) Xogadores Compoñente de servidor Compoñente de cliente que queUtilizaciónqueque Utilización que O efecto que usoContexto ✅ (se estático) ✅Utilización do contexto que queque queque que que Xogadoresque que queCompoñente Rendering Estratexia Razón ProdutoDetalles RSC Obtido de DB, sen interactividade, sen necesidade de hidratar PriceWithPersonalization SSR Depende da sesión do usuario, dinámico por solicitude AddToCartButton CSR Require interactividade e estado local RelacionadosProductos SSG (con ISR) Seguro para cache no tempo de construción, pode revalidar cada 24h ou por tag StockStatusBanner RSC + streaming Frecuentemente cambiante, transmitido con Suspensión para non bloquear TTFB Compoñente Rendering Estratexia Razón Detalles do produto RSC recuperado de DB, sen interactividade, sen necesidade de hidratarqueSSR de personalización Depende da sesión do usuario, dinámico por solicitudeque queCSRqueque queProdutos SSG (con ISR) Seguro para cache no tempo de construción, pode ser revalidado cada 24 horas ou por etiquetaquequeAcciónsBannerqueRSC + reproduciónqueCambiar con frecuencia, transmitido con Suspense para non bloquear TTFBquequeCompoñente Rendering Estratexia Razónque que Detalles do produto RSC recuperado de DB, sen interactividade, sen necesidade de hidratar RSC Tirado de DB, sen interactividade, sen necesidade de hidratar SSR de personalización Depende da sesión do usuario, dinámico por solicitudeque SSR que queCSRqueque CSR que Produtos SSG (con ISR) Seguro para cache no tempo de construción, pode ser revalidado cada 24 horas ou por etiquetaque que que queAcciónsBannerqueRSC + reproduciónqueCambiar con frecuencia, transmitido con Suspense para non bloquear TTFBqueAcciónsBanner RSC + reprodución (*Se desexa saltar adiante e mergullarse directamente no desastre técnico, salta a 1.Por que se introduciron os compoñentes do servidor React.) A principios da década de 2010, React revolucionou o desenvolvemento frontend co seu modelo de compoñentes declarativos e a difusión eficiente do DOM virtual. O que comezou como unha biblioteca de visualización simple pronto converteuse na columna vertebral para aplicacións de páxina única a gran escala (SPAs). Estes SPAs usaron predominantemente Client-Side Rendering (CSR), o que significa que o navegador descargaría un bundle de JavaScript, executalo e construíra a interfaz de usuario enteiramente no cliente. Este modelo centrado no cliente era flexible e altamente interactivo, e definía aplicacións web "modernas" durante anos. con todo, a medida que as aplicacións crecían máis complexas e ricas en recursos, o enfoque de RSE comezou a mostrar as súas fendas: que que que que Longer Time-to-Interactive (TTI): Os paquetes de JavaScript pesados e o traballo do lado do cliente significaron que os usuarios esperaban máis tempo antes de que puidesen interactuar coa páxina. Conversión de HTML renderizado por servidor nunha aplicación interactiva (hidratación) converteuse nun punto de choque de rendemento, especialmente a medida que a cantidade de contido dinámico aumentou. Os paquetes inundados: As aplicacións frecuentemente enviaban moito máis JavaScript do que era necesario, sobrecargando os navegadores con código para funcións ou contidos que poderían ser entregados de forma máis eficiente. Desempeño que non se escala: canto máis grande e complexa sexa a aplicación, máis difícil será manter o rendemento rápido en todos os dispositivos e condicións de rede. Next.js emerxeu para abordar algúns destes puntos de dor introducindo Server-Side Rendering (SSR), Static Site Generation (SSG), e outras optimizacións. Estas técnicas melloraron os tempos de carga inicial e descargaron parte do traballo de renderización de UI ao servidor. Con Next.js 15 executado en React 19, un novo paradigma de renderización tomou o centro da escena: Os RSC permiten aos desenvolvedores mesturar de forma suave os compoñentes renderizados polo servidor e os renderizados polo cliente nunha única árbore de React. As implicacións son significativas. Noutras palabras, non é necesaria ningunha hidratación do lado do cliente para esas seccións.A lóxica de captura de datos tamén se simplifica executando os compoñentes do servidor, eliminando moitas chamadas de API innecesarias do navegador.O resultado: bundles máis lixeiros do lado do cliente, interaccións máis rápidas e unha aplicación que é moito máis eficiente e escalable. React Server Components (RSC) zero JavaScript overhead Este artigo non é unha revisión a nivel de superficie de RSC. Cando comecei a escribir sobre o uso eficaz de Next.js en 2025, rapidamente quedou claro que React Server Components merecía un mergullo profundo dedicado. O que segue é unha exploración tecnicamente rigorosa de como o RSC funciona baixo o capó, como aproveitalo nun proxecto Next.js 15 e por que representa un cambio fundamental na arquitectura frontend. Ao final, espero que saia coa mesma claridade e apreciación para RSC que fixen a través do proceso de investigación e escritura desta obra. Intro: From CSR to RSC — How Rendering Evolved in React Introdución: De CSR a RSC - Como o rendemento evolucionou en reacción Ao longo da última década, a forma en que construímos aplicacións de React evolucionou fundamentalmente e, con ela, a forma en que pensamos sobre a renderización. Unha breve historia de Client-Side Rendering (CSR) en React React gañou a súa popularidade a través de Un modelo onde o navegador descarga JavaScript, execútalo e constrúe toda a interfaz de usuario no cliente.Este enfoque deu aos desenvolvedores un control total sobre a interactividade e o estado, e facilitou a construción de aplicacións dinámicas de páxina única (SPA). Client-Side Rendering (CSR) Con todo, a CSR veu con notables compromisos: que que que que que Cargas iniciais máis lentas, especialmente en redes móbiles ou pobres Poor SEO para páxinas orientadas ao contido Paquetes de JavaScript pesados - mesmo para páxinas con interacción mínima Foi necesario un paso de hidratación despois de que se cargase HTML, retrasando o tempo de interacción Por un tempo, estas limitacións eran só "como eran as cousas".Entón Next.js cambiou o xogo. Como Next.js trouxo SSR e SSG ao desenvolvemento de React cando Introduciu a renderización do lado do servidor (SSR) e a xeración estática de sitios (SSG) como cidadáns de primeira clase para React. Isto marcou un punto de inflexión: os desenvolvedores de frontend agora podían escoller como e cando ocorreu a renderización. Next.js que que que que SSR permitiu xerar páxinas por solicitude, mellorando o SEO e a velocidade de carga para o contido dinámico. SSG permitiu que o contido fose preconstruído no momento da implantación, perfecto para blogs, documentos e sitios de marketing. A rexeneración estática incremental (ISR) puxo fin á brecha permitindo que as páxinas estáticas se actualizasen despois da implantación. Esta flexibilidade axudou aos desenvolvedores a alcanzar un mellor equilibrio entre o rendemento, o SEO e a experiencia do desenvolvedor. Pero mesmo con SSR e SSG, aínda había un problema pendente: - mesmo para compoñentes que non tiñan que ser interactivos. we were still sending too much JavaScript to the browser O aumento dos compoñentes de servidor React (RSC) en 2025 coa liberación de e Entramos nunha nova era: Son agora unha parte fundamental de como construímos aplicacións. Next.js 15 React 19 React Server Components (RSC) A diferenza de SSR, que aínda require hidratación e envía JavaScript ao cliente, . . RSC allows you to render components on the server — without sending any JavaScript to the browser at all É un gran cambio: que que que que Os compoñentes agora poden acceder directamente aos datos do lado do servidor O contido estático non require hidratación Pode mesturar os compoñentes do servidor e do cliente nunha única árbore de React, compondo a súa estratexia de renderización por compoñente RSC non substitúe SSR ou SSG. , desbloqueando un control máis fino sobre o rendemento, o tamaño do paquete e o comportamento de renderización. complements them En 2025, RSC é un concepto fundamental que todos os enxeñeiros de React deben dominar. 1. Why React Server Components Were Introduced Por que se introduciron os compoñentes do servidor React A medida que as aplicacións de React se tornaron máis complexas, a industria comezou a sentir o peso do seu éxito.Mentres que o cliente-side rendering (CSR), servidor-side rendering (SSR) e xeración de sitio estático (SSG) ofreceu estratexias diferentes para construír aplicacións web de alto rendemento, cada un deles levou a cabo compromisos que se tornaron máis evidentes en escala. Limitacións de CSR, SSR e SSG 1o Hydration overhead Mesmo con SSR ou SSG, unha vez que o HTML alcance o navegador, React necesita "hidratar" a páxina - conectar audiencias de eventos, reiniciar compoñentes e reconstruír efectivamente a aplicación na memoria. 2o JavaScript bundle bloat Con CSR, cada compoñente, utilidade e chamada de API que forma parte da páxina debe ser enviada ao navegador, independentemente de que sexa interactivo ou non. SSR e SSG reducen isto lixeiramente, pero a maioría do paquete aínda necesita ser executado no cliente. 3o Disconnected data-fetching logic No mundo pre-RSC, os datos vivían fóra dos compoñentes que os renderizaban. ou (ou chamar ás APIs en Esta separación engadiu sobrecarga cognitiva e fixo que o código fose máis difícil de localizar e reutilizar. getServerSideProps getStaticProps useEffect Que problemas RSC foi deseñado para resolver React Server Components (RSC) foron creados para abordar estes puntos de dor crecentes cunha idea simple pero poderosa: . . let components execute on the server by default, and only send JavaScript to the browser when it’s absolutely necessary Eliminate unnecessary JavaScript RSC permite que os compoñentes sexan renderizados do lado do servidor Se un compoñente non require interactividade, non hai necesidade de hidratar ou cargar o seu paquete JS. sen Server-side data access within the component tree RSC elimina a fronteira artificial entre a captura de datos e a renderización. para acceder directamente a bases de datos, sistemas de ficheiros ou APIs - co-localizar datos e ver a lóxica de forma natural, sen necesidade de rutas de API ou perforación de prop. async/await Improve rendering efficiency and developer experience Ao mover a lóxica non interactiva ao servidor, os desenvolvedores poden construír aplicacións máis lixeiras con paquetes máis pequenos e un mellor rendemento. RSC tamén simplifica o modelo mental - só escribe compoñentes e deixa que o marco manexe onde se executan e como se envían. RSC non ten como obxectivo substituír SSR ou SSG, senón que os complementa. , non só o nivel da páxina, sobre o que debe executarse no servidor e o que pertence ao navegador. at the component level In short: React Server Components were designed to bring modern frontend development back to its lean, fast, and maintainable roots without compromising interactivity. 2. Rendering Strategies in Next.js 15: RSC vs SSR vs CSR Estratexias de rendemento en Next.js 15: RSC vs SSR vs CSR Next.js 15 ofrece aos desenvolvedores un modelo de renderización granular que vai moito máis alá das estratexias tradicionais a nivel de páxina. Para converterse nun concepto de primeira clase, é esencial entender como se comparan con dous modelos coñecidos: e . . React Server Components (RSC) Server-Side Rendering (SSR) Client-Side Rendering (CSR) Aínda que SSG (xeración de sitios estáticos) aínda é valioso en casos específicos, pódese ver como un construído sobre a base da SSR. En contraste, represent distinct runtime rendering paths, and understanding them is crucial for making performance- and architecture-aware decisions in 2025. caching strategy RSC vs SSR vs CSR 💡 Antes de comparar: que queremos dicir por "compoñente interactivo"? No contexto de React e Next.js, unha Calquera elemento que . . interactive component requires client-side JavaScript to respond to user input or browser events Isto inclúe (pero non está limitado a): que que que que que que que Botóns que actualizan o estado en clic Formularios con entradas de validación ou controladas Dropdowns e modals que cambian aberto / pechado Animacións desencadeadas por scrolling ou hover Tabs, carrozas, filtros e slides Compoñentes que usan useState, useEffect ou useReducer Se un compoñente ten → Interno ou confiar na súa Debe correr sobre o cliente. event handlers state DOM or browser APIs Interactivity = Browser-side behavior + JS event listeners + local state. Comprender esta distinción axuda a aclarar : para evitar o envío de JavaScript para pezas de interface que non teñan que ser interactivas. why RSC exists Rendering modelos a unha ollada Características RSC (compoñentes de servidor de reacción) SSR (Server-Side Rendering) SSR (Rendering ao lado do servidor) CSR (Rendering do lado do cliente) CSR (Rendering do lado do cliente) Enviar localización Servizos Servizos Servizos cliente JavaScript enviado ao navegador Ningunha Si Si Si Si Require hidratación Non Si Si Interactividade Interactivity Non ❌ No ✅ Full Unha chea Unha chea Unha chea Acceso aos recursos do servidor Directamente ✅ A través de getServerSideProps Precisa de chamadas API cando se corre On-demand or streamed Por petición Descargar en Browser Descargar en Browser Caso de uso ideal Visións estáticas ou baseadas en datos Visións estáticas ou baseadas en datos UI personalizado ou dinámico UI personalizado ou dinámico Fluxos interactivos, UX local Think in Components, Not Just Pages Nas versións anteriores de Next.js, as estratexias de renderización aplicáronse na . You had , Calquera que sexa a súa elección aplicada ao Isto fixo sentido nun mundo onde a renderización ocorreu todo ou nada - xa sexa estáticamente no tempo de construción, ou dinámicamente en cada solicitude. page level getServerSideProps getStaticProps Páxina completa Pero con e o directorio introducido en Next.js 13+ e estandarizado en 15, converteuse en a Isto desencadea unha nova mentalidade. React Server Components (RSC) app/ rendering is no longer a top-down, one-size-fits-all decision per-component concern 🧠 A New Way of Thinking: Declarative and Composable Rendering Este cambio é máis que un cambio de API, é un cambio conceptual na forma en que arquitecta o seu frontend. Declarative No canto de orquestración e os compoñentes son renderizados manualmente, agora simplemente — React e Next.js coidan do resto. como onde declare what each component does and what it needs Non transmite props de SSR a compoñentes, nin transmite props manualmente a puntos finais de API. // Server Component export default async function ProductInfo() { const product = await db.getProduct(slug) return {product.name} } Este compoñente: que que que que que Runs on the server Non envíe JS ao cliente Non require ningún getServerSideProps ou capa de API É "só un compoñente" - non é necesaria ningunha abstracción adicional Describe a UI e as súas necesidades de datos , e o motor de renderización calcula o resto. declaratively Composable Diferentes partes da súa interfaz de usuario poden usar diferentes estratexias de renderización. , , e . . on the same page at the same time with minimal overhead Por exemplo: // Product page layout // Server Component (no JS, rendered on the server) // Client Component (interactive) // Static Component (SSG with revalidation) Estes compoñentes viven xuntos na mesma árbore, pero cada un: que que que que Executa nun ambiente diferente (servidor, cliente, construír) Utiliza só os datos e o código que necesita Navega exactamente o que se require para o navegador - non máis, non menos Para facelo máis sinxelo, fixemos unha que mostra como diferentes estratexias de renderización poden coexistir nunha única páxina. Demo mínimo 3. How React Server Components Work Under the Hood 3. How React Server Components Work Under the Hood React Server Components (RSC) son máis que unha nova estratexia de renderización, cambian fundamentalmente como se constrúen, renderizan e transmiten as árbores de compoñentes. e como afecta ás fronteiras de estado, interactividade e datos. how it works behind the scenes Fronteira de servidor/cliente: unha árbore de reacción dividida As aplicacións de reacción que usan RSC xa non se renderizan completamente no cliente. : de component tree is split into two worlds que que Compoñentes do servidor: só se executa no servidor. Nunca se envía JavaScript ao navegador. Non se pode manter o estado local ou anexar auditorios de eventos. Perfecto para renderizar contido estático e lóxica vinculada ao servidor (por exemplo, acceso DB). Compoñentes do cliente: Deben estar explicitamente marcados con "Use client".Estes compilados en JavaScript amigable ao navegador e soportan a interactividade completa, o estado local, o usoEffect e a xestión de eventos. En build ou runtime, React constrúe unha árbore onde os compoñentes do servidor e do cliente coexisten e as une durante a renderización. 📍 What En realidade fai "use client" When you add a un ficheiro, marca que todo o módulo e as súas exportacións como Detrás das escenas, isto instrue ao Next.js construír a pipeline para: "use client" client-only que que Compila ese ficheiro (e as súas dependencias) nun bundle separado de JavaScript Exclúe ese compoñente de ser executado no servidor Treat it like a classic React CSR component with hydration logic Esta directiva actúa como unha between the two sides of the tree. All components above it can be server-rendered; all components below it must be rendered in the browser. boundary marker 💧 Streaming: Rendering in Pieces, Not All at Once RSC abrazos como unha estratexia de renderización nativa. en lugar de esperar a que se construíse a árbore de React completa antes de enviala ao navegador, o servidor do usuario ao cliente cando estea preparado. streaming streams serialized fragments que que que Compoñentes do servidor son renderizados e enviados o máis axiña posible Lugares (por exemplo, a través de ) para cubrir temporalmente Os compoñentes do cliente hidratan incrementalmente, só cando se cargan Como é posible isto? RSC introduce un concepto chamado hidratación selectiva. Cando un Compoñente do Cliente é renderizado dentro dunha árbore do Compoñente do Servidor, React inserta un detentor de lugar ( ) e desvía a hidratación. Unha vez que o cliente cargou o bundle JS correspondente: que que que que React lazily carga ese compoñente específico Atopa o carpinteiro e séguelle á árbore viva Hidrata-lo en illamento, sen re-render toda a páxina This design is : your app starts fast, and interactivity comes online gradually. decoupled and progressive }> // Server Component // Client Component (hydrated later) Recuperación de datos e división de código en RSC Outra clave “máxica” de RSC: que sen depender de , ou de paso manual. you can fetch data directly inside components with async/await getServerSideProps useEffect // Server Component export default async function Dashboard() { const stats = await getStatsForUser() return } Por que isto é posible? que que que Os compoñentes RSC funcionan como funcións de servidor reais, non como módulos compilados polo cliente Poden acceder a bases de datos, APIs internas, sistemas de ficheiros ou a calquera cousa que soporte o seu tempo de execución do servidor O resultado é renderizado en HTML (non JS) e transmitido ao cliente E tamén: que que que que Non é necesaria hidratación, xa que o resultado é estático Non hai lóxica de UI de carga no propio compoñente - todo se resolve antes de que chegue ao navegador — unless nested inside a client boundary No code for this component is sent to the client Isto reduce significativamente o tamaño da caldeira e do paquete, mantendo a lóxica colocada coa interface de usuario - un obxectivo de longa data de React que finalmente se realizou a escala. Estado, ganchos e consideracións do ciclo de vida RSC Reaccións tradicionais como , ou , because they . . does not support useState useEffect useRef don’t run in the browser Utilización Características Feature Server Component Server Component Compoñentes do cliente Client Component useState ❌ ✅ ✅ useEffect useEffect ✅ ✅ useContext ✅ (se é estático) ✅ (se é estático) ✅ async/await (debería envolverse en efectos) async/await async/await (debería envolverse en efectos) (debería envolverse en efectos) Traballadores de eventos Traballadores de eventos ✅ ✅ Isto impón unha clara separación de responsabilidades: que Compoñentes do servidor: datos e deseño Compoñentes do cliente: interactividade e estado local Os Compoñentes do servidor de React están deseñados para simplificar a túa aplicación. Unha vez que internalizas as regras de límite, o modelo de transmisión e o acceso de datos asínc, podes con moito menos carballo que antes. compose fast, personalized, and minimal-JS apps 4. What’s the Best Practice? Combining RSC, SSR, and SSG 4. What’s the Best Practice? Combining RSC, SSR, and SSG Unha das preguntas máis comúns que enfrontan os enxeñeiros de React en Next.js 15 non é "debe usar RSC?" - é “how do I combine RSC with SSR and SSG in a maintainable, high-performance way?” A beleza de Next.js 15 é que xa non está limitado a unha estratexia de renderización por páxina. , applying the most appropriate approach to each part of the UI. compose rendering strategies at the component level This section introduces a practical framework for making that decision based on actual architectural needs. Comezar coa pregunta principal: que necesita este compoñente? Fai estas catro preguntas para cada compoñente: que que que Does it need to be interactive? ✅ Yes → Use a Client Component Does it need secure, request-specific, or real-time data? ✅ Yes → Consider SSR Pode ser precomputado ou actualizado con pouca frecuencia? ✅ Si → Prefer SSG Recolle datos do servidor pero nunca necesita executarse no cliente? ✅ Si → Use RSC Exemplo: Estratexia de desintegración da páxina de produto Aquí está como unha páxina de produto de comercio electrónico típica podería ser composta usando todas as tres estratexias: AddToCartButton Require interacción e estado local Compoñentes Compoñentes Realización dunha estratexia Rendering Strategy Razóns Reason ProductDetails ProductDetails RSC Tirado de DB, sen interactividade, sen necesidade de hidratar PrezoPersonalización PriceWithPersonalization SSR Depende da sesión do usuario, dinámico por solicitude Depende da sesión do usuario, dinámico por solicitude AddToCartButton Require interacción e estado local AddToCartButton AddToCartButton CSR Require interacción e estado local Require interacción e estado local Produtos relacionados RelatedProducts SSG (with ISR) SSG (with ISR) Seguro para caché durante a construción, pode ser revalidado cada 24 horas ou por tag Safe to cache at build-time, can revalidate every 24h or per tag StockStatusBanner RSC + streaming Frequently changing, streamed in with Suspense to not block TTFB Frequently changing, streamed in with Suspense to not block TTFB Each component is doing Non hai hidratación de páxina completa, non hai captura de datos globais, non hai JavaScript innecesario. just what it needs to do 📐 Design Best Practices for Combining Strategies ✅ 1.- Comezar o servidor primeiro En canto ao número de páxinas web, inclúese o número de páxinas web que inclúen todas as páxinas ( ) only when necessary. This keeps bundles smaller and simplifies testing. "use client" 2.- Manteña os límites claros Use nomes de cartafol ou sufixos de nome de ficheiro para que os límites sexan explícitos: /components /server/ProductDetails.tsx /client/AddToCartButton.tsx /shared/ReviewStars.tsx ✅ 3. abrazar suspensión para entrega progresiva Utilización to stream in non-critical RSCs without blocking the whole page: }> Co-locate lóxica con compoñentes Non divida a captura de datos e a interfaz de usuario entre ficheiros a menos que sexa necesario. lóxica directamente dentro da árbore de compoñentes - o marco coida do resto. async ✅ 5. Use ISR (Incremental Static Regeneration) smartly Para páxinas cacheables con alto tráfico, como artigos de blog ou seccións de marketing, use SSG + revalidación: export const revalidate = 3600 // regenerate every hour 6 erros comúns a evitar que que que ❌ by default — you’ll end up with CSR all over again Using "use client" Recuperación de datos nos compoñentes do cliente cando podería ser recopilado polo servidor ❌ — instead, let client components be focused, isolated, and stateful Passing too much data between RSC and client components via props Recreación de SSR-estilo getServerSideProps lóxica dentro de RSC - non hai necesidade, RSC é servidor-side ✅ Decision Tree Summary Velaquí unha guía simplificada: Is it interactive? │ ├── Yes → Client Component (CSR) │ └── No │ ├── Needs per-request data? → SSR │ ├── Can be pre-rendered? → SSG │ └── Otherwise → RSC Non tes que memorizalo.Unha vez que internalizas como renderizar mapas á responsabilidade, . . the decisions become intuitive A mellor práctica non é sobre escoller "a mellor estratexia de rendemento". It’s about - Con claridade, propósito e rendemento en mente. designing rendering as an intentional part of your component architecture 6. Looking Ahead: Why RSC Is More Than Just a Feature Mirando cara adiante: por que RSC é máis que unha característica Os compoñentes do servidor React non son só unha optimización de rendemento ou unha mellora de DX. . Much like React Hooks in 2019, RSC in 2025 is . . they represent a foundational shift in how we build React applications redefining the baseline for frontend architecture RSC cambia o modelo mental da construción en reacción O desenvolvemento tradicional de React sempre se construíu sobre esta suposición: “The browser owns the runtime. We hydrate everything. Every piece of logic and data must live in the client, or be fetched via API.” RSC breaks that assumption. Con RSC, agora preguntas: que que Podo saltar a hidratación por completo? Pódese executar este compoñente puramente no servidor? Podo colocar a lóxica de backend coa miña UI? It gives us back pero non con castañas e castañas, senón con . . the ability to separate display logic and interactivity cleanly first-class architectural boundaries Xa non é “client-first”. “purpose-first.” Cada parte da súa interfaz de usuario existe onde é máis eficiente: servidor, cliente ou estático. 🌐 Ecosystem Shift Toward Server-First Rendering RSC isn’t happening in isolation. The broader frontend ecosystem is undergoing a . . server-first rendering renaissance Frameworks como: que que que Remix inclínase fortemente na carga de datos do servidor e nas accións de formulario. embraces zero-JS by default, shipping only islands of interactivity. Astro Qwik leva a hidratación ao extremo - adiando todos os JS ata que sexa explícitamente necesario. Next.js 15, con RSC e App Router, agora pon a renderización por compoñente no centro da experiencia do desenvolvedor. Esta non é unha coincidencia, é un reflexo dunha dura verdade que todos sentimos: Sending less JavaScript is the only way to scale interactivity and performance on the modern web. Os compoñentes do servidor React son a resposta nativa de React a ese desafío - profundamente integrados, ergonómicos e listos para a produción. O que esperar a continuación A medida que React 19 e o ecosistema maduran, podemos esperar: que que que que Máis ferramentas de depuración e perfilado granular para árbores RSC Mellor integración de DevTools para mostrar límites e tempos de hidratación Patróns de orde superior a estratexias de rendemento abstracto (por exemplo, , envases) Adopción máis ampla en sistemas de deseño, frameworks e bibliotecas (por exemplo, kits de UI RSC-aware) Gústache a lectura? Se este artigo axudou a pensar doutro xeito sobre React e Next.js Para máis profundidades Follow me on HackerEditar HackerEditar para falar sobre React, arquitectura ou migración RSC Or connect with me on ligazóns ligazóns