js pushstate

[KasselJulian]

Hi,

möchte gerne ein paar Fragen bezüglich JavaScripts Pushstate-Funktion klären.
1.) Die Funktion wird ja z.B. erst am IE10 unterstützt. Welche Alternativen gibt es für ältere Browser um die URL ohne Reload zu manipulieren?
2.) Der zweite Parameter in der Pushstate-Funktion ist der Titel. Auf mozilla.org konnte ich nachlesen, das der Titel vollkommen egal ist und momentan nicht genutzt wird, jedoch ggf. in der Zukunft.
Ich dachte die Funktion von besagtem zweiten Parameter soll es sein den Titel der Seite zu ändern? Bisher habe ich das nämlich nur über document.title erreichen können. Habe ich da was falsch verstanden?

Bin über hilfreiche Antworten dankbar

 

[mindraper]

AW: js pushstate

moin,

dann versuche ich mich mal an einer hilfreichen antwort. oder an zwei

zu 1.)
zunächst einmal würde ich an deiner stelle, sofern vom browser unterstützt, immer die history API (pushState/replaceState in verbindung mit popstate eventlistener) verwenden. probleme die bei der alternativen lösung auftreten können hier vermieden und/oder vermindert werden.

falls dir die history API nicht die nötigen funktionalitäten bietet, gäbe es noch die ältere "alternative", die sich den umstand zu nutze macht, dass ein "hashchange" (ein ändern der URL mit hilfe eines hashbangs/raute) innerhalb der URL-leiste eines browsers nicht dazu führt, dass eine neue seite geladen wird.

der grund dafür, dass das so ist, liegt im wesentlichen darin begründet, dass ein hashchange immer dann (und das ist auch schon seit ziemlich langer zeit so) auftaucht, wenn du beispielsweise einen seitenanker antriggerst – also einen hyperlink, dessen href-attribut auf ein id-attribut eines (anderen) elements auf der gleichen seite verweist, du die eigentliche ressource/seite aber nicht verlassen möchtest. der anker verweist also auf ein sog. "fragment" der gezeigten ressource, das über einen eindeutigen identifizierer (id-attribute dürfen ja nur einmal in einer seite vorkommen) angesteuert werden kann.

beispiel URL ohne hashbang: protokoll://www.eine-page.tld/
beispiel URL inkl. hashbang: protokoll://www.eine-page.tld/#hashbang-an-url

weitere überlegungen beim einsatz von hashbangs:

blogpost von insolani.co.uk

prinzipiell würde ich persönlich mir zweimal den einsatz von hashbangs überlegen – auch, weil der einsatz (gleiches gilt für die history API) eigentlich nur für single-page-apps bzw. RIAs interessant ist. für private seiten beispielsweise kann ich keinen wirklichen zugewinn/mehrwert erkennen.


zu 2.)
hin und wieder hilft es, sich die erklärungen ebenfalls durchzulesen ich vermute mal, du beziehst dich auf diesen artikel?

ich nehme mir die freiheit heraus, den artikel an der relevanten stelle zu zitieren:
"[...] Alternatively, you could pass a short title for the state to which you're moving. [...]"

die angabe des "title"-arguments bezieht sich keinesfalls auf das title-tag, sondern auf den titel des eintrags innerhalb der history. mit anderen worten, die history eines browsers hat – und es wäre auch offensichtlich nicht gut wenn dem so wäre – in keiner weise etwas mit dem auf einer seite enthaltenen html zu tun.


hoffe das hilft

 

[KasselJulian]

AW: js pushstate

Hi,

vielen Dank für deine Antwort Hat Klarheit ins Ungewisse bei Frage 2 gebracht.
Frage 1 ist noch nicht ganz beantwortet. Das mit Hashbang war mir klar, aber darauf setze ich nicht. Ich meinte mit "Alternativen für ältere Browser" eine Möglichkeit, die dem Resultat von pushstate entspricht. Wie es z.B. für CSS3-Selektoren für IE < 10 eine Lösung gibt (eine JavaScript-Library), so könnte es ja auch für pushstate eine Library geben, die die Schnittstelle herstellt!? Die Library hat dann die Aufgabe bei Browsern die normalerweise pushstate nicht unterstützen (z.B. alles unter IE10) es funktionierend zu machen

 

[mindraper]

AW: js pushstate

moin,

nein, es gibt meines wissens nach keine library, die eine schnittstelle für die history API implementiert. streng genommen ist das auch ziemlich unlogisch, weil die history API selbst ja die schnittstelle zum browser ist. es ist nunmal via scripts unmöglich, den browser selbst zu erweitern.

es gibt allerdings ein paar libraries, die die funktionalität der history API imitieren und diese – sofern vorhanden – nutzen. anderenfalls benutzen sie als eingebautes fallback eben doch wieder hashes/hashchange.

falls du nicht vorhast alles via cookies zu lösen (-.-) bleiben auch nicht mehr allzu viele alternativen.

hier eine liste:
https://github.com/Modernizr/Modern...5-history-api-pushstate-replacestate-popstate

 

[KasselJulian]

AW: js pushstate

Hi,
habe mir den Link angeguckt. Laut dem soll die History API für IE6+ verfügbar sein. Auf einer anderen Seite habe ich gelesen dass pushstate jedoch erst ab IE10 funktioniert. Ziemlich verwirrend finde ich. Da ist nochwas was mich verwirrt: Wofür brauche ich denn da eine ganze API? der window.pushstate-Befehl funktioniert in meinem (aktuellen) Firefox auch ohne die Einbindung von history.js. Wozu also?

 

[mindraper]

AW: js pushstate

moin,

ich glaube du hast da was grundsätzlich falsch verstanden. die history API ist im IE 6 definitiv nicht NATIV drinne. der link listet die bereits besagten libraries auf. und diese bieten eine fallback lösung bis einschließlich IE 6.

es gibt da schon einen unterschied zwischen nativ verfügbar und durch eine library emuliert:

nativ = bestandteil des browsers
library = emulierte variante, die (falls nötig) ein fallback nutzt

falls du wissen willst, wo die history API überall nativ imlementiert ist:
http://caniuse.com/#feat=history

zur API frage:
jedes framework/library/toolkit hat eine API. jedes feature das du in einem browser ansprichst ebenfalls (zusammengefasst als die API eines browsers). API ist ein akronym für "Application Programming Interface", zu deutsch: eine programmierschnittstelle.

im bezug auf die history API und JavaScript:

1) window
window ist der oberste einstiegspunkt für JS in die gesamte verfügbare browser API

2) window.history
zugriff auf die history API, eine untermenge der browser API

3) window.history.pushState()
nutzung einer funktionalität (methode) der history API names "pushState"

jetzt klar? oder anders ausgedrückt: mal angenommen, dir stünde keinerlei API zur verfügung, wie könntest du dann den browser ansprechen? eben – nämlich gar nicht.

 

[KasselJulian]

AW: js pushstate

Ok, leuchtet mir ein. Sprich mit Einbindung der history API (die nativ nicht im IE < 10 enthalten) ist pushstate auch in IE6+ verfügbar (Da Fallback vorhanden). Das ist doch super!
Das widerspricht aber nun deinem geposteten Link!?

 

[mindraper]

AW: js pushstate

moin,

Ok, leuchtet mir ein. Sprich mit Einbindung der history API (die nativ nicht im IE < 10 enthalten) ist pushstate auch in IE6+ verfügbar (Da Fallback vorhanden). Das ist doch super!

du hörst mir nicht zu die history API bzw. deren methoden pushState und replaceState ist nicht im IE 6/7/8/9 enthalten und du kannst sie nicht "nachrüsten" oder "verfügbar machen".
mein zuerst geposteter link listet einige libraries auf, die für den IE 6/7/8/9 (und andere browser in denen die history API mit pushState/replaceState nicht nativ vorhanden ist) intern auf hashchange umleiten.

Das widerspricht aber nun deinem geposteten Link!?

nein. der zweite link zeigt eine übersicht der browser, in denen native unterstützung vorhanden ist, mithin keine library benötigt wird.

 

[KasselJulian]

AW: js pushstate

Ok, d.h. die Library ändert bei Einbindung der API und Verwendung im IE6-9 einen Hashbang. Das löst des Rätsels Verwirrung Fallback ist in diesem Fall kein Aufschluss auf die Verwendung dessen.

Könntest du mir noch abschließend eines sagen? Was meinst du mit intern? Ist der Hash "nicht sichtbar"?

 

[mindraper]

AW: js pushstate

moin,

"intern" bezieht sich auf die (weiter-)verarbeitung innerhalb der library selbst. was dachtest du denn, wieso die aus (teils) so viel code bestehen?

 

[KasselJulian]

AW: js pushstate

moin,

"intern" bezieht sich auf die (weiter-)verarbeitung innerhalb der library selbst

Eine Seite die mit Pushstate arbeitet und auf den mit Ajax bereitgestellten Seiten eine URL erwartet wie man sie kennt:

domain.de/verzeichnis/unterverzeichnis
und nicht
domain.de/!#/verzeichnis/unterverzeichnis

kann doch nur dann damit arbeiten, wenn sie explizit prüft ob ein hashtag vorhanden ist. In dem Fall ist es doch für den Programmierer ein Fallback mit Aufwand, nicht einfach nur ein Fallback den die API "intern" löst!?
Denn wenn nicht geprüft wird ob ein Hashtag vorhanden ist und der Programmierer noch dementsprechend einen serverseitigen Fallback einbaut, funktioniert das Script ja nicht mehr.

 

[mindraper]

AW: js pushstate

moin,

entschuldige bitte, aber deine argumentation bewegt sich gerade außerhalb des mir verständlichen. WIESO sollte deine seite (oder auch dein backend) NICHT damit arbeiten können?

grundsätzlich fragst du doch nur eine ressource an. um zu wissen, welche ressource ich anfordere, muss meine seite doch nur erfahren, um welche genau es sich handelt. um bei deinem beispiel zu bleiben:

in beiden fällen (pushState ODER hashbang) fordere ich doch folgendes an:
/verzeichnis/unterverzeichnis

falls gar nichts besseres einfällt:
VOR dem XHR die komplette url durch diese function und regex laufen lassen:

function getRessourceIdentifier (urlIn) {
    return urlIn.replace(/^((http|https)\:\/\/)?([w]{3}\.)?\w+\.\w{2,6}(\/!#)?/, '');
}

sollte dir immer /verzeichnis/unterverzeichnis zurückgeben -> der identifizierer. den via XHR ans backend schicken, warten bis der request zurück kehrt, daten des zurückgekehrten requests laden.

 

[KasselJulian]

AW: js pushstate

Ok, das ist ja das was ich meinte. Du musst als Programmierer dein Script darauf auslegen, dass es beide Methoden versteht (in deinem Fall erklärt mit Regex).
Ich stelle mal in Frage ob die Verwendung beider Möglichkeiten suchmaschinenoptimiert ist. Aber das ist ein anderes Thema.
Jedenfalls ist meine Frage geklärt; es ist nicht intern, sondern der Hashbang ist sichtbar.

Danke!

Cheers