Ich habe eine Frage zum Scrollen: Unter Android gibt es etwas namens RecyclerView Dynamische Listen mit RecyclerView erstellen | Android Developers. Es verwendet Komponenten wieder, anstatt beim Scrollen immer mehr hinzuzufügen. Es scheint, als ob Discourse das nicht tut? Warum ist das so? Wird eine andere Strategie verwendet? Ich hatte die vage Vorstellung, dass das benutzerdefinierte VDOM-Widget-System geschaffen wurde, um dieses Problem (einer ständig wachsenden Liste von DOM-Elementen) zu lösen. Aber ehrlich gesagt verstehe ich immer noch nicht, wie das das Problem löst. 
Vielleicht kann jemand etwas Licht darauf werfen 
3 „Gefällt mir“
Wir laden immer nur 20 Beiträge gleichzeitig, mittels sogenanntem „virtuellem Scrollen“.
4 „Gefällt mir“
Was passiert mit den alten DOM-Elementen? Wenn ich weiter scrolle, werden dem DOM-Baum wahrscheinlich immer mehr Elemente hinzugefügt. Werden sie irgendwann entfernt?
1 „Gefällt mir“
Wir lassen sie herumliegen, wir haben eine „Tarnungs“-Logik, die Elemente durch einen Platzhalter ersetzt, sobald Sie sich sehr weit vom Ansichtsfenster entfernen. Wenn Sie sich dann dem Element nähern, enttarnen wir es durch erneutes Rendern. Die Schwelle für diese Magie ist ziemlich hoch.
4 „Gefällt mir“
@sam Gibt es einen Artikel, den Sie mir verlinken können, der diese Technik mit dem Recycling von Komponenten vergleicht? Ich würde gerne mehr darüber lesen. Wie sind Sie zu dieser Entscheidung gekommen? Ich stelle mir vor, dass A tour of how the Widget (Virtual DOM) code in Discourse works auch damit zusammenhängt.
1 „Gefällt mir“
[quote=„spirobel, Beitrag:5, Thema:211069″]
Gibt es einen Artikel, den Sie mir verlinken können, der diese Technik mit dem Recycling von Komponenten vergleicht?
[/quote]
Ich glaube nicht, dass wir einen Artikel haben, aber ich könnte mich irren. Vielleicht erinnert sich @eviltrout, ob wir einige unserer Entscheidungen bezüglich des Post-Cloaking dokumentiert haben. Bin mir nicht sicher.
2 „Gefällt mir“
Es ist sehr lange her, daher erinnere ich mich leider nicht mehr.
Ich glaube nicht, dass wir jemals Recyclingkomponenten vollständig analysiert haben. Tarnung war ein großer Erfolg und hat unsere damaligen Probleme gelöst.
4 „Gefällt mir“
@eviltrout Ich habe diesen Beitrag gesehen Evil Trout Inc.
Nach Jahren des Wartens auf einen Durchbruch bei der Android- oder Ember-Performance haben wir beschlossen, dass es an der Zeit war, die nukleare Option zu wählen: Wir haben die Ember-Rendering-Engine für unsere gängigste Ansicht durch eine benutzerdefinierte, auf Virtual DOM basierende Engine ersetzt.
Es scheint also, dass das VDOM/Widget-System in Discourse als Reaktion auf die Android-Performance-Probleme entwickelt wurde.
Dieser Commit, der das Cloaking einführt, scheint nach dem VDOM/Widget-System zu erfolgen:
Hängen Cloaking und das VDOM/Widget-System in irgendeiner Weise zusammen? Es scheint, dass beide die Leistung betreffen. Das Wiederverwenden von Komponenten würde die Anzahl der DOM-Elemente erheblich reduzieren, sodass etwas wie das VDOM/Widget-System nicht notwendig wäre, oder?
2 „Gefällt mir“
Wir hatten Cloaking vor dem VDOM, aber es wurde neu implementiert, nachdem wir festgestellt hatten, dass wir es auch dort brauchten.
Das Recycling von Komponenten sollte den Speicherverbrauch reduzieren und die Leistung bei großen Themen verbessern, aber es wird die Rendering-Zeit nicht beschleunigen, was Widgets erheblich tun.
3 „Gefällt mir“
„Man kann gar nicht genug betonen, dass bei allen Performance-Problemen Kompromisse eingegangen werden müssen. Ich denke, Ember macht hier das Richtige und konzentriert sich auf Anwendungen, die gut organisiert sind und mit zunehmender Funktionalität skaliert werden. Für die überwiegende Mehrheit der Ansichten in Ihrer Anwendung wird der Framework-Overhead keine Rolle spielen. Wenn Sie jedoch viele verschachtelte Komponenten mit vielen Bindungen rendern, kann die Situation pathologisch werden.
Obwohl Discourse auf den ersten Blick einfach aussieht, wird jeder Beitrag mit ziemlich vielen Komponenten gerendert. Wir haben viele dynamische Schaltflächen, Links und Effekte, die jedes Mal angewendet werden, wenn ein Beitrag mit über 150 beteiligten Attributen gerendert wird.
Das habe ich im Blogbeitrag von @eviltrout gelesen. Es scheint, dass die Leistung von Ember im Allgemeinen kein Problem darstellt, aber nur im spezifischen Fall von Discourse-Themen, richtig? Discourse-Themen sind eine sehr lange Liste von Komponenten (Beiträge), die viele Komponenten in sich haben (Antwortschaltfläche, Like-Schaltfläche usw.). Dies führt zu einer Verschlechterung der Render-Leistung.
vdom/widgets lindern dieses Problem teilweise, da sie den Renderprozess kostengünstiger machen. Aber irgendwann wird die Menge der DOM-Elemente so groß, dass sie durch Verbergen reduziert werden müssen.
Das Recycling von Komponenten bedeutet, dieses Problem ganz zu vermeiden, indem nur eine feste Anzahl von DOM-Elementen auf dem Bildschirm vorhanden ist, die wiederverwendet werden, wenn der Benutzer durch den Inhalt scrollt.
Bitte korrigieren Sie mich, wenn ich etwas falsch dargestellt habe.
Danke,
Spirobel 
“
2 „Gefällt mir“