Routing op basis van hash versus pad

Hashgebaseerde routers luisteren naar de gebeurtenis hashchange, die wordt geactiveerd telkens wanneer location.hash verandert. In combinatie met het lezen van window.location.hash is dit de volledige API die nodig is voor routering aan de clientzijde — de History API komt er niet aan te pas.

URL's zien er bijvoorbeeld zo uit: https://example.com/about — ze zijn niet te onderscheiden van door de server weergegeven URL's. pushState uit de History API wijzigt het pad zonder opnieuw te laden; popstate wordt geactiveerd bij achteruit- en vooruitnavigatie; het onderscheppen van kliks maakt van <a> SPA-navigatie.

Bij padgebaseerde routering moet de server de index.html van de SPA teruggeven voor elk pad dat een gebruiker rechtstreeks kan invoeren of vernieuwen. Anders geeft het vernieuwen van /about een 404. Configureer dit als volgt: probeer het bestand, en gebruik anders index.html, bijvoorbeeld met geschiedenis-terugval in Nginx of vite-plugin-history-api in Vite voor ontwikkeling.

Zoekmachines en veel hulpmiddelen kunnen hashfragmenten helemaal niet crawlen — inhoud op /#/about is onzichtbaar voor oude crawlers. Google verwerkt dit via headless rendering, maar andere crawlers mogelijk niet. Padgebaseerde URL's worden normaal gecrawld en zijn daardoor zonder meer beter voor SEO.

Hash-URL's zien er zichtbaar "vreemd" uit — gebruikers zien de # en vertrouwen de link mogelijk niet of vergeten de volledige URL te kopiëren. Pad-URL's zien eruit als elke andere web-URL, precies zoals gebruikers verwachten. Moderne SPA's kiezen daarom bijna altijd voor padgebaseerde routering.

Hashgebaseerd: ongeveer 10 regels JavaScript, met een hashchange-listener en weergave. Padgebaseerd: aanroepen van pushState, een popstate-listener, het onderscheppen van kliks op links en terugval aan de serverzijde. Hashes zijn de lichtste mogelijke keuze; paden vereisen meer infrastructuur voor een betere gebruikerservaring.

Volledig statische hosts, zoals de standaardconfiguratie van GitHub Pages, kunnen geen terugval aan de serverzijde uitvoeren. Daardoor breekt padgebaseerde routering bij vernieuwen. Mogelijke oplossingen zijn omleidingen via trucs met 404.html, hosten op Netlify of Vercel, die SPA-terugval begrijpen, of hashgebaseerde routering accepteren voor projecten die uitsluitend op een statische host staan.

Sommige apps combineren beide: padgebaseerd voor de hoofdroute en hashes voor secties binnen een pagina, zoals modale vensters en tabbladankers. De gebeurtenis hashchange wordt hiervoor nog steeds geactiveerd en vormt een aanvulling op de router op basis van History voor status van subpagina's, zonder de hoofd-URL te vervuilen.

Om van hashes naar paden te migreren, herschrijf je alle interne links, voeg je terugval aan de serverzijde toe, vervang je de hashchange-logica door popstate en stuur je oude hash-URL's door naar de overeenkomstige pad-URL's met een klein opstartscript dat eenmaal wordt uitgevoerd en history.replaceState aanroept.

Kies hashgebaseerd voor statische hosts zonder herschrijvingen, interne beheertools waarbij SEO niet belangrijk is en ingesloten widgets. Kies padgebaseerd voor alles wat gebruikers zien, alles wat in zoekmachines moet worden geïndexeerd en alles wat je op sociale media deelt — en dat geldt voor de meeste apps.

Hashgebaseerde routering, met URL's zoals /#/about, heeft geen serverconfiguratie nodig, maar heeft zwakke SEO en gebruikt lelijke URL's. Padgebaseerde routering, met URL's zoals /about, heeft terugval naar index.html op de server nodig, maar levert duidelijke, SEO-vriendelijke URL's op die gemakkelijk te delen zijn. Moderne SPA's voor het publiek gebruiken padgebaseerde routering; projecten op een statische host of interne projecten kiezen soms nog voor hashes vanwege de eenvoud.