Slovník pojmů
Single-page application
SPA udržuje aplikaci v prohlížeči a při navigaci mění její stav. Není automaticky rychlejší ani vhodnější než více stránková aplikace; potřebuje dobře zvládnout URL, chyby, načítání i přístupnost.
Stručná definice
Navigace se mění uvnitř běžící aplikace, ne výměnou celého dokumentu.
SPA při prvním otevření získá základní HTML a JavaScript. Po spuštění klientský router vyhodnocuje URL, načítá data z API a vykresluje odpovídající obrazovku. Při přechodu z objednávek na detail objednávky proto často nevznikne nový document request, ale změní se stav aplikace a DOM v již otevřeném prohlížeči.
Tento model neříká, kde musí vznikat první HTML. SPA může být čistě klientsky vykreslená, serverově předvykreslená nebo hybridní. Rozhodující je hlavně navigace a dlouhodobě běžící klientský stav. Server přitom dál zůstává zdrojem autoritativních dat, autentizace i autorizace.
Jaký problém řeší
Plynulou práci s více propojenými obrazovkami
SPA dává smysl zejména tam, kde uživatel dlouho pracuje v jednom nástroji a často přechází mezi souvisejícími daty.
- administrace e-shopu se seznamem objednávek, detailu, skladem a zákazníky
- interní SaaS, kde uživatel filtruje data, upravuje formuláře a sleduje více panelů
- dashboard s průběžně načítanými přehledy, upozorněními a stavem integrací
- rozhraní nad API, které potřebuje zachovat filtr, rozpracovanou akci a historii prohlížeče
- postupné načítání méně používaných obrazovek, aby se nenačetl všechen kód najednou
Praktický příklad
Administrace s URL pro každý detail objednávky
Uživatel otevře seznam objednávek, nastaví filtr a přejde na detail jedné objednávky. Router změní URL na /objednavky/4821, načte jen potřebná data a přesune focus na nadpis nové obrazovky. Tlačítko Zpět obnoví předchozí filtr nebo alespoň předchozí navigační stav, nikoli náhodnou prázdnou stránku.
Při obnovení URL /objednavky/4821 musí server vrátit aplikaci nebo odpovídající HTML fallback. Klient pak znovu načte aktuální data a na serveru se zkontroluje oprávnění k dané objednávce. Uložený klientský stav nesmí být jediným důkazem, že ji uživatel může číst.
JavaScript
history.pushState({}, '', '/objednavky/4821');
main.replaceChildren(document.createTextNode('Načítám objednávku…'));
const response = await fetch('/api/orders/4821');
if (!response.ok) throw new Error('Detail objednávky nelze načíst.');
const order = await response.json();
main.textContent = `Objednávka ${order.number}`;
Jak funguje
Navigace v SPA od URL po novou obrazovku
Diagram ukazuje základní tok. Konkrétní framework může kroky organizovat jinak, odpovědnost za URL a stav ale zůstává.
- První načtení Prohlížeč získá HTML, CSS a JavaScript. Aplikace se spustí až po načtení potřebného kódu.
- Router přečte URL Rozhodne, zda zobrazit seznam, detail nebo formulář, a zachová možnost otevřít konkrétní adresu přímo.
- Načtení dat a stavů Klient volá API a průběžně zobrazuje načítání, prázdný výsledek, chybu nebo data.
- Vykreslení a focus Aktualizuje DOM, oznámí podstatnou změnu a přesune focus na smysluplné místo, typicky nadpis obsahu.
- Historie a obnova pushState a popstate umožní Zpět/Vpřed. Obnovení hluboké URL musí umět přijmout také server.
Důležité pojmy
Router, stav a odolná navigace
SPA nerozhoduje jen o tom, jak rychle se změní obrazovka, ale také o tom, jak se aplikace chová při návratu, chybě a výpadku skriptu.
Klientský router
Mapuje URL na obrazovku aplikace. Nenahrazuje serverovou routu: server musí umět bezpečně obsloužit přímé otevření a ověřit přístup.
Deep link
Odkaz na konkrétní detail musí fungovat po vložení do e-mailu, otevření v nové kartě i po obnovení stránky.
Lazy loading
Méně používaná část kódu se načte až při přechodu na příslušnou obrazovku. Zkracuje první start, ale přidává další chybové a načítací stavy.
Hydratace
Pokud server dodá HTML a klient na něj naváže interaktivní JavaScript, jde o hydrataci. Není podmínkou každé SPA ani synonymem pro routing.
Stav rozhraní
Filtr, rozpracovaný formulář nebo otevřený panel patří do UI stavu. Objednávka, oprávnění a cena se ověřují proti serveru.
Vztah k podobným pojmům
SPA popisuje navigační model, nikoli automaticky místo vykreslení.
Stejný produkt může kombinovat více technik podle části rozhraní a potřeb uživatele.
- Webová aplikace
- Je širší celek zahrnující frontend, backend, data a infrastrukturu. SPA je pouze jedna možnost, jak její rozhraní organizovat.
- AJAX
- Označuje asynchronní HTTP komunikaci. Může zlepšit běžnou stránku i být součástí SPA, sám o sobě z ní SPA nedělá.
- Client-side rendering
- Určuje, že obsah vzniká hlavně v prohlížeči. SPA jej často používá, ale může mít i serverově vytvořený první obsah.
- Server-side rendering
- Vytváří HTML na serveru. Moderní aplikace mohou SSR využít společně s klientskou navigací.
Výhody a omezení
Plynulá navigace výměnou za složitější klientský stav.
Přínosy
- rychlý přechod mezi často používanými obrazovkami bez výměny celého dokumentu
- možnost zachovat filtr, výběr a rozpracovaný stav při navigaci
- jednotná interakční vrstva nad API a klientskými komponentami
- postupné načítání méně používaných částí aplikace
Rizika a časté chyby
- velký první JavaScript bundle a dlouhé čekání na spuštění
- nefunkční obnovení deep linku bez serverového fallbacku
- ztracený focus nebo neoznámená změna obrazovky pro uživatele čtečky
- představa, že skrytí akce v klientu je autorizace
- použití SPA pro jednoduché stránky, kde přidá více složitosti než užitku
Kdy dává smysl
Při delší souvislé práci v aplikaci, ne jako výchozí nálepka pro každý web.
SPA se hodí pro administraci, pracovní nástroje a dashboardy, kde uživatel přeskakuje mezi daty, ale zůstává v jednom pracovním kontextu. Výhoda se projeví jen tehdy, když aplikace skutečně zvládá načítání, chyby, obnovu URL a přístupnost lépe než plný reload.
Pro obsahový web, jednoduchý katalog nebo několik samostatných formulářů může být přímočařejší serverově vykreslená více stránková aplikace. Volba nemá být reakcí na popularitu frameworku, ale na délku uživatelské cesty, síťové podmínky a schopnost týmu klientský stav testovat.
Na co myslet
Navigaci je potřeba testovat jako skutečnou cestu uživatele.
Kvalitní SPA neskrývá, že něco načítá nebo selhalo, a stále respektuje očekávání běžného prohlížeče.
- testovat přímé otevření, obnovu, Zpět/Vpřed a sdílení každé důležité URL
- pro každou obrazovku mít načítací, prázdný, chybový a úspěšný stav
- při změně obrazovky aktualizovat titulek, focus a případné oznámení pro čtečku
- nechávat serveru autoritu nad daty, autentizací a autorizací konkrétního záznamu
- měřit skutečný čas prvního zobrazení i odezvu navigace na slabším zařízení a síti
Časté otázky
SPA v praxi
Je SPA automaticky rychlejší než klasický web?
Ne. Další navigace může působit rychle, ale první načtení, velikost skriptu a slabší zařízení mohou výsledek zhoršit. Je potřeba měřit konkrétní uživatelskou cestu.
Je SPA totéž co client-side rendering?
Ne. SPA popisuje hlavně navigaci a běžící aplikaci. Obsah může vznikat klientsky, serverově při prvním requestu nebo hybridně.
Může SPA fungovat bez JavaScriptu?
Čistě klientská SPA zpravidla ne v plném rozsahu. Serverový fallback nebo progresivní vylepšení může zachovat důležité cesty, ale je nutné je vědomě navrhnout.
Řeší klientský router oprávnění?
Ne. Může skrýt nebo přesměrovat obrazovku pro pohodlí, ale server musí ověřit oprávnění při každém čtení či změně chráněných dat.
Jak pracuji s architekturou v praxi
Rozhraní volím podle pracovního toku, ne podle nálepky frameworku.
U interních a e-commerce aplikací propojuji UI, API a datové toky tak, aby zůstaly srozumitelné při běžné práci i při chybě nebo výpadku.