SPA - Statusänderung beim Scrollen?

[Matthias Scharwies]

Servus!

Ich möchte eine Single-page Application in plain Vanilla JS erstellen.

Das Menü wird mit internen Seitenankern realisiert.

Ist es sinnvoll, dass auch beim Scrollen eine Statusänderung des fragment identifiers erzielt wird?

Wie kann man erkennen, welcher State /welche Seite gerade im Viewport sichtbar ist?

Vielen Dank im Voraus!

Herzliche Grüße

Matthias Scharwies

[Matthias Apsel]

Hallo Matthias Scharwies,

Ist es sinnvoll, dass auch beim Scrollen eine Statusänderung des fragment identifiers erzielt wird?

Ich denke ja.

Wie kann man erkennen, welcher State /welche Seite gerade im Viewport sichtbar ist?

https://forum.selfhtml.org/m1675317?

Bis demnächst
Matthias

[Matthias Scharwies]

Servus!

Wie kann man erkennen, welcher State /welche Seite gerade im Viewport sichtbar ist?

https://forum.selfhtml.org/m1675317?

Grad erst ne Woche her - Vielen Dank!

Bis demnächst
Matthias

Herzliche Grüße

Matthias Scharwies

[Winkelmaus Herzogblau]

Wie kann man erkennen, welcher State /welche Seite gerade im Viewport sichtbar ist?

https://forum.selfhtml.org/m1675317?

Das Ereignis visibilitychange wird nur ausgelöst, wenn sich die Sichtbarkeit des gesamten Dokuments ändert, d.h. wenn der Benutzer zwischen den Browser-Tabs wechselt.

Geht um die Sichtbarkeit von Teilen eines einzelnen Dokuments, muss das allem Anschein nach zu Fuß erledigt werden. Für die betreffenden Elemente muss bei scroll- und resize-Ereignissen mit getBoundingClientRect() die Position abgefragt werden; getBoundingClientRect() liefert Koordinaten relativ zum Viewport. Das könnte dann in etwa so aussehen:

function inViewport(e) {
    var r = e.getBoundingClientRect();
    return !(r.bottom < 0 || r.right < 0 || r.left > window.innerWidth || r.top > window.innerHeight);
}

[JürgenB]

Hallo,

Das Ereignis visibilitychange wird nur ausgelöst, wenn sich die Sichtbarkeit des gesamten Dokuments ändert, d.h. wenn der Benutzer zwischen den Browser-Tabs wechselt.

also bezieht sich „content of a tab“ auf den Viewport, das war mir beim Lesen von https://developer.mozilla.org/en-US/docs/Web/Events/visibilitychange nicht ganz klar geworden.

Gruß
Jürgen

[Winkelmaus Herzogblau]

Das Ereignis visibilitychange wird nur ausgelöst, wenn sich die Sichtbarkeit des gesamten Dokuments ändert, d.h. wenn der Benutzer zwischen den Browser-Tabs wechselt.

also bezieht sich „content of a tab“ auf den Viewport, das war mir beim Lesen von https://developer.mozilla.org/en-US/docs/Web/Events/visibilitychange nicht ganz klar geworden.

Der Begriff Viewport ist meines Erachtens fehl am Platze, zumindest verkompliziert er die Sache. Der Inhalt eines Tabs ist erstmal einfach nur das Dokument, wird der Tab nicht angezeigt, wird das Dokument nicht angezeigt.
Der Begriff Viewport bezieht sich dann doch eher auf einen bestimmten Teilbereich des Dokuments, nämlich das Sichtbare vom Ganzen (bei visibilitychange geht's nur ums Ganze).

[dedlfix]

Tach!

Ich möchte eine Single-page Application in plain Vanilla JS erstellen.

Oh je.

Das Menü wird mit internen Seitenankern realisiert.

Ist es sinnvoll, dass auch beim Scrollen eine Statusänderung des fragment identifiers erzielt wird?

Das klingt für mich jetzt nicht unbedingt nach SPA, sondern scheint mir eher nur eine Single Page Website zu sein (ich weiß gar nicht, ob das ein etablierter Begriff ist oder das ganz anders genannt wird). Unter A wie Application verstehe ich jedenfalls sowas, was man auf dem Desktop als Programm geschrieben hätte, das beispielsweise als Ziel hat, irgendwelche Daten zu verwalten, also Datensätze anzuzeigen, zu suchen und zu bearbeiten. Und dann ergibt mein "Oh je" vom Anfang auch mehr Sinn, denn Daten in Eingabefelder zu bringen und von dort zur weiteren Verarbeitung wieder abzuholen, zu validieren und Fehler auszugeben ist etwas, was man ungern zu Fuß macht. Das wird nämlich sehr schnell sehr unübersichtlich - auch dann immer noch, wenn man mit jQuery eine Menge abkürzen kann - und deswegen sind Frameworks wie AngularJS entstanden, mit denen man die einzelnen Teilaufgaben schön separieren kann.

Wie kann man erkennen, welcher State /welche Seite gerade im Viewport sichtbar ist?

Bei SPAs nach meiner Definition tauscht man eher die Ansichten (Views) aus oder öffnet Dialoge, und Scrollen nimmt man nur für lange Listen/Tabellen. Da gäbe es keinen Bedarf, den Anker anhand von Scroll-Positionen zu ändern. Wohl aber ändert sich auch da der Anker oder auch andere Teile der URL, ohne dass die Seite neu geladen werden müsste. Das kann man über die History API erreichen (wenn man nicht gerade den Edge vor sich hat).

dedlfix.

[dedlfix]

Tach!

Wie kann man erkennen, welcher State /welche Seite gerade im Viewport sichtbar ist?

Bootstrap hat dafür seine ScrollSpy-Komponente. Da könnte man zumindest mal spionieren, wie das Erkennen geht.

dedlfix.

[Matthias Scharwies]

Servus!

Das klingt für mich jetzt nicht unbedingt nach SPA, sondern scheint mir eher nur eine Single Page Website zu sein (ich weiß gar nicht, ob das ein etablierter Begriff ist oder das ganz anders genannt wird).

Ja, da hab ich angefangen: eine „Single-Page Webseite“ nur mit CSS zu realisieren. (Der andere Begriff, den ich bei der Lektüre gefunden habe, war „Onepager“.

Unter A wie Application verstehe ich jedenfalls sowas, was man auf dem Desktop als Programm geschrieben hätte, das beispielsweise als Ziel hat, irgendwelche Daten zu verwalten, also Datensätze anzuzeigen, zu suchen und zu bearbeiten.

Ja, da hast du Recht. Das ist das Problem, wenn man nur Demos ohne konkreten und praktischen Anwendungsfall prodzieren will. Oft ergibt dieses Beispiel ohne die Daten dann gar keinen Sinn.

Und dann ergibt mein "Oh je" vom Anfang auch mehr Sinn, denn Daten in Eingabefelder zu bringen und von dort zur weiteren Verarbeitung wieder abzuholen, zu validieren und Fehler auszugeben ist etwas, was man ungern zu Fuß macht. Das wird nämlich sehr schnell sehr unübersichtlich - auch dann immer noch, wenn man mit jQuery eine Menge abkürzen kann - und deswegen sind Frameworks wie AngularJS entstanden, mit denen man die einzelnen Teilaufgaben schön separieren kann.

Da habe ich in der letzten Zeit einige Rants gelesen, in denen vor Over-Engineerung etc gewarnt wurde:

• molily: Progressive enhancement for JavaScript web apps
• shiftedup: Is a Single-Page Application what you really need?
• Danny Markov: Making a Single Page App Without a Framework

Wie kann man erkennen, welcher State /welche Seite gerade im Viewport sichtbar ist?

Bei SPAs nach meiner Definition tauscht man eher die Ansichten (Views) aus oder öffnet Dialoge, und Scrollen nimmt man nur für lange Listen/Tabellen. Da gäbe es keinen Bedarf, den Anker anhand von Scroll-Positionen zu ändern. Wohl aber ändert sich auch da der Anker oder auch andere Teile der URL, ohne dass die Seite neu geladen werden müsste. Das kann man über die History API erreichen (wenn man nicht gerade den Edge vor sich hat).

Vor der Funktion, Statusänderungen zu registrieren und dann die aria-Attribute zu ändern, hätte ich vorher geschaut, ob sich auch durch Scrollen was getan hätte.

Es war nur so eine Idee mein CSS-Beispiel auch in punkto Zugänglichkeit zu erweitern.

Herzliche Grüße

Matthias Scharwies

[dedlfix]

Tach!

Da habe ich in der letzten Zeit einige Rants gelesen, in denen vor Over-Engineerung etc gewarnt wurde:

• shiftedup: Is a Single-Page Application what you really need?

Ich greif da mal nur den einen raus, denn der spricht recht konkret Dinge an, die bei einer SPA problematisch werden: Verlinkungen von extern, SEO, Performance, nicht vorhandener Javascript-Support. Das wären (außer Performance) alles Dinge, die ich für eine SPA nicht bräuchte. Oder anders gesagt, wenn das nicht gegeben ist, dann muss man sich die Frage aus der Überschrift des Artikels stellen. Dann will der Probleminhaber vermutlich eher eine schicke Website als eine Web-Anwendung.

Web-Anwendungen haben für mich dann ihre Berechtigung, wenn es um etwas geht, wofür man früher Programme geschrieben hat, und man sich nun das Ausrollen und Aktuell-Halten der Software sparen will. Vor allem betrifft sowas Intranet-Anwendungen, die als Arbeitspferde fungieren und Hilfsmittel sind, mit denen irgendwelche konreten Aufgaben erledigt werden können, und die nicht nicht nur mehr oder weniger den informativen Charackter einer Mein-Haus-mein-Auto-mein-Boot-Website haben. Solche Anwendungen können aber auch im Internet angesiedelt sein, beispielsweise, wenn es sich um ein Berechnungsprogramm für ein Spiel handelt. Mal angenommen, in dem Spiel geht es darum, eine Gegend zu versorgen und dafür muss man je Einwohner bestimmte Dinge herstellen. Das Programm rechnet nun aus, wieviel Produzenten und Zulieferer man betreiben muss, damit alles rund läuft. Natürlich kann man solche Spiele auch nach Bauchgefühl oder durch Reaktion auf Missstände meistern, aber die Planer haben lieber solche Tools.

Für solche Anwendungen jedenfalls ist es nicht wichtig, dass die Suchmaschinen den Inhalt durchforsten, weil sie ins Intranet nicht reinkommen oder weil der Inhalt der Seiten nicht suchrelevant ist. Es muss lediglich der Rechner als solcher gefunden werden, und dafür gibt es eine statische Seite, die ihn vorstellt und seine Funktionen anpreist. Auch Verlinkungen auf andere Seiten als die Startseite ergeben dann meist keinen gesteigerten Sinn. Wohl aber die Navigation vor und zurück, wenn man sich innerhalb der Anwendung bewegt.

Bleibt noch nicht vorhandener Javascript-Support. Den kann man im Intranet ausschließen, indem eine Systemvoraussetzung definiert und mit dem Arbeitgeber abgestimmt ist. Wenn die Mitarbeiter meinen, Javascript ausschalten zu müssen, dann müssen sie halt sehen, wie sie ihre Aufgaben ohne es erledigt bekommen. Natürlich kann man die Anwendung auch herkömmlich erstellen, so dass lediglich statische Formulare auf dem Client zu sehen sind und alles per Roundtrips zum Server geschickt und dort berechnet wird. Aber warum sollte man das auch für die Teile tun wollen, die der Client problemlos selbst berechnen kann? Da kommt dann auch die Performance-Frage wieder aufs Tapet und Laufzeiten zwischen den Systemen, die vermeidbar sind.

Der Artikel wettert ja auch nicht generell gegen SPAs. Der Autor hat salopp gesagt lediglich erkannt, dass es keine problemlosen eierlegenden Wollmilchsäue gibt und man sich überlegen soll, welches Werkzeug am besten zu welchem Zweck passt.

Nachdem ich jetzt mit meinem Geschreibsel fertig bin, hab ich auch mal die Conclusion des Artikels gelesen und stelle fest, dort steht ja im Wesentlichen das, was ich auch gesagt habe.

dedlfix.

[Matthias Scharwies]

Servus!

Nachdem ich jetzt mit meinem Geschreibsel fertig bin, hab ich auch mal die Conclusion des Artikels gelesen und stelle fest, dort steht ja im Wesentlichen das, was ich auch gesagt habe.

Aufgrund der vielen Kritiken scheinen aber doch viele Leute Angular.js und die anderen Frameworks dazu zu missbrauchen, um Web-Visitenkarten und Ähnliches zu erstellen.

Würdest du bei richtigen SPAs das HTML-Markup schon anfangs in template-Blöcken ausliefern, oder es mit den Daten dann per Ajax holen und dynamisch erzeugen?

Herzliche Grüße

Matthias Scharwies

[dedlfix]

Tach!

Aufgrund der vielen Kritiken scheinen aber doch viele Leute Angular.js und die anderen Frameworks dazu zu missbrauchen, um Web-Visitenkarten und Ähnliches zu erstellen.

Mag sein, aber daran ist ja nicht das Werkzeug schuld, egal wie einfach und verführerisch es ist.

Würdest du bei richtigen SPAs das HTML-Markup schon anfangs in template-Blöcken ausliefern, oder es mit den Daten dann per Ajax holen und dynamisch erzeugen?

Oder. Ich entscheide das situationsabhängig, bevorzuge aber, es bereits in bestehenden Dateien zu haben. Das spart ja auch Requests und Reaktionszeit. Angular 1 nimmt dafür <script type="text/ng-template" id="foo.html">...</script>. Wenn kein Block mit der entsprechenden ID gefunden wird, dann fordert Angular es von sich aus vom Server, wenn die ID referenziert wird. Diesen Weg musste ich an einer Stelle gehen, an der es unpraktikabel war, Templates in andere und zu dem Zeitpunkt bereits geladene Dateien einzufügen.

Zusammen mit den Daten in einem Request das Template auszuliefern kann man machen. Aber wenn die Daten dann mehrfach benötigt werden (zum Beispiel beim Paging), kommt auch das Template mehrfach mit. Oder es muss gesteuert werden, ob man es noch braucht oder nicht mehr. Angular trennt nicht nur diese Requests, auch die Aufgaben werden an verschiedenen Stellen erledigt. Ein Service kümmert sich um die Daten, das Template wird beim Router oder von den Komponenten (vereinfacht: HTML-Code der eine Teilaufgabe erfüllt) referenziert. Man kommt sonst schnell in das Mischen von Zuständigkeiten und erhält Und-Aufgaben: Daten holen und sich um das Template kümmern. Das ergibt Funktionsmonster, die man schlecht testen und warten kann, selbst wenn man die Teilaufgaben in andere Funktionen delegiert. Es ist auch nicht vorgesehen, ein Template selbst zu holen und in Angulars Template-Cache einzufügen.

dedlfix.