History API Client-seitig nutzen
Kommentare

Mike Robinson hat einen interessanten Artikel zur History API verfasst. Lange Zeit konnten Developer nicht auf den State und die History von Browsern Einfluss nehmen. Lediglich das Überprüfen von Einträgen

Mike Robinson hat einen interessanten Artikel zur History API verfasst. Lange Zeit konnten Developer nicht auf den State und die History von Browsern Einfluss nehmen. Lediglich das Überprüfen von Einträgen in der Historie, und den Nutzer vorwärts und zurück navigieren zu lassen, war möglich. Mit HTML5 und der Erweiterung der History API sowie der Verbreitung von dynamischen Webseiten hat sich das grundlegend geändert.

Es ging und geht schon immer um URLs. Sie sind „die Venen des Internets“. Bisher bot die JavaScript History API nur recht rudimentäre Möglichkeiten:

// Check the length of the history stack console.log(history.length); 
// Send the user agent forward console.log(history.forward()); 
// Send the user agent back console.log(history.back()); 
// Send the user agent back (negative) or forward (positive) 
// by a given number of items console.log(history.go(-3));  

Bei dynamischen Ajax-Anwendungen, bei denen nur Teile einer Seite im Browser aktualisiert werden, ist es schwierig, Nutzern eine URL über den aktuellen Application State an die Hand zu geben, die geteilt oder als Lesezeichen gespeichert werden kann. Fragment identifiers wie beispielsweise die für Artikel-Überschriften verwendete id-Attribute, bieten zwar einige Status-Informationen, sind allerdings völlig abhängig von Client-seitigen Scripts. Die Erweiterung der History-API lässt es zu, dass History-Items in den Browser gepusht werden, um native Vor- und Zurück-Aktionen zu steuern. Diese Items können zudem Daten enthalten, die extrahiert werden können, um den Zustand der Seite später wieder herzustellen.

Pages can add state objects between their entry in the session history and the next („forward“) entry. These are then returned to the script when the user (or script) goes back in the history, thus enabling authors to use the „navigation“ metaphor even in one-page applications.

WHATWG

Kopiert oder bookmarked der User eine stateful URL und ruft die URL später auf, kann das Back-End so konfiguriert werden, dass die URL interpretiert und der Nutzer zur entsprechenden Seite bzw. den entsprechenden Zustand der Seite weitergeleitet wird. Dies erfordert selbstverständlich eine entsprechende Server-Konfiguration, damit die URL auch interpretiert werden kann. Die Nutzung von Hash-Bang (#!), die durch Twitter webweit Anklang fand, hat allerdiengs einige Nachteile und sollte eher als unschöner Hack betrachtet werden.

Und wie nehmen wir „ordentlich“ Einfluss auf die Browser History?

Zum Beispiel mit der Methode history.pushState() durch die Definition der Parameter data, title und url (optional). Damit definieren wir einen Zustand der Seite, geben diesem einen Namen und eine speicherbare URL, selbst bei einem Page Reload. Anschließend die Methode der clickHandler-Funktion direkt über der return-Anweisung hinzufügen: that´s it.

function clickHandler(e) { /* Snip... */ // Add an item to the history log history.pushState(data, event.target.textContent, event.target.href); return event.preventDefault(); }  

Mike Robinson ist in seinem Post Pushing and Popping with the History API zudem auf History Events in der Navigation eingegangen. Vielen Dank aus der Community. Einfach empfehlenswert.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -