Lås upp kraften i React: En djupdykning i ReactDOM och server-side rendering

I det enorma ekosystemet kring React fokuserar vi ofta på komponenter, state och hooks. Men magin som förvandlar våra deklarativa komponenter till påtagliga, interaktiva användargränssnitt i en webbläsare sker genom ett avgörande bibliotek: react-dom. Detta paket är den väsentliga bron mellan Reacts abstrakta virtuella DOM och den konkreta Document Object Model (DOM) som användare ser och interagerar med. För utvecklare som bygger applikationer för en global publik är förståelsen för hur man effektivt utnyttjar react-dom nyckeln till att skapa högpresterande, tillgängliga och sökmotorvänliga upplevelser.

Denna omfattande guide tar dig med på en djupdykning i react-dom-biblioteket. Vi kommer att börja med grunderna i client-side rendering, utforska kraftfulla verktyg som portaler och sedan flytta vårt fokus till det omvälvande paradigmet med server-side rendering (SSR) och dess inverkan på prestanda och SEO över hela världen.

Kärnan i client-side rendering (CSR) med ReactDOM

I grunden fungerar React enligt en abstraktionsprincip. Vi beskriver vad UI:t ska se ut för ett givet state, och React hanterar hur. Modellen för client-side rendering (CSR), som är standard för applikationer skapade med verktyg som Create React App, följer en tydlig process:

1. Webbläsaren begär en webbsida och tar emot en minimal HTML-fil med en länk till ett stort JavaScript-paket.
2. Webbläsaren laddar ner och exekverar JavaScript-paketet.
3. React tar över, bygger den virtuella DOM:en i minnet och använder sedan react-dom för att rendera hela applikationen i ett specifikt DOM-element (vanligtvis en <div id="root"></div>).
4. Användaren kan nu se och interagera med applikationen.

Denna process orkestreras av en enda, kraftfull startpunkt i moderna React-applikationer.

Det moderna API:et: `ReactDOM.createRoot()`

Om du har arbetat med React i några år är du kanske bekant med ReactDOM.render(). Men i och med lanseringen av React 18 är det officiella och rekommenderade sättet att initiera en klient-renderad applikation att använda ReactDOM.createRoot().

Varför denna förändring? Det nya root-API:et möjliggör Reacts samtidiga funktioner (concurrent features), vilket låter React förbereda flera versioner av UI:t samtidigt. Detta är grunden för kraftfulla prestandaförbättringar och nya funktioner som transitions. Att använda det äldre ReactDOM.render() kommer att göra att din app inte kan dra nytta av dessa moderna möjligheter.

Så här initierar du en typisk React-applikation:

            
// index.js - Startpunkten för din applikation

import React from 'react';
import ReactDOM from 'react-dom/client';
import App from './App';

// 1. Hitta DOM-elementet där React-appen ska monteras.
const rootElement = document.getElementById('root');

// 2. Skapa en root för det elementet.
const root = ReactDOM.createRoot(rootElement);

// 3. Rendera din huvudsakliga App-komponent i root-elementet.
root.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>
);

            

              
                Copy
              
            
          

Detta enkla, eleganta kodblock är grunden för nästan varje client-side React-applikation. Metoden root.render() kan anropas flera gånger för att uppdatera UI:t; React kommer effektivt att hantera uppdateringarna genom att jämföra det nya virtuella DOM-trädet med det föregående och endast tillämpa de nödvändiga ändringarna på den faktiska DOM:en.

Mer än bara grunderna: Viktiga verktyg i ReactDOM

Även om createRoot är den primära startpunkten, tillhandahåller react-dom flera andra kraftfulla verktyg för att hantera vanliga men knepiga UI-utmaningar.

Bryt dig loss: `createPortal`

Har du någonsin försökt skapa en modal, en tooltip eller en notifierings-popup och stött på problem med CSS stacking context (z-index) eller att innehåll klipps av en förälders overflow: hidden-egenskap? Detta är ett klassiskt UI-problem. Ur ett komponentlogikperspektiv kan en modal ägas av en knapp djupt nere i din komponentträdstruktur. Men visuellt måste den renderas på den översta nivån i DOM:en, ofta som ett direkt barn till <body>, för att undkomma dessa CSS-begränsningar.

Det är precis detta som ReactDOM.createPortal löser. Det låter dig rendera en komponents barn till en annan del av DOM:en, utanför dess förälders DOM-hierarki, samtidigt som den behåller sin position i Reacts komponentträd. Det betyder att eventbubbling fortfarande fungerar som förväntat – ett event som avfyras inifrån portalen kommer att propagera upp till sina förfäder i React-trädet, även om dessa förfäder inte är dess direkta föräldrar i DOM:en.

Exempel: En återanvändbar modalkomponent

            
// Modal.js
import React from 'react';
import ReactDOM from 'react-dom';

// Vi antar att det finns en <div id="modal-root"></div> i din public/index.html
const modalRoot = document.getElementById('modal-root');

const Modal = ({ children }) => {
  const el = document.createElement('div');

  React.useEffect(() => {
    // Vid montering, lägg till elementet i modal-root.
    modalRoot.appendChild(el);

    // Vid avmontering, städa upp genom att ta bort elementet.
    return () => {
      modalRoot.removeChild(el);
    };
  }, [el]);

  // Använd createPortal för att rendera barnen i den separata DOM-noden.
  return ReactDOM.createPortal(children, el);
};

export default Modal;

// App.js
import React, { useState } from 'react';
import Modal from './Modal';

function App() {
  const [showModal, setShowModal] = useState(false);

  return (
    <div>
      <h1>Min App</h1>
      <button onClick={() => setShowModal(true)}>Visa Modal</button>
      {showModal && (
        <Modal>
          <div className="modal-content">
            <h2>Detta är en Portal Modal!</h2>
            <p>Den renderas i '#modal-root', men dess state hanteras av App.js</p>
            <button onClick={() => setShowModal(false)}>Stäng</button>
          </div>
        </Modal>
      )}
    </div>
  );
}

            

              
                Copy
              
            
          

Tvinga fram synkrona uppdateringar: `flushSync`

React är otroligt smart när det gäller prestanda. En av dess viktigaste optimeringar är state batching. När du anropar flera state-uppdateringsfunktioner i en enda händelsehanterare, renderar React inte om omedelbart efter varje. Istället samlar den ihop dem och utför en enda, effektiv om-rendering i slutet. Detta förhindrar onödiga mellanliggande renderingar.

Det finns dock sällsynta undantagsfall där du behöver tvinga React att tillämpa DOM-uppdateringar synkront. Du kan till exempel behöva läsa av ett DOM-elements storlek eller position omedelbart efter en state-ändring som påverkar det. Det är här flushSync kommer in i bilden.

flushSync är en nödutgång. Du sveper in en state-uppdatering i den, och React kommer synkront att exekvera uppdateringen och skicka ändringarna till DOM:en innan någon efterföljande kod körs.

Använd med försiktighet! Överanvändning av flushSync kan motverka prestandafördelarna med batching. Det behövs vanligtvis bara för interoperabilitet med tredjepartsbibliotek eller för komplexa animationer och layoutlogik.

            
import { flushSync } from 'react-dom';

function ListComponent() {
  const [items, setItems] = useState(['A', 'B', 'C']);
  const listRef = React.useRef();

  const handleAddItem = () => {
    // Anta att vi behöver scrolla till botten direkt efter att ha lagt till ett objekt.
    
    flushSync(() => {
      setItems(prev => [...prev, 'D']);
    });
    
    // När denna rad körs är DOM:en uppdaterad. Det nya objektet 'D' är renderat.
    // Vi kan nu pålitligt mäta listans nya höjd och scrolla.
    listRef.current.scrollTop = listRef.current.scrollHeight;
  };

  return (
    <div>
      <ul ref={listRef} style={{ height: '100px', overflow: 'auto' }}>
        {items.map(item => <li key={item}>{item}</li>)}
      </ul>
      <button onClick={handleAddItem}>Lägg till objekt och scrolla</button>
    </div>
  );
}

            

              
                Copy
              
            
          

En notering om det förflutna: `findDOMNode` (föråldrad)

I äldre kodbaser kan du stöta på findDOMNode. Denna funktion användes för att hämta den underliggande webbläsarens DOM-nod från en klasskomponentinstans. Men det anses nu vara föråldrat och avråds starkt.

Den främsta anledningen är att det bryter komponentabstraktionen. En föräldrakomponent bör inte rota i sitt barns implementeringsdetaljer för att hitta en DOM-nod. Detta gör komponenter sköra och svåra att refaktorera. Dessutom, med framväxten av funktionella komponenter och hooks, fungerar findDOMNode inte alls med dem.

Det moderna och korrekta tillvägagångssättet är att använda refs och ref forwarding. En barnkomponent kan explicit exponera en specifik DOM-nod för sin förälder via forwardRef, vilket upprätthåller ett tydligt och explicit kontrakt.

Paradigmskiftet: Server-side rendering (SSR) med ReactDOM

Även om CSR är kraftfullt för att bygga komplexa, interaktiva applikationer, har det två betydande nackdelar, särskilt för en global användarbas:

1. Initial laddningsprestanda: Användaren ser en tom vit skärm tills hela JavaScript-paketet har laddats ner, tolkats och exekverats. På långsammare nätverk eller mindre kraftfulla enheter, vilket är vanligt i många delar av världen, kan detta leda till en frustrerande lång väntetid.
2. Sökmotoroptimering (SEO): Även om sökmotorers crawlers har blivit bättre på att exekvera JavaScript, är de inte perfekta. En server som skickar tillbaka en praktiskt taget tom HTML-fil förlitar sig på att crawlern renderar sidan, vilket kan leda till ofullständig indexering eller lägre ranking jämfört med en sida som serverar färdigformaterat HTML-innehåll från början.

Server-side rendering (SSR) adresserar dessa problem direkt. Med SSR sker den initiala renderingen av din React-applikation på servern. Servern genererar den fullständiga HTML-koden för den begärda sidan och skickar den till webbläsaren. Användaren ser omedelbart innehållet – en enorm vinst för upplevd prestanda och SEO.

Paketet `react-dom/server`

För att utföra denna server-side-magi tillhandahåller React ett separat paket: react-dom/server. Detta paket innehåller de verktyg som behövs för att rendera komponenter i en miljö utan DOM, som en Node.js-server.

De två primära metoderna är:

• renderToString(element): Detta är arbetshästen för SSR. Den tar ett React-element (som din <App />-komponent) och renderar det till en statisk HTML-sträng. Denna sträng inkluderar de speciella `data-reactroot`-attributen som React kommer att använda på klientsidan för en process som kallas hydrering.
• renderToStaticMarkup(element): Denna liknar den föregående, men utelämnar de extra `data-reactroot`-attributen. Den är användbar när du vill generera ren, statisk HTML som inte kommer att hydreras på klienten. Ett utmärkt användningsfall är att generera HTML för e-postmallar.

Den sista pusselbiten: Hydrering

HTML-koden som genereras av servern är bara statisk markup. Den ser rätt ut, men den är inte interaktiv. Knapparna fungerar inte, och det finns inget state på klientsidan. Processen att göra denna statiska HTML interaktiv kallas hydrering.

Efter att webbläsaren har tagit emot den server-renderade HTML-koden, laddar den också ner samma JavaScript-paket som i CSR-fallet. Men istället för att återskapa hela DOM:en från grunden, tar React över den befintliga HTML-koden. Den går igenom det server-renderade DOM-trädet, fäster nödvändiga händelselyssnare (som onClick) och initierar applikationens state. Denna process är sömlös och mycket snabbare än att bygga DOM:en från noll.

För att aktivera hydrering på klienten använder du ReactDOM.hydrateRoot() istället för createRoot().

Ett förenklat exempel på SSR-flöde (med Express.js på servern):

            
// server.js

import express from 'express';
import React from 'react';
import ReactDOMServer from 'react-dom/server';
import App from './src/App';

const app = express();

app.get('/', (req, res) => {
  // 1. Rendera React App-komponenten till en HTML-sträng.
  const appHtml = ReactDOMServer.renderToString(<App />);

  // 2. Injicera den renderade HTML-koden i en mall.
  const html = `
    <!DOCTYPE html>
    <html>
      <head>
        <title>React SSR App</title>
      </head>
      <body>
        <div id="root">${appHtml}</div>
        <script src="/client.js"></script> <!-- Klientsidans JS-paket -->
      </body>
    </html>
  `;

  // 3. Skicka hela HTML-dokumentet till klienten.
  res.send(html);
});

app.listen(3000, () => {
  console.log('Servern lyssnar på port 3000');
});

            

              
                Copy
              
            
          

            
// client.js - Startpunkten på klientsidan

import React from 'react';
import ReactDOM from 'react-dom/client';
import App from './App';

const rootElement = document.getElementById('root');

// 1. Istället för createRoot, använd hydrateRoot.
// React kommer inte att återskapa DOM:en, utan kommer att fästa händelselyssnare
// på den befintliga server-renderade markupen.
ReactDOM.hydrateRoot(
  rootElement,
  <React.StrictMode>
    <App />
  </React.StrictMode>
);

            

              
                Copy
              
            
          

Det är avgörande att komponentträdet som renderas på klienten för hydrering är identiskt med det som renderades på servern. Avvikelser kan leda till hydreringsfel och oförutsägbart beteende.

Att välja rätt strategi: CSR vs. SSR

Beslutet mellan CSR och SSR handlar inte om vilket som är universellt "bättre", utan vilket som är bättre för din specifika applikations behov. Ramverk som Next.js och Remix har gjort SSR mycket mer tillgängligt, men det är fortfarande viktigt att förstå avvägningarna.

När du bör välja client-side rendering (CSR):

• Högt interaktiva dashboards och adminpaneler: För applikationer bakom en inloggningsvägg där SEO är irrelevant och användare har stabila, snabba anslutningar, är enkelheten med CSR ofta att föredra.
• Interna verktyg: När prestandan för den första sidladdningen är mindre kritisk än utvecklingshastighet och enkelhet.
• Proof of Concepts och MVP:er: CSR är vanligtvis snabbare att sätta upp och driftsätta, vilket gör det idealiskt för snabb prototypframtagning.

När du bör välja server-side rendering (SSR):

• Publika innehållswebbplatser: För bloggar, nyhetssajter, marknadsföringssidor och alla webbplatser där upptäckbarhet via sökmotorer är av största vikt.
• E-handelsplattformar: Produktsidor måste laddas snabbt och vara perfekt indexerbara av sökmotorer och sociala mediers crawlers för att driva försäljning.
• Applikationer riktade mot globala målgrupper: När dina användare kan ha långsammare internetanslutningar eller mindre kraftfulla enheter, förbättrar sändningen av förrenderad HTML den initiala användarupplevelsen avsevärt.

Det är också värt att notera förekomsten av hybridmetoder som Static Site Generation (SSG), där sidor förrenderas till HTML vid byggtid, och Incremental Static Regeneration (ISR), som gör det möjligt att uppdatera statiska sidor periodiskt efter driftsättning. Dessa erbjuder prestandafördelarna med SSR med lägre serverkostnader.

Slutsats: Den mångsidiga bron till DOM

Paketet react-dom är mycket mer än ett enkelt renderingsverktyg; det är ett sofistikerat bibliotek som ger utvecklare finkornig kontroll över hur deras React-applikationer interagerar med webbläsaren. Från den grundläggande createRoot för client-side-applikationer till kraftfulla verktyg som createPortal för komplexa UI:n, tillhandahåller det de nödvändiga verktygen för modern webbutveckling.

Viktigast av allt, genom att tillhandahålla en robust mekanism för server-side rendering och hydrering via react-dom/server och hydrateRoot, ger React utvecklare möjlighet att bygga applikationer som inte bara är interaktiva och dynamiska, utan också högpresterande och SEO-vänliga för en mångsidig, global publik. Att förstå dessa renderingsstrategier och välja den rätta för ditt projekt är ett kännetecken för en skicklig React-utvecklare, vilket gör att du kan leverera den bästa möjliga upplevelsen till varje användare, oavsett var de befinner sig eller vilken enhet de använder.