Navigáció, interaktivitás és kliensoldali állapot

Célok

A lecke végére el tudod dönteni, melyik állapot való az URL-be, melyik marad a memóriában és melyik a szerveren, és meg tudod indokolni, miért nem lehet a kliensoldali állapotot hivatalos igazságnak tekinteni.

Miért kell az állapotot rendezni?

Egy webalkalmazás nemcsak oldalakat jelenít meg: a felhasználó útját és a felület pillanatnyi állapotát is kezeli. Ha ezeket nem választjuk szét, furcsa hibák jönnek: a Vissza gomb váratlan helyre visz, a frissítés eltünteti a keresést, a megosztott link mást mutat a címzettnek. Az állapot háromféle helyen élhet, és mindegyiknek más a tulajdonsága.

A hallgató keres, kiválaszt, visszalép

A hallgató a kurzuslistában rákeres a „web” szóra, kiválaszt egy kurzust, majd a Vissza gombbal visszatérne a szűrt listához. Ha a program csak a képernyőn látható elemeket cseréli, de az URL-t és az előzményeket figyelmen kívül hagyja, a Vissza gomb váratlan helyre vihet. Ha a frissítéskor elveszik a keresés, a hallgató munkája szakad meg. Ezek nem grafikai hibák, hanem navigációs és állapotkezelési döntések.

flowchart LR
    L[Szűrt lista] --> K[Kurzus részletei]
    K -->|Vissza| L
    L -->|megosztható URL| M[Másik böngésző]

Három hely az állapotnak

Hely	Mi tartozik ide?	Tulajdonság
URL	A kiválasztott kurzus azonosítója, a keresőkifejezés, a lapszám	Megosztható, könyvjelzőzhető, túléli a frissítést
Memória (a futó kliensprogram)	A nyitott súgópanel, a kijelölt fül, a folyamatban lévő betöltés	Gyors, de frissítéskor elvész
Szerver	A tényleges férőhelyszám, a beadott jelentkezés	Hivatalos, több kliens számára közös

Az URL az állapot megosztható és újranyitható része. Egy kurzus azonosítója természetesen szerepelhet az útvonalban (/kurzusok/webprog), egy keresési kifejezés vagy szűrő a lekérdezésben (?q=web). Így a hallgató kimásolhatja a címet, frissíthet, és később visszatérhet ugyanarra a nézetre. Nem minden felületi részlet való az URL-be: egy éppen nyitott, lényegtelen súgópanel állapota maradhat helyi programállapot.

Helyi és szerveroldali állapot

A kliens pillanatnyi állapota például a keresőmező értéke vagy a folyamatban lévő betöltés. A szerveroldali állapot a kurzus tényleges férőhelyszáma vagy egy beadott jelentkezés. A kliens megjeleníthet másolatot vagy becslést a szerver adatairól, de nem tekintheti azt hivatalos igazságnak: a „9 szabad hely” kijelzés a lekérés pillanatának másolata, mire a hallgató rákattint, már lehet nulla. Jelentkezéskor a szervernek újra kell döntenie a saját szabályai szerint (5.5, 2.4: 409).

flowchart TD
    F[Felület pillanatnyi állapota] --> U[URL-ben megosztható rész]
    F --> M[Memóriában kezelt rész]
    S[Szerver állapota] -->|API-válasz| F
    F -->|műveleti kérés| S

Ha az állapotot nem kell elveszíteni, a böngésző tárolhat adatot (3.6, helyi tárolás), de ez nem jelenti azt, hogy minden felületi állapotot az IndexedDB-be kell írni. A tárolás helyét a frissesség, a megoszthatóság és az elvesztés következménye szabja meg.

Interakció és hozzáférhetőség

Egy kliensoldali nézetváltás ne csak vizuálisan történjen meg. A felhasználónak értenie kell, melyik nézetbe jutott, mi töltődik, és mi történt hiba esetén. A natív hivatkozások és gombok jelentése itt is fontos (3.2). Ha a JavaScript a tartalmat frissíti, a billentyűzetes fókusz és a követhetőség is feladat; ennek gyakorlatát a 9. fejezet részletezi.

Végigvezetett példa: a Kurzuspont keresője

Állapot	Hova kerül?	Indok
A kereső kifejezése (web)	URL: /kurzusok?q=web	Megosztható, a Vissza és a frissítés működik.
A kiválasztott kurzus	URL: /kurzusok/webprog	Mély link, könyvjelző.
A „Részletek” panel nyitva van	Memória	Lényegtelen, frissítéskor elveszhet.
A „Jelentkezem” gomb állapota (küldés alatt)	Memória	Rövid életű.
A férőhelyszám	Szerver (a kliens másolatot mutat)	Hivatalos adat, több kliens osztozik rajta.
A beadott jelentkezés	Szerver	A hivatalos rekord.

Ha a hallgató elküldi a linket egy barátjának, a címzett ugyanazt a szűrt listát látja (URL-ből), de a saját jelentkezéseit nem (szerverről, bejelentkezéssel, 7. fejezet).

Gyakori tévhitek

Állítás	Pontosítás
„A látható nézet elég, az URL mellékes.”	Megosztás, frissítés és előzmények miatt az URL az állapot része.
„A kliensoldali állapot azonos a szerver hivatalos adatával.”	A kliens másolatot vagy felületi állapotot kezel.
„A History API automatikusan kirajzolja az oldalt.”	Az alkalmazásnak kell az URL-hez tartozó nézetet felépítenie.
„Minden állapotot IndexedDB-be kell menteni.”	Az állapot megőrzési és megosztási igénye eltérő.

Röviden

• Az állapot három helyen élhet: URL-ben (megosztható), memóriában (gyors, de törlődik), szerveren (hivatalos).
• A kereső kifejezése és a kiválasztott elem az URL-be való; a lényegtelen felületi részlet a memóriába.
• A kliens a szerver adatának másolatát mutatja; a döntést a szerver hozza.
• A History API az URL és az előzmények kezelését segíti, de a nézetet az alkalmazásnak kell felépítenie.

Ellenőrző kérdések

1. Mi kerüljön az URL-be a kurzuskeresőben, és mi ne?
2. Miért nem hivatalos adat a böngészőben megjelenített „9 szabad hely”?
3. Mi történik, ha egy SPA nem kezeli a popstate eseményt?
4. Melyik állapot veszik el frissítéskor, és melyik marad?

Tanulási források

• History API (MDN) — az előzmények kezelése, angolul.