Aloha ;) > > Eine weitere kleine Performance-Verbesserung kann man vielleicht erreichen, > > Wieso, ist Dein System zu langsam? Ich betreibe das hier (bekanntermaßen) auf Museumstechnik und die kommt überhaupt nicht ins Schwitzen davon. Das zeigt die Erfahrung - mit dem, was momentan in deinem Code steht, crasht die Performance vielleicht noch nicht. Mit dem was am Ende drinstehen würde geht die Performance aber baden - weil das System so wie es ist schlecht skaliert falls du nicht entsprechende Schalter einbaust. Die Schalter sind aber nicht die optionale Performance-Steigerung sondern die Grundvoraussetzung dafür, dass man auf das scroll-Event angemessen (lies: ohne Nutzer mit schwachen Geräten eine schlechte UX zu bieten) reagieren kann. > > indem man eine fixe Boolean-Variable `window.hasScrolled` verwendet statt des classList.contains-Aufruf, aber ich denke das ist performancetechnisch verschmerzbar. > > > > Unter diesem Umstand kann man den Code hier vielleicht so verwenden, ohne große Performance-Bauchschmerzen zu bekommen. > > Von einer globalen Variable `window.hasScrolled` würde ich nun wieder abraten. Deshalb hab ich das auch nur erwähnt, nicht umgesetzt 😉 > Die sollte schön geschützt werden! Wer weiß, was sonst noch alles in die Seite kommen soll. "Immer brav kapseln" habe ich im SelfHTML-Forum gelernt. Aber da warst Du vermutlich noch nicht dabei ;-) Nein - aber die Lektion hatte ich trotzdem „damals schon“ gelernt. Die Kapselung ändert aber an der Funktionsweise nicht Elementar viel. Abgesehen davon: Auch einfache Kapselung (`window.myVars.hasScrolled`) ist kein Persilschein. Ich halte aber die Benennung `window.hasScrolled` für ausreichend sicher - man kann wohl davon ausgehen, dass ein Skript, das zufällig eine gleich benannte Variable verwendet durch die Semantik der Variablenbenennung mit hoher Wahrscheinlichkeit genau das selbe mit dieser Variable tut. Das ist jetzt was anderes als würde ich `window.i` oder `window.temp` oder `window.elm` verwenden wollen. Aber unterm Strich hast du natürlich Recht: Nichts *davon* bietet absolute Sicherheit. > Und die Sache mit den Closures hat Christian ja neulich nochmal ausführlich erklärt. Richtig. Man hätte hier auch darauf verzichten können, die Funktion als `window.checkScroll` zu definieren. Mir ging es hier vor allem darum, Lukas die Funktionsweise zu erklären. Da hab ich die Bedenken mit Kapselung für die Verständlichkeit über Bord geworfen. Falls du Closures (genauer: IIFE) verwenden willst hier ein Vorschlag, der alle Aspekte mit einbezieht: ~~~js (function () { var hasScrolled = false; var checkScroll = function() { if(window.pageYOffset > 0) { if (hasScrolled) { return true; } else { hasScrolled = true; document.body.classList.add("fixed-header-on"); } } else if (hasScrolled) { hasScrolled = false; document.body.classList.remove("fixed-header-on"); } } window.addEventListener("scroll",checkScroll); window.addEventListener("load",checkScroll); // Falls mit Anker gesprungen wurde! })(); ~~~ Grüße, RIDER -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller # [Twitter](https://twitter.com/Camping_RIDER) # [Steam](http://steamcommunity.com/id/Camping_RIDER) # [YouTube](https://www.youtube.com/user/RidersFlame) # [Self-Wiki](http://wiki.selfhtml.org/wiki/Benutzer:Camping_RIDER) # [Selfcode](http://community.de.selfhtml.org/fanprojekte/selfcode.htm): sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[

Aloha ;) > > Eine weitere kleine Performance-Verbesserung kann man vielleicht erreichen, > > Wieso, ist Dein System zu langsam? Ich betreibe das hier (bekanntermaßen) auf Museumstechnik und die kommt überhaupt nicht ins Schwitzen davon. Das zeigt die Erfahrung - mit dem, was momentan in deinem Code steht, crasht die Performance vielleicht noch nicht. Mit dem was am Ende drinstehen würde geht die Performance aber baden - weil das System so wie es ist schlecht skaliert falls du nicht entsprechende Schalter einbaust. Die Schalter sind aber nicht die optionale Performance-Steigerung sondern die Grundvoraussetzung dafür, dass man auf das scroll-Event reagieren kann. > > indem man eine fixe Boolean-Variable `window.hasScrolled` verwendet statt des classList.contains-Aufruf, aber ich denke das ist performancetechnisch verschmerzbar. > > > > Unter diesem Umstand kann man den Code hier vielleicht so verwenden, ohne große Performance-Bauchschmerzen zu bekommen. > > Von einer globalen Variable `window.hasScrolled` würde ich nun wieder abraten. Deshalb hab ich das auch nur erwähnt, nicht umgesetzt 😉 > Die sollte schön geschützt werden! Wer weiß, was sonst noch alles in die Seite kommen soll. "Immer brav kapseln" habe ich im SelfHTML-Forum gelernt. Aber da warst Du vermutlich noch nicht dabei ;-) Nein - aber die Lektion hatte ich trotzdem „damals schon“ gelernt. Die Kapselung ändert aber an der Funktionsweise nicht Elementar viel. Abgesehen davon: Auch einfache Kapselung (`window.myVars.hasScrolled`) ist kein Persilschein. Ich halte aber die Benennung `window.hasScrolled` für ausreichend sicher - man kann wohl davon ausgehen, dass ein Skript, das zufällig eine gleich benannte Variable verwendet durch die Semantik der Variablenbenennung mit hoher Wahrscheinlichkeit genau das selbe mit dieser Variable tut. Das ist jetzt was anderes als würde ich `window.i` oder `window.temp` oder `window.elm` verwenden wollen. Aber unterm Strich hast du natürlich Recht: Nichts *davon* bietet absolute Sicherheit. > Und die Sache mit den Closures hat Christian ja neulich nochmal ausführlich erklärt. Richtig. Man hätte hier auch darauf verzichten können, die Funktion als `window.checkScroll` zu definieren. Mir ging es hier vor allem darum, Lukas die Funktionsweise zu erklären. Da hab ich die Bedenken mit Kapselung für die Verständlichkeit über Bord geworfen. Falls du Closures (genauer: IIFE) verwenden willst hier ein Vorschlag, der alle Aspekte mit einbezieht: ~~~js (function () { var hasScrolled = false; var checkScroll = function() { if(window.pageYOffset > 0) { if (hasScrolled) { return true; } else { hasScrolled = true; document.body.classList.add("fixed-header-on"); } } else if (hasScrolled) { hasScrolled = false; document.body.classList.remove("fixed-header-on"); } } window.addEventListener("scroll",checkScroll); window.addEventListener("load",checkScroll); // Falls mit Anker gesprungen wurde! })(); ~~~ Grüße, RIDER -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller # [Twitter](https://twitter.com/Camping_RIDER) # [Steam](http://steamcommunity.com/id/Camping_RIDER) # [YouTube](https://www.youtube.com/user/RidersFlame) # [Self-Wiki](http://wiki.selfhtml.org/wiki/Benutzer:Camping_RIDER) # [Selfcode](http://community.de.selfhtml.org/fanprojekte/selfcode.htm): sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[

Aloha ;) > > Eine weitere kleine Performance-Verbesserung kann man vielleicht erreichen, > > Wieso, ist Dein System zu langsam? Ich betreibe das hier (bekanntermaßen) auf Museumstechnik und die kommt überhaupt nicht ins Schwitzen davon. Das zeigt die Erfahrung - mit dem, was momentan in deinem Code steht, crasht die Performance vielleicht noch nicht. Mit dem was am Ende drinstehen würde geht die Performance aber baden - weil das System so wie es ist schlecht skaliert falls du nicht entsprechende Schalter einbaust. Die Schalter sind aber nicht die optionale Performance-Steigerung sondern die Grundvoraussetzung dafür, dass man auf das scroll-Event reagieren kann. > > indem man eine fixe Boolean-Variable `window.hasScrolled` verwendet statt des classList.contains-Aufruf, aber ich denke das ist performancetechnisch verschmerzbar. > > > > Unter diesem Umstand kann man den Code hier vielleicht so verwenden, ohne große Performance-Bauchschmerzen zu bekommen. > > Von einer globalen Variable `window.hasScrolled` würde ich nun wieder abraten. Deshalb hab ich das auch nur erwähnt, nicht umgesetzt 😉 > Die sollte schön geschützt werden! Wer weiß, was sonst noch alles in die Seite kommen soll. "Immer brav kapseln" habe ich im SelfHTML-Forum gelernt. Aber da warst Du vermutlich noch nicht dabei ;-) Nein - aber die Lektion hatte ich trotzdem „damals schon“ gelernt. Die Kapselung ändert aber an der Funktionsweise nicht Elementar viel. Abgesehen davon: Auch einfache Kapselung (`window.myVars.hasScrolled`) ist kein Persilschein. Ich halte aber die Benennung `window.hasScrolled` für ausreichend sicher - man kann wohl davon ausgehen, dass ein Skript, das zufällig eine gleich benannte Variable verwendet durch die Semantik der Variablenbenennung mit hoher Wahrscheinlichkeit genau das selbe mit dieser Variable tut. Das ist jetzt was anderes als würde ich `window.i` oder `window.temp` oder `window.elm` verwenden wollen. Aber unterm Strich hast du natürlich Recht: Nichts *davon* bietet absolute Sicherheit. > Und die Sache mit den Closures hat Christian ja neulich nochmal ausführlich erklärt. Richtig. Man hätte hier auch darauf verzichten können, die Funktion als `window.checkScroll` zu definieren. Mir ging es hier vor allem darum, Lukas die Funktionsweise zu erklären. Da hab ich die Bedenken mit Kapselung für die Verständlichkeit über Bord geworfen. Falls du Closures (genauer: IIFE) verwenden willst hier ein Vorschlag, der alle Aspekte mit einbezieht: ~~~js (function () { var hasScrolled = false; var checkScroll = function() { if(window.pageYOffset > 0) { if (hasScrolled) { return true; } else { hasScrolled = true; document.body.classList.add("fixed-header-on"); } } else if (hasScrolled) { hasScrolled = false; document.body.classList.remove("fixed-header-on"); } } window.addEventListener("scroll",checkScroll); window.addEventListener("load",checkScroll); // Falls mit Anker gesprungen wurde! })(); ~~~ Grüße, RIDER -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller # [Twitter](https://twitter.com/Camping_RIDER) # [Steam](http://steamcommunity.com/id/Camping_RIDER) # [YouTube](https://www.youtube.com/user/RidersFlame) # [Self-Wiki](http://wiki.selfhtml.org/wiki/Benutzer:Camping_RIDER) # [Selfcode](http://community.de.selfhtml.org/fanprojekte/selfcode.htm): sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[