J’ai une question concernant le défilement : sur Android, il existe quelque chose appelé recyclerview Créez des listes dynamiques avec RecyclerView | Android Developers Il réutilise des composants au lieu d’en ajouter de plus en plus lors du défilement. Il semble que Discourse ne fasse pas cela ? Pourquoi ? Y a-t-il une stratégie différente utilisée ? J’ai eu l’impression vague que le système de widgets vdom personnalisé a été créé pour résoudre ce problème (d’une liste d’éléments DOM en croissance constante). Mais pour être honnête, je ne comprends toujours pas comment cela résout le problème. 
Peut-être que quelqu’un peut éclairer ce point 
3 « J'aime »
Nous ne chargeons que 20 messages à la fois, en utilisant ce que l’on appelle le « défilement virtuel ».
4 « J'aime »
que deviennent les anciens éléments DOM ? Si je continue à faire défiler, j’imagine que de plus en plus d’éléments sont ajoutés à l’arbre DOM. Sont-ils supprimés à un moment donné ?
1 « J'aime »
Non, nous les laissons autour, nous avons une pièce de logique de « dissimulation » qui remplace les éléments par un espace réservé une fois que vous êtes très loin de la fenêtre d’affichage, puis lorsque vous vous rapprochez de l’élément, nous le dévoilons en le re-rendant. Le seuil pour cette magie est assez élevé.
4 « J'aime »
@sam Y a-t-il un article que vous pouvez me fournir qui compare cette technique au recyclage de composants ? Je serais intéressé d’en lire davantage à ce sujet. Comment avez-vous pris cette décision ? J’imagine que A tour of how the Widget (Virtual DOM) code in Discourse works est également lié à cela.
1 « J'aime »
Je ne pense pas que nous ayons d’article, mais je pourrais me tromper. Peut-être que @eviltrout se souvient si nous avons documenté certaines de nos décisions concernant le post-masquage. Pas sûr.
2 « J'aime »
Cela fait très longtemps et je ne m’en souviens malheureusement pas.
Je ne pense pas que nous ayons jamais analysé complètement le recyclage des composants. Le camouflage a été une grande réussite et a résolu nos problèmes à l’époque.
4 « J'aime »
@eviltrout J’ai vu cet article Evil Trout Inc.
Après des années d’attente d’une percée dans les performances d’Android ou d’Ember, nous avons décidé qu’il était temps de prendre l’option nucléaire : nous avons remplacé le moteur de rendu Ember pour notre vue la plus courante par un moteur de rendu personnalisé basé sur un DOM virtuel.
Il semble donc que le système vdom/widget de Discourse ait été construit en réponse aux problèmes de performance d’Android.
Ce commit qui introduit le cloaking semble se produire après le système vdom/widget :
Le cloaking et le système vdom/widget sont-ils liés d’une manière ou d’une autre ? Il semble qu’ils traitent tous deux de la performance. Le recyclage des composants réduirait considérablement le nombre d’éléments DOM, donc quelque chose comme le système vdom/widget ne serait pas nécessaire, n’est-ce pas ?
2 « J'aime »
Nous avions le masquage avant le vdom, mais il a été réimplémenté après que nous ayons remarqué que nous en avions également besoin là-bas.
Le recyclage des composants devrait réduire la mémoire et améliorer les choses sur les grands sujets, mais il n’accélérera pas le temps de rendu que les widgets font considérablement.
3 « J'aime »
On ne saurait trop insister sur le fait que tous les problèmes de performance impliquent des compromis. Je pense qu’Ember fait ce qu’il faut ici et se concentre sur les applications qui sont organisées et évoluent à mesure que vous ajoutez des fonctionnalités. Pour la grande majorité des vues de votre application, la surcharge du framework ne vous préoccupera pas. Cependant, si vous rendez de nombreux composants imbriqués avec de nombreuses liaisons, la situation peut devenir pathologique.
Bien que Discourse puisse sembler simple en surface, chaque message est rendu avec pas mal de composants. Nous avons de nombreux boutons dynamiques, liens et effets appliqués chaque fois qu’un message est rendu avec plus de 150 attributs impliqués.
J’ai vu cela dans l’article de blog que @eviltrout a écrit. Il semble que la performance d’Ember ne soit généralement pas un problème, mais seulement dans le cas spécifique des sujets Discourse, n’est-ce pas ? Les sujets Discourse sont une très longue liste de composants (messages) qui ont beaucoup de composants à l’intérieur d’eux (bouton de réponse, bouton de j’aime, etc.). C’est ce qui entraîne une dégradation des performances de rendu.
Le vdom/widgets atténue quelque peu ce problème, car il rend le processus de rendu moins coûteux. Mais à un moment donné, la quantité d’éléments DOM devient si importante qu’il faut la réduire en les masquant.
Le recyclage des composants signifie éviter complètement ce problème, en n’ayant qu’un nombre fixe d’éléments DOM à l’écran, qui sont réutilisés au fur et à mesure que l’utilisateur fait défiler le contenu.
Veuillez me corriger si j’ai mal caractérisé quoi que ce soit.
Merci,
Spirobel 
2 « J'aime »