Sieht super aus, David! Eine kleine Anregung – wäre es möglich, die Ladeleiste weiterlaufen zu lassen (vielleicht etwas langsamer), anstatt sie in der Mitte kurz anzuhalten, obwohl noch auf eine Antwort gewartet wird? Sie könnte vielleicht von 40 % bis 70 % langsamer laufen und dann erst pausieren, falls keine Antwort eintrifft?
Wenn man diese kurze Pause ausblendet, wirkt es meiner Meinung nach reaktionsschneller und unmittelbarer 
Derzeit scheint es 5 Sekunden lang langsamer zu laufen, bevor es bei 80 % Breite stoppt.
Hier habe ich eine sehr, sehr langsame Internetverbindung simuliert:
Aktuelles SCSS:
.loading-indicator-container {
--loading-duration: 5s;
--loading-function: cubic-bezier(0, 0, 0, 1);
--done-duration: 0.4s;
--done-function: ease;
--fade-out-duration: 0.4s;
position: fixed;
top: 0;
left: 0;
z-index: 1001;
height: 3px;
width: 100%;
opacity: 0;
transition: opacity var(--fade-out-duration) ease var(--done-duration);
background-color: var(--primary-low);
}
.loading-indicator-container .loading-indicator {
height: 100%;
width: 100%;
width: 0%;
background-color: var(--tertiary);
}
.loading-indicator-container.loading {
opacity: 1;
transition: opacity 0s;
}
.loading-indicator-container.loading .loading-indicator {
transition: width var(--loading-duration) var(--loading-function);
width: 80%;
}
.loading-indicator-container.done .loading-indicator {
transition: width var(--done-duration) var(--done-function);
width: 100%;
}
body.discourse-hub-webview .loading-indicator-container {
top: 1px;
}
body.footer-nav-ipad .loading-indicator-container {
top: 49px;
}
body.loading #main-outlet {
opacity: 0.2;
transition: opacity 0.2s ease;
}
Hmm, bei mir bleibt es bei etwa 40 % stehen, aber eine sich bewegende Leiste – auch wenn sie langsamer ist – wäre meiner Meinung nach besser als ein Stillstand.
Außerdem, in Bezug auf den Fade-Effekt: Vielleicht würde es schneller wirken, wenn der Inhalt ausgeblendet und der neue Inhalt eingeblendet wird (falls es möglich ist, das Ziel für die Lade-Route zu adressieren)?
Es passieren zwei Dinge…
@Canapin hat recht, dass die initiale Animation nach 5 Sekunden bei 80 % endet… also bleibt sie bei einer langsamen Verbindung dort hängen und wird erst abgeschlossen, wenn du auf der nächsten Seite bist.
Der Fall von @P16 ist das, was ich bei einer schnelleren Verbindung erlebe… sobald der Übergang von der aktuellen Seite stattfindet, wird die Animation kurz an der Stelle angehalten, an der sie gerade war… und setzt eine Sekunde später auf der neuen Seite fort (hier wurde die Balkenhöhe übertrieben dargestellt, damit sie sichtbar ist).
Ich stimme zu, dass es ideal wäre, eine gewisse Bewegung aufrechtzuerhalten, aber das ist möglicherweise nicht ohne eine komplette Änderung der Implementierung möglich…
Ich glaube nicht, dass das Einblenden viel hilft… du kannst den Inhalt nicht einblenden, bevor du ihn hast, also verzögerst du sein Erscheinen dadurch leicht. Es ist zwar möglich, dass es einen Geschwindigkeitsillusion erzeugt, aber technisch gesehen ist es um die Dauer der Einblendanimation langsamer!
Mir ist gerade aufgefallen, dass man den Einblende-Effekt (gewissermaßen) mit der Komponente für das Inhaltsverzeichnis testen kann (da sie den Beitrag einblendet), zum Beispiel… besuchen: PostgreSQL 13 update. Ich finde nicht, dass es sich besonders schneller anfühlt… aber es ist definitiv “weicher”.
Oooh, ich denke, das liegt daran, dass der Inhalt tatsächlich geladen wurde und es zu einem erheblichen Hänger beim Parsen von HTML, der Kaskadierung von Stilen, dem Layout und dem Rendern kommt, während dessen die Animation nicht weiterlaufen kann.
.loading-indicator-container .loading-indicator, .loading-indicator-container {
background-color:#FFCC00;
}
Ich habe versucht, die Farbe im CSS des Themes zu ändern, aber sie bleibt blau. Kann mir jemand helfen?
Ja, genau. Die Single-Thread-Natur des JS-/DOM-Renderns bedeutet, dass wir beim Rendern eines Themas viele Frames verlieren 
. Der Slider bewegt sich die ganze Zeit, es werden nur die Frames nicht gerendert.
Danke. Ich habe das gerade im Core bereinigt, sodass es hier auf Meta sehr bald behoben sein wird.
Ich werde heute auf Meta einen Fade-In-Effekt einrichten, damit wir sehen können, wie er sich anfühlt. Natürlich möchten wir, wenn wir das tun, andere Fade-Ins wie die TOC-Komponente entfernen.
Edit: Das ist erledigt. Fade-In auf Meta aktiviert.
Je nachdem, in welcher Reihenfolge Ihre Themes/Komponenten geladen werden, funktioniert das möglicherweise nicht. Sie müssen den Selektor „spezifischer“ machen als das CSS des Lade-Slider-Komponenten. Am einfachsten ist es wahrscheinlich, !important zur background-color hinzuzufügen. Sie sollten auch den Container-Selektor entfernen, da sonst der Hintergrund derselbe wie der Vordergrund ist:
.loading-indicator-container .loading-indicator {
background-color:#FFCC00 !important;
}
Danke, David, sieht großartig aus!
Es wird nun der Durchschnitt der letzten 5 Seitenaufrufe berechnet und damit die Geschwindigkeit der Leiste festgelegt.
Hallo David,
der Loader wird immer besser Weiter so!
Mit diesem neuen Update wirkt er dynamischer
Mir ist gerade etwas im Zusammenhang mit Kategorien aufgefallen. Ich verwende die Schaltfläche „Thema erstellen“ zum Umbenennen. 
Mit dem Loading Slider wird der Text der Schaltfläche nicht aktualisiert. Mir ist das nur deshalb aufgefallen, weil es Probleme mit anderen Skripten verursachen könnte.
Demo (in diesem Video klicke ich auf eine Kategorie, die einen anderen Text für „Thema erstellen“ hat, und wechsle dann zu einer anderen Kategorie mit der Standard-Schaltfläche „Thema erstellen“.) Nachdem ich die gesamte Seite neu geladen habe, wird der korrekte Text angezeigt.
Das Ein- und Ausblenden ist eine Verbesserung. Aber ich finde den Schieberegler immer noch ablenkend. Ich schaue mir ihn an, was bedeutet, dass ich langsamer bin, um bereit zu sein, die Seite zu lesen, wenn sie lädt. Beim Ladekreis war er an einer Stelle und daher leicht zu ignorieren, und die Plötzlichkeit lässt mich an Geschwindigkeit denken (vielleicht zu Unrecht).
Es könnte sein, dass bei langsamen Verbindungen der Schieberegler besser ist, da man ein Gefühl dafür bekommt, wie langsam oder schnell die Seite lädt. Darüber bin ich mir nicht sicher.
Bei mir befindet sich der Schieberegler auf dem Handy oben am Bildschirm, während der alte etwa 30 % von oben in der Bildschirmmitte liegt…
Statt den Blick auf die Mitte des Telefons zu richten, müssen die Augen nun auf und ab wandern, auf und ab… nur meine zwei Cent…
Ich stimme dem zu. Ich denke, es wäre am besten, wenn der Lade-Slider nur auf dem Desktop funktioniert und auf mobilen Geräten vielleicht der Spinner beibehalten wird. Der Spinner fühlt sich eher wie die Nutzung einer App an, was auf mobilen Geräten gut ist. Genau so wie YouTube die Loader verwendet.
Ja, ich habe es auf einem iPhone verwendet, daher bezogen sich meine Kommentare wirklich auf Mobilgeräte.
Die Idee ist großartig. Ich bin ein großer Fan von Slidern statt Spinner.
Ich habe es auf vielen Themes (Dark, Alien, Vincent, Star Wars usw.) sowohl auf 27-Zoll- als auch auf 34-Zoll-ROG-Monitoren aktiviert und getestet. Den Lade-Slider konnte man kaum sehen. Er scheint sehr dünn zu sein. Bei „dunklen
Ich möchte nur anmerken, dass mir das neue UX-Verhalten beim Auswählen von Kategorien, Themen usw. nicht so gefällt, bei dem die aktuelle Ansicht ausgeblendet wird, bevor die neue Seite lädt. Ich finde, der alte Ansatz mit einer leeren Seite und einem Ladesymbol war ein viel angenehmeres Erlebnis.
In beiden Fällen ändert sich die Seite zweimal. Aber da Ladesymbole universelle Elemente sind, fühlte es sich nicht wirklich so an, als würde sich die Seite zweimal ändern. Es fühlte sich an, als würde sie sich auf eine Änderung vorbereiten und dann einmal ändern. Jetzt fühlt es sich so an, als würde sie sich zweimal ändern, weil nach beiden Übergängen noch Inhalt vorhanden ist – einmal ausgeblendet und einmal mit dem neuen Seiteninhalt. Es ist schwer genau zu benennen, warum es mir nicht gefällt, aber ich denke, es liegt daran, dass es keine universelle Ladeansicht mehr gibt. Jetzt gibt es effektiv unendlich viele verschiedene Ladeansichten, und ich finde die „Ausblenden-dann-Laden“-Ansicht ablenkend, da der Hintergrundinhalt bei jedem Wechsel zu einer neuen Seite anders ist.
Einige Dinge, die didInsertElement-Hooks verwenden, müssen aktualisiert werden, ja. Beim alten Spinner wurden alle Elemente auf der Seite zerstört und neu erstellt. Mit diesem neuen System wird Ember Elemente, wenn möglich, wiederverwenden. Das könnte das Rendern zwar etwas beschleunigen, könnte aber auch Bugs verursachen, wenn Anpassungen nicht den üblichen Ember-Mustern folgen. Wir müssen diese Probleme, sobald wir sie bemerken, gemeinsam angehen und bereinigen.
Hast du den Code für deine Anpassungen in einem Git-Repository, das du teilen könntest?
Das ist der Hauptgrund, warum ich dies noch eine Weile als Theme-Komponente ausprobieren möchte – so können wir so viele Probleme wie möglich finden, bevor wir es in den Kern integrieren.
Klar, hier ist das Repository. Danke
Ich denke, es gibt einen mobilen Bug (zumindest auf dem iPhone) bei diesem neuen Feature. Wenn du im Navigationsmenü „Neueste
Danke @Don – ich habe das mal ausprobiert und denke, das ist eine bessere Methode, die mit dem neuen Slider funktionieren sollte: https://github.com/VaperinaDEV/category-btn-name/pull/1 (entschuldige, falls ich etwas Ungarisch falsch übersetzt habe). Dieses Muster könnte auch für andere nützlich sein, die ihre Komponenten aktualisieren müssen (unter Verwendung von berechneten Eigenschaften statt didInsertElement und JQuery).
habe ich mir notiert, um das zu untersuchen, danke