Een inleiding tot de HTML5-geschiedenis-API

De geschiedenis is altijd interessant, toch? In oudere versies van HTML hadden we beperkte controle over browsergeschiedenis. We konden heen en weer gaan met de beschikbare methoden, maar dat was het dan

Met de HTML5-geschiedenis-API hebben we meer controle over het spelen met de browsergeschiedenis. We hebben bijvoorbeeld een manier om een ​​item in de geschiedenis toe te voegen of de URL in de adresbalk te wijzigen zonder de pagina te vernieuwen.

Waarom een ​​geschiedenis-API?

In dit artikel leren we waarom de HTML5-geschiedenis-API is ontstaan. Voordat deze API bestond, gebruikten we vaak hash-waarden om de pagina-inhoud te wijzigen, vooral voor zware toepassingen met één pagina, omdat het wijzigen van de URL niet mogelijk was zonder de pagina te vernieuwen. Wanneer u de hash-waarde voor een URL wijzigt, brengt dit bovendien geen wijzigingen aan in de browsergeschiedenis. 

Beide zaken zijn nu echter wel beschikbaar met de HTML5 History API en het maakt het mogelijk zware, single-page applicaties te ontwikkelen zonder hash-waarden te hoeven gebruiken. Het stelt ons ook in staat om applicaties op een SEO-vriendelijke manier te bouwen. Bovendien stelt deze techniek ons ​​in staat om de bandbreedte te verminderen - maar hoe? 

In dit artikel zullen we een enkele pagina-applicatie met deze API ontwikkelen om precies dat te demonstreren. 

Dat betekent dat we alle benodigde bronnen laden bij het laden van de eerste pagina. Vanaf dat moment downloadt de applicatie alleen de vereiste inhoud. Met andere woorden, in plaats van alle resources altijd te laden, worden alleen de vereiste bronnen van een tweede inhoudsverzoek geladen. 

Merk op dat u wat server-side codering moet uitvoeren om slechts gedeeltelijke resources te leveren in plaats van volledige pagina-inhoud.

Browserondersteuning

Op het moment dat dit artikel wordt geschreven, is browserondersteuning voor de HTML5-geschiedenis-API redelijk goed. We kunnen de status hiervan hier bekijken. Deze link geeft u een glimp van ondersteunde browsers, maar het is altijd een goede gewoonte om ondersteuning voor bepaalde functies te detecteren voordat u deze gebruikt. 

Om programmatisch te bepalen of uw browser de API ondersteunt, bekijkt u de volgende regel code:

return !! (window.history && history.pushState);

Bovendien zou ik willen voorstellen dit artikel te nemen om ondersteuning voor verschillende HTML5-functies te detecteren.

Als u Modernizr gebruikt, moet u onderstaande code gebruiken:

if (Modernizr.history) // Ondersteunde geschiedenis-API

Als uw browser geen geschiedenis-API ondersteunt, kunt u de history.js-polyfills gebruiken.

Geschiedenis manipuleren

HTML5 biedt twee nieuwe methoden:

  1. history.pushState () 
  2. history.replaceState ()

Beide stellen ons in staat om respectievelijk geschiedenisstatus toe te voegen en bij te werken. Beide werken op dezelfde manier en verwachten hetzelfde aantal parameters. Naast deze methoden hebben we popstate evenement. We zullen later in dit artikel zien hoe en wanneer dit te gebruiken popstate evenement.

pushState en replaceState beiden verwachten hetzelfde aantal parameters als onder:

  1. staat kan een JSON-string opslaan en beschikbaar zijn voor popstate evenement.
  2. titel is een parameter voor de meeste browsers voorlopig genegeerd, dus beter om in te stellen nul voor vandaag.
  3. url kan elke URL vertegenwoordigen. Het wordt bijgewerkt met het adres van de browser en het maakt niet uit of die URL bestaat of niet. Het belangrijkste is dat het uw webpagina niet opnieuw laadt.

De belangrijkste verschillen tussen deze methoden zijn dat de pushState voegt een nieuw item toe in de geschiedenisstack en replaceState vervangt de huidige waarde van de geschiedenis in plaats van een nieuwe toe te voegen. Als u nog steeds verward bent in beide methoden, laten we dan dezelfde case met een beter voorbeeld demonstreren.

Laten we aannemen dat we stapels van twee blokken met het label 1 en 2 hebben en blok 3 in je hand hebben. Nu, wanneer we optreden pushState, blok 3 wordt toegevoegd aan een bestaande stapel, zodat de stapel 3 blokken heeft. 

Ga nu uit van dezelfde stapel met twee blokken en nog een in je hand. Wanneer we optreden replaceState, het kiest het blok 2 uit de stapel en plaatst blok 3. Het aantal historiewaarden blijft hetzelfde. pushState, Aan de andere kant verhoogt de geschiedenis met één. 

De onderstaande afbeelding toont dezelfde demonstratie.


Tot nu toe hebben we de pushState en replaceState gebeurtenissen om de browsergeschiedenis te beheren, maar stel dat we een aantal nep-geschiedenis hebben die we in de browser hebben opgeteld. De gebruiker kan wel of niet doorverwezen naar die pagina. In een dergelijk geval zal het een probleem zijn wanneer de gebruiker op de knop heen en weer van de browser raakt om naar geschiedenispagina's te navigeren.

Hoewel je mag verwachten popstate om ontslagen te worden wanneer het pushState of replaceState methoden worden aangepakt, maar in werkelijkheid is dit niet het geval. In plaats daarvan, popstate wordt geactiveerd wanneer u door het item van de sessiegeschiedenis navigeert, door op de knoppen Vorige of Volgende te drukken of door de history.go of history.back methoden.

In WebKit-browsers zou een popstate-gebeurtenis worden geactiveerd na de onload-gebeurtenis van het document, maar Firefox en IE hebben dit gedrag niet.

De demonstratie

De HTML

  • Huis
  • Wat betreft
  • Contact
Klik op Links hierboven om het gebruik van de geschiedenis-API te bekijken pushState methode.

Huis!

Lorem Ipsum is gewoon dummy tekst van de drukkerij- en zetbranche.

JavaScript

Demo 1: HTML5 History API - pushState

In deze demo ervaart u dat geschiedenisitems worden geteld in de browser en u kunt er doorheen varen met behulp van de terug / vooruitknop van de browser. Demo bekijken

Demo 2: HTML5 History API - replaceState

In deze demo ervaart u dat geschiedenisitems worden bijgewerkt in de browsers en dat u er niet doorheen kunt navigeren met de terug / vooruitknop van de browser. Demo bekijken

Conclusie

Deze API heeft een grote impact op de manier waarop onze webtoepassing werkt. Het heeft de afhankelijkheid van hash-waarden in URL's verwijderd om het gemakkelijk te maken om een ​​efficiënte, SEO-vriendelijke toepassing met één pagina te maken. 

Het is echt een leuke API, is het niet?