<ForrigeUke uke="23" år="2025" />

Dette var uka for savn etter korte PR-er og apper i sideleie — og 1106 ting som skjedde i frontendverdenen!

Forstå RSC bedre

Nylig hadde vår alles Dan Abramov skrivesjuke. På fire dager hostet han opp bloggposter om progressiv JSON, kompromisser i datahentingsmønstre, hvordan React Serverkomponenter (RSC) relaterer til LISP og hvorfor RSC integrerer med en bundler. Alt dette for å forstå RSC litt bedre.

Av de fire postene var det den om progressiv JSON jeg likte best. Jeg har hørt mye om streaming, men denne posten ga meg en mer intuitiv forståelse. Men først — hvorfor kom egentlig RSC til verden?

Samlokasjon og effektivitet i datahenting

Hvordan skal vi egentlig gjøre datahenting i React? Det var noe React-teamet undret på gjennom 2010-tallet. I 2025 er RSC en del av svaret på dette spørsmålet, men å lande der var ikke åpenbart.

Den beste datahentingsstrategien er den som tar hånd om både samlokasjon og effektivitet. Samlokasjon — at data hentes der den brukes — gjør koden mer forståelig og vedlikeholdbar. Effektivitet handler om å unngå unødvendige kall og unngå vannfall.

Opp gjennom har vi hatt mange måter å hente data på. Alt fra å sende hele nettsiden ned per forespørsel, til REST-kall ved visse betingelser — og nå en variant hvor data streames inn. Metodene har hver sine fordeler og ulemper, og i denne bloggposten forklarer Abramov alternativene i lys av samlokasjon og effektivitet.

Progressiv JSON

At data gradvis kommer inn på en side er nå greit å forstå, men hvordan skal du egentlig implementere dette? Abramov forklarer streaming med hvordan progressive JPG-er fungerer.

Du har sikkert vært vitne til at når du går inn på en nettside, kan bildet først være kornete, for så å bli skarpere. Dette er en progressiv JPG — bildet får gradvis mer data. Hva om vi overførte samme idé til JSON? Tenk at vi får den viktigste informasjonen først, og resten fylles inn etter hvert:

{
  header: 'Welcome to my blog',
  post: {
    content: 'This is my article',
    comments: [
      'First comment',
      'Second comment'
// (Resten av JSON er ikke med)

Men JSON har noen regler. Du kan ikke bare kutte dataene i to — da mangler du hvert fall en avsluttende krøllparentes, og innholdet blir ugyldig. Men tenk deg at vi har en JSON-parser som kan håndtere ufullstendige data, og fyller inn underveis. Da kan vi vise deler av innholdet før alt er lastet:

{
  header: 'Welcome to my blog',
  post: {
    content: 'This is my article',
    comments: [
      'First comment',
      'Second comment'
      // (Resten av kommentarene mangler)
    ]
  }
  // (Footeren mangler)
}

Dette er selve idéen bak streaming, og det er slik RSC leverer data — som en gradvis fylt datastrøm, i stedet for én stor klump. Men streaming er mer komplisert enn at du bare sender en tilfeldig halvdel av dataene først.

Den naive tilnærmingen er å sende data i rekkefølge, altså fra topp til bunn, som over. Dette ligner på hvordan HTML vanligvis streames: header, så midtdel, så footer. Problemet med dette er at brukeren ikke vet om neste innhold faktisk kommer — eller bare er tregt. Det er også rart å vente på midten hvis footeren allerede er klar.

Hva om vi i stedet sender data i bredden først — altså struktur før innhold? Da lar vi ikke én treg del stoppe alt annet.

Men med data som kommer gradvis — vil ikke innholdet hoppe rundt?

Nei. En viktig del av Reacts løsning er at selv om data kommer gradvis, vil React ikke vise tomme hull der dataen ikke er klar ennå. Den venter ved nærmeste Suspense-grense. Hvis du ikke har definert noen, blir hele siden én stor grense. Men som utvikler kan du plassere Suspense strategisk — og vise en spinner mens innholdet strømmer inn.

Sjekk ut resten av posten for mer om hvordan Suspense, RSC og streaming henger sammen.

Kode er data

RSC innebærer at du både behandler server- og klientkode. For å forstå hvordan dette er mulig, drar Abramov frem programmeringsspråket LISP.

I LISP behandles kode som data. Du kan skrive kode som blir evaluert med engang, eller som kan bli evaluert senere:

(+ 1 2)          // -> 3
'(+ 1 2)         // -> (+ 1 + 2) (quoting)
(eval '(+ 1 2))  // -> 3 (du kan senere evaluere quotet kode)

Denne fnutten foran uttrykket kalles "quoting", og gjør at koden ikke blir evaluert med engang, men kan bli behandlet senere.

På lignende måte kan du i rammeverk som støtter RSC (som Next.js) skrive direktivet "use client" øverst i filen. I praksis blir dette som å "quote" en hel modul:

'use client'
 
export function onClick() {
  alert('Hi.');
}

Det betyr at koden eksisterer som en peker — en referanse til noe som skal kjøres på klienten. En modul fra klienten importeres på serveren, men representeres som en referanse. Serveren bruker koden som data, og klienten evaluerer det når det trengs.

Sjekk ut resten av posten for mer detaljer.

Hvorfor RSC trenger en bundler

At serveren kan motta kode som data, som bare skal evalueres på klientsiden, gjør at RSC krever en bundler.

Vanligvis trenger du ikke en bundler på serversiden, fordi koden kan kjøres direkte fra filsystemet — importene løse ved kjøring, og alle filer er tilgjengelige lokalt.

På klientsiden derimot, trengs en bundler. Uten bundling kan filene bli store, avhengigheter kan lastes i feil rekkefølge, og det kan oppstå mange nettverksforespørsler for å hente alle modulene — noe som gir tregere lastetid og dårligere ytelse.

Med React serverkomponenter blir ting annerledes.

Som vi så i LISP-retorikken, handler RSC ikke bare om å sende data som HTML eller JSON. Det sender også kode som data — det vil si referanser til komponenter som bare skal kjøres på klienten. Når du skriver use client, sier du eksplisitt: "dette er klientkode, ikke kjør det her".

Serveren må da vite:

• Hvilken modul komponenten tilhører
• Hvordan den skal lastes på klienten
• Hvordan den kan kobles tilbake til riktig use client-fil

Alt dette krever et system som forstår prosjektets modulstruktur, vet hva som skal kjøres hvor, og kan produsere referanser til riktig kode. Og det er nettopp det bundleren gjør. Den gjør det mulig å skrive kode for klient og server i én kodebase, selv om de kjører i to ulike miljøer.

Sjekk ut Abramovs post for flere eksempler.

👋 Det var alt for denne gang. Ha en riktig fin uke!