Kliensoldali renderelés

Célok

A lecke végére el tudod magyarázni, mit jelent a kliensoldali renderelés (CSR), meg tudod mondani, mit lát a böngésző, a keresőrobot és a curl a szerver válaszában, és tudod, miért kell külön megtervezni a betöltési, üres és hibás állapotot.

Miért építi a böngésző a felületet?

Ha a nézet minden változásához új HTML-t kellene kérni a szervertől, a felület lassúnak és darabosnak érződne. Ha viszont a szerver adatot ad, a böngészőben futó program pedig ebből építi a nézetet, a változás gyors és folyamatos lehet, és ugyanazt az API-t más kliens is használhatja (5. fejezet). A kliensoldali renderelés (CSR, Client-Side Rendering) azt jelenti, hogy a felület jelentős részét a böngészőben futó JavaScript állítja össze. A szerver HTML-vázat, programot és adatot adhat, és a kliens ezekből építi fel az aktuális DOM-ot (3.2).

A kurzuslista összeáll a böngészőben

A Kurzuspont CSR-változata egy kis HTML-vázat és egy szkriptet küld. A szkript lekéri a kurzusokat az API-ból, és felépíti a listát. Az alábbi a szerver tényleges válasza (curl kimenet egy kipróbáló szerverről):

$ curl localhost:8084/csr
<!doctype html><html lang="hu"><head><meta charset="utf-8"><title>Kurzuspont</title></head>
<body><h1>Kurzusok</h1><div id="lista">Betöltés...</div><script>
fetch("/api/kurzusok").then(r => r.json()).then(adat => {
  document.querySelector("#lista").innerHTML =
    "<ul>" + adat.map(x => "<li>" + x.cim + "</li>").join("") + "</ul>";
});
</script></body></html>

(A válasz egy sorban érkezik; a könnyebb olvashatóság kedvéért tördeltük.)

A válasz nem tartalmaz egyetlen kurzust sem, csak a „Betöltés...” szöveget és a programot. A lista a böngészőben jön létre: a szkript lefut, az /api/kurzusok kérésre megérkezik a JSON, és a program beírja a DOM-ba.

flowchart LR
    H[HTML-váz] --> B[Böngésző]
    J[JavaScript] --> B
    A[API-adat] --> B
    B --> D[DOM és látható felület]

Az ábra nem azt állítja, hogy CSR-nél a szerver nem küld HTML-t. A kiinduló váz is HTML. A döntő kérdés az, hol készül el a fő tartalmi nézet.

(Ezt a kódot böngészőben nem futtattuk, mert a document és a fetch-eredmény megjelenítése böngészőt igényel; a szervervalasz viszont tényleges kimenet. Az egyszerűség kedvéért a példa a cim mezőt közvetlenül HTML-be írja: valódi alkalmazásban az idegen eredetű szöveget nem szabad így beilleszteni, lásd a 8. fejezetben az XSS-t.)

A betöltési lánc következményei

A böngészőnek előbb le kell töltenie és futtatnia a programot, és ha a tartalomhoz API-adat kell, annak válaszára is várnia kell. Az első használható képernyő idejét így a HTML mellett a JavaScript mérete, futása és az adatlekérés is befolyásolja:

sequenceDiagram
    participant B as Böngésző
    participant S as Szerver
    B->>S: GET /csr
    S-->>B: HTML-váz + szkript
    Note over B: A felhasználó "Betöltés..." szöveget lát
    B->>S: GET /api/kurzusok
    S-->>B: JSON
    Note over B: A szkript felépíti a listát

Ha az API lassú vagy nem érhető el, a felhasználó a „Betöltés...” szövegnél marad. Gyenge eszközön a program feldolgozása különösen számíthat. Ezért nem elég a hálózati kérések számát nézni: a böngészőben végzett munka is a felhasználói élmény része.

Betöltési, üres és hibás állapot

A CSR-ben a felületnek legalább négy állapota van, és mindegyiket meg kell tervezni:

Állapot	Mit lát a felhasználó?
Betöltés	Visszajelzés, hogy az adat úton van (nem végtelen forgó jelzés)
Siker	A lista
Üres	„Nincs találat a szűrésre”: ez nem hiba
Hiba	Magyarázat és újrapróbálási lehetőség

Az „üres eredmény” nem azonos az „adatkérés sikertelen” állapottal; a kettőt a felhasználónak meg kell tudnia különböztetni.

Interakció és újrarajzolás

A kliensprogram gyorsan reagálhat helyi változásokra (szűrés, panel nyitása). Ha a változáshoz szerveradat kell, új HTTP-kérést indít. A DOM módosítása után a böngésző stílust és elrendezést is újraszámolhat (3.3). A felhasználó által érzett sebesség tehát a program tervezésétől, a hálózattól és a rendereléstől együtt függ.

Az alkalmazás adatmodellje és a megjelenő DOM nem azonos: a lista adatai lehetnek a memóriában, miközben a képernyőn csak a szűrt részük látszik. Ha az adat frissül, a programnak össze kell hangolnia a belső állapotot és a felületet (6.5).

Mit lát a „nem böngésző”?

Egy keresőrobot, egy hivatkozás-előnézet készítő vagy a curl a fenti válaszban csak a „Betöltés...” szöveget látja, ha nem futtatja a szkriptet. Egyes keresők futtatják a JavaScriptet, de ez további költséget és bizonytalanságot jelent (lásd a kereshetőség kérdését a 9. fejezetben). A fontos, nyilvános tartalmat ezért gyakran már a szerver válaszában érdemes elhelyezni, ami a következő lecke témája.

Kapcsolat az SPA-val

Végigvezetett példa: a Kurzuspont szűrője

A jelentkezési felület kurzuslistáján a hallgató szűr. A CSR változatban:

1. Az oldal betölt, a lista kezdetben „Betöltés...”.
2. A szkript lekéri az összes kurzust, és felépíti a listát.
3. Gépeléskor a szkript a már letöltött adatból szűr, hálózati kérés nélkül.
4. A „jelentkezem” gomb viszont új kérést küld, mert a szabad helyet a szervernek kell eldöntenie.

A szűrés gyors, mert helyi, de a jelentkezéshez mindig a szerver a végső bíró.

Gyakori tévhitek

Állítás	Pontosítás
„CSR esetén nincs szerver.”	A szerver HTML-vázat, programot és API-adatot ad.
„A JavaScript letöltése után az oldal kész.”	Futtatás, adatlekérés és renderelés még hátra lehet.
„A kliensoldali váltás mindig hálózatmentes.”	Friss adathoz új API-kérés kellhet.
„CSR = SPA.”	A renderelés helye és a navigációs modell két külön tengely.
„A keresők mindig látják a JavaScript által épített tartalmat.”	Nem garantált; a nyers válasz csak a vázat tartalmazza.

Röviden

• CSR: a fő nézet a böngészőben, JavaScripttel áll elő; a szerver váza gyakran szinte üres.
• Az első használható képernyő a programtól és az adatlekéréstől is függ.
• A betöltés, siker, üres és hiba állapotát külön meg kell tervezni.
• A nem böngésző kliensek (robot, curl) a nyers választ látják.
• A CSR és az SPA nem azonos.

Ellenőrző kérdések

1. Mit tartalmaz a /csr válasza a kurzusokról?
2. Miért lehet lassabb az első használható képernyő CSR-nél?
3. Miért nem azonos az „üres lista” és a „hiba”?
4. Mi a különbség a CSR és az SPA között?

Tanulási források

• Rendering on the Web (web.dev) — a CSR előnyei és költségei angolul.
• Document Object Model (MDN) — mit módosít a kliensprogram.