nicht angemeldet
JürgenB
Tabellenkalk
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Matthias Apsel
Matthias Apsel
Matthias Apsel
hi,
nach der Umstellung meiner Seite als Single Page Application sind mir in der Konsole ein paar Requests aufgefallen, die das XHR-Objekt spontan macht. Die Requests zielen auf JS-Dateien mit dem Parameter /spa.js?_=1483478601051 z.B. was wie ein Zeitstempel aussieht. Was hat es damit auf sich?
Schöne Grüße.
nach der Umstellung meiner Seite als Single Page Application
Der einige gefundene Request ist NICHT "spontan" und zeigt auf:
spa_nkfd.js?_=1483488351823 also nicht spa.js?_zeitpunkt
Du musst doch wissen was Du programmiert hast.
nach der Umstellung meiner Seite als Single Page Application
Der einige gefundene Request ist NICHT "spontan" und zeigt auf:
Spontan heißt selbstständig, das XHR-Objekt macht den Request selbstständig.
spa_nkfd.js?_=1483488351823also nichtspa.js?_zeitpunkt
Was für ein Zeitpunkt?
Du musst doch wissen was Du programmiert hast.
Es sind spontane Requests, die hab ich eben nicht programmiert. Deswegen frage ich ja ;)
MfG
Hallo,
Es sind spontane Requests, die hab ich eben nicht programmiert. Deswegen frage ich ja ;)
einen Zugriff auf eine Datei /spa.js?... habe ich nicht beobachtet, und
<script src="/spa_nkfd.js"></script>
sieht nicht nach „spontan“ aus.
Gruß
Jürgen
Hallo,
Es sind spontane Requests, die hab ich eben nicht programmiert. Deswegen frage ich ja ;)
einen Zugriff auf eine Datei /spa.js?... habe ich nicht beobachtet, und
<script src="/spa_nkfd.js"></script>sieht nicht nach „spontan“ aus.
Nochmal: Die hier angesprochenen Requests sehe ich in der Konsole einschließlich eines Parameters _= und Headers die das XHR-Objekt selbstständig feuert. Das heißt: In o.g. JS-Datei sind diese Header und Parameter NICHT programmiert.
Deswegen frage ich ja hier.
Hallo,
Nochmal: Die hier angesprochenen Requests sehe ich in der Konsole einschließlich eines Parameters
_=und Headers die das XHR-Objekt selbstständig feuert. Das heißt: In o.g. JS-Datei sind diese Header und Parameter NICHT programmiert.
ich habe mich gerade noch mal durch deine Seite durchgeklickt, und auf den jeweiligen Seiten auch einen Moment gewartet. Zugriffe auf /gra.js?_=... habe ich nicht gesehen.
Wann treten die Zugriffe denn auf?
Wie lange muss man warten?
Kommen die Zugriffe bei allen Seiten?
Gruß
Jürgen
Hallo,
Nochmal: Die hier angesprochenen Requests sehe ich in der Konsole einschließlich eines Parameters
_=und Headers die das XHR-Objekt selbstständig feuert. Das heißt: In o.g. JS-Datei sind diese Header und Parameter NICHT programmiert.ich habe mich gerade noch mal durch deine Seite durchgeklickt, und auf den jeweiligen Seiten auch einen Moment gewartet. Zugriffe auf /gra.js?_=... habe ich nicht gesehen.
Wann treten die Zugriffe denn auf?
Wie lange muss man warten?
Kommen die Zugriffe bei allen Seiten?
Auf Startseite gehen, Konsole aufmachen, Register Netz und auf den nächsten Link im Menu klicken. Dann sind diese Requests in der Konsole zu sehen. MfG
Hallo,
Auf Startseite gehen, Konsole aufmachen, Register Netz und auf den nächsten Link im Menu klicken. Dann sind diese Requests in der Konsole zu sehen. MfG
in meinem FF unter W7 sehe ich folgendes:
GET http://nkfd.rolfrost.de/ [HTTP/1.1 200 OK 430ms]
GET http://nkfd.rolfrost.de/nv.css [HTTP/1.1 200 OK 0ms]
GET http://nkfd.rolfrost.de/xforum.css [HTTP/1.1 200 OK 0ms]
GET http://nkfd.rolfrost.de/xjs.js [HTTP/1.1 200 OK 0ms]
GET http://nkfd.rolfrost.de/jquery.min.js [HTTP/1.1 200 OK 0ms]
GET http://nkfd.rolfrost.de/request.js [HTTP/1.1 200 OK 0ms]
GET http://nkfd.rolfrost.de/spa_nkfd.js [HTTP/1.1 200 OK 0ms]
GET XHR http://nkfd.rolfrost.de/ [HTTP/1.1 200 OK 150ms]
GET http://nkfd.rolfrost.de/favicon.ico [HTTP/1.1 200 OK 0ms]
GET XHR http://nkfd.rolfrost.de/nkfd.html [HTTP/1.1 200 OK 80ms]
Synchrone XMLHttpRequests am Haupt-Thread sollte nicht mehr verwendet werden, weil es nachteilige Effekte für das Erlebnis der Endbenutzer hat. Für weitere Hilfe siehe http://xhr.spec.whatwg.org/ jquery.min.js:4:17595
GET XHR http://nkfd.rolfrost.de/xjs.js [HTTP/1.1 200 OK 40ms]
GET XHR http://nkfd.rolfrost.de/alib.js [HTTP/1.1 200 OK 50ms]
GET XHR http://nkfd.rolfrost.de/cEAV.js [HTTP/1.1 200 OK 40ms]
GET XHR http://nkfd.rolfrost.de/jquery.min.js [HTTP/1.1 200 OK 90ms]
GET XHR http://nkfd.rolfrost.de/nkfd.html [HTTP/1.1 200 OK 100ms]
GET XHR http://nkfd.rolfrost.de/eu.html [HTTP/1.1 200 OK 90ms]
GET XHR http://nkfd.rolfrost.de/xjs.js [HTTP/1.1 200 OK 40ms]
GET http://nkfd.rolfrost.de/astro/eu.gif [HTTP/1.1 200 OK 0ms]
GET http://nkfd.rolfrost.de/astro/gg.gif [HTTP/1.1 200 OK 0ms]
GET XHR http://nkfd.rolfrost.de/alib.js [HTTP/1.1 200 OK 30ms]
GET XHR http://nkfd.rolfrost.de/cEAV.js [HTTP/1.1 200 OK 50ms]
GET XHR http://nkfd.rolfrost.de/jquery.min.js [HTTP/1.1 200 OK 90ms]
GET XHR http://nkfd.rolfrost.de/eu.html [HTTP/1.1 200 OK 120ms]
Gruß
Jürgen
Hallo JürgenB,
er hat schon recht, diese Requests mit den Parametern finden statt:
in meinem FF unter W7 sehe ich folgendes:
Entwickler-Tools oder Firebug? Falls letzteres: benutze lieber die Entwickler-Tools ;-)
LG,
CK
Hallo Christian,
Entwickler-Tools oder Firebug? Falls letzteres: benutze lieber die Entwickler-Tools ;-)
Entwickler-Tools. Da sehe ich die Parameter nicht, aber die Zugriffe sehe ich schon. Und da war eben nichts mit /spa.js. Oder zeigen die Entwickler-Tools nicht alle Zugriffe?
Gruß
Jürgen
Hallo,
Spontan heißt selbstständig,
merkwürdig, wieso kann ich diese Bedeutung für „spontan“ nicht finden?
Gruß
Kalk
Hallo,
Spontan heißt selbstständig,
merkwürdig, wieso kann ich diese Bedeutung für „spontan“ nicht finden?
Das Internet ist kein Ersatz für einen Deutschlehrer der auch Latein gegeben hat.
MfG
Kann es sein, dass Du den Parameter "_" selbst ("selbst" in dem Sinne: Eines Deiner oder der von verwendeten Skripte) "irgendwo" ranhängst um das Cachen im Browser oder durch Proxys zu verhindern? Das zu sehende wäre nämlich eine typische Methode genau dafür.
Kann es denn wirklich sein, dass Du keine Ahnung davon hast, dass für eine derartige Diagnose ein paar weitere Angaben nötig sind? Vorliegend würde ich sogar jede wirksame Server- bzw. Verzeichniskonfiguration sehen wollen.
Hallo pl,
Was hat es damit auf sich?
jQuery erzeugt solche Parameter um Caches zu umgehen. Siehe auch Dokumentation.
LG,
CK
Hi,
Was hat es damit auf sich?
jQuery erzeugt solche Parameter um Caches zu umgehen. Siehe auch Dokumentation.
Mein Code macht den Request nicht mit jQuery. Ich setze jedoch jQuery ein und es kommt tatsächlich von da und zwar hier: $('body').html(this.response);
Wenn ich das ersetze durch document.querySelector('body').innerHTML = this.response; hört der Spuk auf.
Danke für Deinen Hinweis!
Schöne Grüße ;)
@@pl
Wenn ich das ersetze durch
document.querySelector('body').innerHTML = this.response;hört der Spuk auf.
Und da fängt der Unsinn an. Die Referenz auf body steht bereits mit document.body zur Verfügung. Es ist unsinnig, danach nochmal das DOM abzusuchen.
LLAP 🖖
hi,
Die Referenz auf
bodysteht bereits mitdocument.body
Boahhey''' wir werden immer besser ;)
Danke Dir!!
document.querySelector('body').innerHTML = this.response;
Wow. Das ist aber wohl kaum der Sinn des XHR-Requests, den ganzen Seiteninhalt zu ersetzen. Ebensowenig dürfte es Sinn der Sache sein, in der history die gesamte Seite zu speichern. Anders als Gunnar meint fängt der Unsinn hier, also beim Konzept, an.
document.querySelector('body').innerHTML = this.response;Wow. Das ist aber wohl kaum der Sinn des XHR-Requests, den ganzen Seiteninhalt zu ersetzen.
Nun, ich zeige es Dir ja, dass eine SPA auf diese Art und Weise funktioniert. Meine Idee es so zu machen ist über 10 Jahre alt. Nur kannte ich damals den Begriff SPA noch nicht.
Ebensowenig dürfte es Sinn der Sache sein, in der history die gesamte Seite zu speichern.
Die History ermöglicht dem Benutzer die Navigation Vor/Zurück und auch das funktioniert einwandfrei ;)
PS: Mein Konzept ist, eine Website mit beliebig vielen Unterseiten über eine einzige Einstiegsseite in den SPA-Modus zu schalten. Du kannst diesen Modus jederzeit wieder verlassen indem Du einen beliebigen Link in einem neuen Fenster öffnest.
PS: Mein Konzept ist, eine Website mit beliebig vielen Unterseiten über eine einzige Einstiegsseite in den SPA-Modus zu schalten.
Das ist wie jeden Morgen mit angehängtem Wohnwagen zur Arbeit zu fahren. Es reicht völlig aus, die Inhalte auszutauschen, die sich auch tatsächlich unterscheiden.
PS: Mein Konzept ist, eine Website mit beliebig vielen Unterseiten über eine einzige Einstiegsseite in den SPA-Modus zu schalten.
Das ist wie jeden Morgen mit angehängtem Wohnwagen zur Arbeit zu fahren. Es reicht völlig aus, die Inhalte auszutauschen, die sich auch tatsächlich unterscheiden.
So isses. Es reicht, auf einer beliebigen Einzelseite ein einziges JS einzubinden und schon läuft das ganze FW im SPA Modus ;)
MfG
@@pl
Das ist wie jeden Morgen mit angehängtem Wohnwagen zur Arbeit zu fahren. Es reicht völlig aus, die Inhalte auszutauschen, die sich auch tatsächlich unterscheiden.
So isses. Es reicht, auf einer beliebigen Einzelseite ein einziges JS einzubinden und schon läuft das ganze FW im SPA Modus ;)
Welchen Vorteil genau hätte eine SPA, bei der sämtlicher Inhalt des body ausgetauscht wird, gegenüber ganz normalen HTML-Ressourcen, die auch völlig ohne JavaScript funktionieren?
LLAP 🖖
Hallo Gunnar,
Welchen Vorteil genau hätte eine SPA, bei der sämtlicher Inhalt des
bodyausgetauscht wird, gegenüber ganz normalen HTML-Ressourcen
Der Flash geht weg und es wirkt dadurch schneller. Rails hat dafür Turbolinks eingeführt.
die auch völlig ohne JavaScript funktionieren?
Progressive Enhancement! Dass man so etwas einsetzt heisst nicht, dass es ohne nicht funktioniert.
LG,
CK
@@Christian Kruse
Welchen Vorteil genau hätte eine SPA, bei der sämtlicher Inhalt des
bodyausgetauscht wird, gegenüber ganz normalen HTML-RessourcenDer Flash geht weg und es wirkt dadurch schneller.
Was für ein Flash? Browser arbeiten doch heutzutage so, dass die alte Seite so lange stehenbleibt bis die neue geladen ist und gerendert wird. Da ist kein Flash.
Welchen Vorteil genau hätte eine SPA?
die auch völlig ohne JavaScript funktionieren?
Progressive Enhancement! Dass man so etwas einsetzt heisst nicht, dass es ohne nicht funktioniert.
Ja, das sollte klar sein.
LLAP 🖖
Hallo Gunnar,
Was für ein Flash? Browser arbeiten doch heutzutage so, dass die alte Seite so lange stehenbleibt bis die neue geladen ist und gerendert wird. Da ist kein Flash.
Doch, der ist immer noch da, nur viel kürzer. Selbst im Safari sehe ich sie noch, wenn ich gerad mal wieder unter macOS unterwegs sein muss.
die auch völlig ohne JavaScript funktionieren?
Progressive Enhancement! Dass man so etwas einsetzt heisst nicht, dass es ohne nicht funktioniert.
Ja, das sollte klar sein.
Dann ist dein Argument aber für die Tonne ;-)
LG,
CK
Dann ist dein Argument aber für die Tonne ;-)
Nicht für die Tonne ist, dass bei der vorliegenden Methode des "SPA" völlig sinnlos eine Menge an Daten "errechnet" bzw. "herausgesucht" und übertragen werden.
Hallo ,
Dann ist dein Argument aber für die Tonne ;-)
Nicht für die Tonne ist, dass sinnlos eine Menge an Daten "errechnet" bzw. "herausgesucht" und übertragen werden.
Normalerweise[tm], ohne JS, würde die Seite vollständig vom Server geladen. Mit dem Turbolinks-Ansatz wird nur der body-Inhalt ohne head o.ä. geladen. Es werden also weniger Daten übertragen.
Dass man das noch weiter treiben kann ist offensichtlich, aber das kann man ja immer. Und es ist ein guter Ansatz die Seite ein wenig zu beschleunigen, wenn man Legacy-Code vorliegen hat.
LG,
CK
@@Christian Kruse
Normalerweise[tm], ohne JS, würde die Seite vollständig vom Server geladen. Mit dem Turbolinks-Ansatz wird nur der
body-Inhalt ohneheado.ä. geladen. Es werden also weniger Daten übertragen.
Normalerweise[tm] kann aber jede Seite andere Metainformationen wie description im head zu stehen haben.
LLAP 🖖
Hallo Gunnar Bittersmann,
Normalerweise[tm] kann aber jede Seite andere Metainformationen wie
descriptionimheadzu stehen haben.
Normalerweise™[tm]™ sind die aber nur wichtig, bevor die Seite angezeigt wird.
Bis demnächst
Matthias
@@Matthias Apsel
Normalerweise[tm] kann aber jede Seite andere Metainformationen wie
descriptionimheadzu stehen haben.Normalerweise™[tm]™ sind die aber nur wichtig, bevor die Seite angezeigt wird.
Nein. title ist normalerweise (ohne [tm]™) wichtig, solange die Seite angezeigt wird.
LLAP 🖖
Hallo Gunnar Bittersmann,
Nein.
titleist normalerweise (ohne [tm]™) wichtig, solange die Seite angezeigt wird.
title ja, sonst noch was? Es spricht ja nichts dagegen, die Inhalte mehrerer Elemente per Ajax zu laden. Unter Umständen wird sich der Titel auch aus der Benennung der aktuellen Seite rekonstruieren lassen.
Ich bin schon versucht, dass mal auszuprobieren.
Bis demnächst
Matthias
Hallo Matthias,
Ich bin schon versucht, dass mal auszuprobieren.
Funktioniert insgesamt recht gut, bedenke aber, dass du das ggfls auch im JS beachten musst.
LG,
CK
Hallo ,
Dann ist dein Argument aber für die Tonne ;-)
Nicht für die Tonne ist, dass sinnlos eine Menge an Daten "errechnet" bzw. "herausgesucht" und übertragen werden.
Normalerweise[tm], ohne JS, würde die Seite vollständig vom Server geladen. Mit dem Turbolinks-Ansatz wird nur der
body-Inhalt ohneheado.ä. geladen. Es werden also weniger Daten übertragen.
Mit meinem Ansatz auch: <head> bleibt, nur <body> wird ausgetauscht. Einen gezielten Austausch von <title> und <meta descr> kann ich nachrüsten, muss dafür nur die x-response erweitern.
MfG
@@Christian Kruse
Was für ein Flash? Browser arbeiten doch heutzutage so, dass die alte Seite so lange stehenbleibt bis die neue geladen ist und gerendert wird. Da ist kein Flash.
Doch, der ist immer noch da, nur viel kürzer. Selbst im Safari sehe ich sie noch, wenn ich gerad mal wieder unter macOS unterwegs sein muss.
Bir mir flasht da nichts, weder in Firefox noch in Safari. Auch nicht, wenn ich das MacBook nicht ins WLAN hänge, sondern über 3G im Netz bin. Muss ich dem iPhone noch einen Aluhut überstülpen, um bei EDGE irgendwas flashen zu sehen?
Dann ist dein Argument aber für die Tonne ;-)
Welches Argument? Hab ich eins gebracht? Ich hab doch bloß nachgefragt, welches Argument hier für SPA spräche. Du hast ein Argument gebracht. Welches ich durchaus anerkennen würde, wenn ich es denn nachvollziehen könnte. Kann ich aber nicht.
LLAP 🖖
Hallo Gunnar,
Was für ein Flash? Browser arbeiten doch heutzutage so, dass die alte Seite so lange stehenbleibt bis die neue geladen ist und gerendert wird. Da ist kein Flash.
Doch, der ist immer noch da, nur viel kürzer. Selbst im Safari sehe ich sie noch, wenn ich gerad mal wieder unter macOS unterwegs sein muss.
Bir mir flasht da nichts, weder in Firefox noch in Safari.
Dann hast du langsame Augen. Mir fällt das durchaus auf, und auch sehr unangenehm.
Muss ich dem iPhone noch einen Aluhut überstülpen, um bei EDGE irgendwas flashen zu sehen?
Das hat mit der Netz-Geschwindigkeit wenig zu tun, sondern mit dem rendern. Der alte Inhalt wird gelöscht und der neue wird dargestellt bzw der alte wird vom neuen überschrieben (was davon stimmt weiss ich nicht sicher) - das stellt sich als kurzes flackern dar. Das bleibt aus, wenn man den Turbolinks-Ansatz wählt; insgesamt wirkt dadurch die Seite schneller.
Dann ist dein Argument aber für die Tonne ;-)
Welches Argument? Hab ich eins gebracht?
Du hast mit deinem „die auch völlig ohne JavaScript funktionieren?“ impliziert, dass Seiten mit der Turbolinks-Lösung nicht ohne JS funktionieren.
Du hast ein Argument gebracht.
Nein, kein Argument. Du hast nach einem Vorteil gefragt, ich habe dir einen genannt - dass du das anders siehst sei dir unbenommen, ich hatte nicht vor dich zu überzeugen.
LG,
CK
@@Christian Kruse
Bir mir flasht da nichts, weder in Firefox noch in Safari.
Dann hast du langsame Augen.
Mag sein, ich bin ja nicht mehr der jüngste.
Dann sei aber die Frage gestattet: Welchen Vorteil genau hätte eine SPA für Hotti? ;-)
Vielleicht ist aber auch dein MacBook nicht mehr das jüngste, ergo langsam? ;-)
Mir fällt das durchaus auf, und auch sehr unangenehm.
Hm liegt das daran, dass ich meine Seiten angesehen habe? Also schlankes DOM – rendern in nullkommanichts.
Vielleicht sollte ich mal irgendwelche Bootcrap-Seiten ansehen? Also Seiten, deren Quälcode man nicht ansehen sollte?
Oder liegt das daran, dass du dir Seiten angesehen hast, wo irgendwelches JavaScript das Rendern der Seite blockiert?
Dann ist die bevorzugte Lösung nicht, den body-Inhalt per JavaScript auszutauschen, sondern JavaScript so einzubinden, dass es nicht das Rendern der Seite blockiert.
Du hast mit deinem „die auch völlig ohne JavaScript funktionieren?“ impliziert, dass Seiten mit der Turbolinks-Lösung nicht ohne JS funktionieren.
Nee nee, nicht einmal ohne das „auch“. Mit schon gar nicht. ;-)
Nein, kein Argument. Du hast nach einem Vorteil gefragt, ich habe dir einen genannt - dass du das anders siehst sei dir unbenommen
Ich sehe das nicht anders. Ich sehe den Vorteil gar nicht – im wahrsten Sinne des Wortes.
ich hatte nicht vor dich zu überzeugen.
Kannst du ruhig. Per progressive enhancement die UX zu verbessern fällt bei mir immer auf fruchtbaren Boden.
LLAP 🖖
Hallo Gunnar,
Vielleicht ist aber auch dein MacBook nicht mehr das jüngste, ergo langsam? ;-)
Das ist unabhängig von OS, Browser und Hardware zu bemerken. Ich sehe das bei meiner Desktop-Maschine genau so wie bei meinem lahmarschigen MacBook.
Mir fällt das durchaus auf, und auch sehr unangenehm.
Hm liegt das daran, dass ich meine Seiten angesehen habe? Also schlankes DOM – rendern in nullkommanichts.
Nein, das ist immer bemerkbar, allerdings ist die Ausprägung natürlich unterschiedlich.
Dann ist die bevorzugte Lösung nicht, […]
„Dass man das noch weiter treiben kann ist offensichtlich, aber das kann man ja immer. Und es ist ein guter Ansatz die Seite ein wenig zu beschleunigen, wenn man Legacy-Code vorliegen hat.“ – in https://forum.selfhtml.org/self/2017/jan/3/spontane-requests-xhr/1683691#m1683691.
Du hast mit deinem „die auch völlig ohne JavaScript funktionieren?“ impliziert, dass Seiten mit der Turbolinks-Lösung nicht ohne JS funktionieren.
Nee nee, nicht einmal ohne das „auch“. Mit schon gar nicht. ;-)
Die Wortwahl in dem Kontext lies für mich nur diesen einen Schluss zu. Ein kultureller Unterschied?
ich hatte nicht vor dich zu überzeugen.
Kannst du ruhig.
Möchte ich aber gar nicht.
LG,
CK
hi,
Welchen Vorteil genau hätte eine SPA, bei der sämtlicher Inhalt des
bodyausgetauscht wird, gegenüber ganz normalen HTML-RessourcenDer Flash geht weg und es wirkt dadurch schneller. Rails hat dafür Turbolinks eingeführt.
So isses, die ganze Navigation läuft wesentlich flüssiger im Browser ab. Dabei ist es unerheblich ob der komplette <body> ausgetauscht wird oder nur Teile davon, für den Besucher ist das transparent.
die auch völlig ohne JavaScript funktionieren?
Progressive Enhancement! Dass man so etwas einsetzt heisst nicht, dass es ohne nicht funktioniert.
Genau das war auch eines der Ziele meiner Entwicklung: Sämtliche Links bleiben somit auch den Suchmaschinen erhalten und der Besucher kann den SPA Modus jederzeit verlassen.
MfG
Hallo Gunnar Bittersmann,
Welchen Vorteil genau hätte eine SPA, bei der sämtlicher Inhalt des
bodyausgetauscht wird, gegenüber ganz normalen HTML-Ressourcen, die auch völlig ohne JavaScript funktionieren?
Wenn tatsächlich mit JavaScript nur der Inhalt des main-Elements getauscht wird und die Links in der Navigation angepasst werden, lohnt sich das bestimmt.
Bis demnächst
Matthias
Hallo Matthias Apsel,
Wenn tatsächlich mit JavaScript nur der Inhalt des main-Elements getauscht wird und die Links in der Navigation angepasst werden, lohnt sich das bestimmt.
Und mich stört, dass sie der URI nicht ändert. Und STRG+F5 aktualisiert nicht die aktuelle Seite, sondern die, die ich als erstes aufgerufen habe.
Bis demnächst
Matthias
Hallo Matthias,
Wenn tatsächlich mit JavaScript nur der Inhalt des main-Elements getauscht wird und die Links in der Navigation angepasst werden, lohnt sich das bestimmt.
Und mich stört, dass sie der URI nicht ändert. Und STRG+F5 aktualisiert nicht die aktuelle Seite, sondern die, die ich als erstes aufgerufen habe.
Ja, da ist die Turbolinks-Implementierung sinnvoller. RRs Implementierung ist kaputt.
LG,
CK
Hallo Matthias Apsel,
Wenn tatsächlich mit JavaScript nur der Inhalt des main-Elements getauscht wird und die Links in der Navigation angepasst werden, lohnt sich das bestimmt.
Und mich stört, dass sie der URI nicht ändert. Und STRG+F5 aktualisiert nicht die aktuelle Seite, sondern die, die ich als erstes aufgerufen habe.
Nein. Ein Reload wirkt nur auf die Seite in welcher die SPA läuft. Das kann, muss aber nicht die Seite sein, welche Du als Erste aufgerufen hast. Die Navigation geht vom Browser nahtlos auf JS über, so kannst Du das prüfen.
Die Adresszeile jedoch ist mit JS history.pushState() komplett manipulierbar und zwar völlig unabhängig von Inhalten die im Browser gezeigt werden. Auf meiner Beispielseite übergebe ich jedoch einen auf "/" festgesetzten URI an history.pushState() das kann ich gerne ändern so dass der URI auch in der Adresszeile dem gezeigten Inhalt entspricht.
MfG
Hallo pl,
Wenn tatsächlich mit JavaScript nur der Inhalt des main-Elements getauscht wird und die Links in der Navigation angepasst werden, lohnt sich das bestimmt.
Und mich stört, dass sie der URI nicht ändert. Und STRG+F5 aktualisiert nicht die aktuelle Seite, sondern die, die ich als erstes aufgerufen habe.
Nein.
Ein Reload wirkt nur auf die Seite in welcher die SPA läuft. Das kann, muss aber nicht die Seite sein, welche Du als Erste aufgerufen hast.
Doch, genau das ist das Problem. Dadurch, dass du in deiner Implementation nicht die URL veränderst, wird bei einem Reload die Einstiegsseite geladen.
Die Adresszeile jedoch ist mit JS
history.pushState()komplett manipulierbar und zwar völlig unabhängig von Inhalten die im Browser gezeigt werden. Auf meiner Beispielseite übergebe ich jedoch einen auf "/" festgesetzten URI anhistory.pushState()das kann ich gerne ändern so dass der URI auch in der Adresszeile dem gezeigten Inhalt entspricht.
Siehe Video, das stimmt so nicht. Und jetzt gerade (zwischen Video und Antwort ist einiges an Zeit vergangen) geht es so gar nicht mehr, da wird die vollständige Seite vom Server geladen.
LG,
CK
Nunja, hier läuft jetzt auch die Adresszeile dem Inhalt entsprechend mit. So bringt Dich jetzt ein Reload auf die native Ressource und auch aus dem SPA-Modus raus.
Letzter ist nur noch daran erkennbar, dass sich in der Konsole die Requests akkumulieren und allesamt nur vom XHR-Objekt ausgehen.
Sicher gibts da noch einiges zu optimieren, aber im Prinzip funktioniert das schon so wie ich mir das vorgestellt habe. Z.T. werden auch meine Anwendungen über XHR geschleift ohne den SPA-Modus zu verlassen. Der Link TV im Footer bringt Dich z.B. zu diversen Feeds die weiterhin funktional sind auch wenn Du über die SPA-Einstiegseite kommst. Selbst www-authenticate funktioniert über SPA.
MfG
Hallo pl,
Nunja, hier läuft jetzt auch die Adresszeile dem Inhalt entsprechend mit.
Gut.
So bringt Dich jetzt ein Reload auf die native Ressource
Gut.
und auch aus dem SPA-Modus raus.
Schlecht. Wenn du darin wirklich einen Vorteil siehst, solltest du ihn nicht wegen eines simplen Reloads aufgeben.
Bis demnächst
Matthias
hi,
So bringt Dich jetzt ein Reload auf die native Ressource
Gut.
und auch aus dem SPA-Modus raus.
Schlecht. Wenn du darin wirklich einen Vorteil siehst, solltest du ihn nicht wegen eines simplen Reloads aufgeben.
Was sollte denn Deiner Meinung nach ein Reload sonst machen? Den Benutzer auf die Einstiegseite bringen womit er im SPA-Modus drinbleibt, wolltest Du ja nicht ;)
MfG
Hallo pl,
Was sollte denn Deiner Meinung nach ein Reload sonst machen? Den Benutzer auf die Einstiegseite bringen womit er im SPA-Modus drinbleibt, wolltest Du ja nicht ;)
Die aktuelle Seite neu laden und im SPA-Modus bleiben.
Bis demnächst
Matthias
Hi,
Was hat es damit auf sich?
jQuery erzeugt solche Parameter um Caches zu umgehen. Siehe auch Dokumentation.
In Fakt kümmert sich jQuery darum, dass nachgeladener JS-Code verfügbar wird:
// wenn JS-Code in response nachgeladen werden soll
$(document.body).html( this.response );
// Kein Nachladen
document.body.innerHTML = this.response;
MfG