Ho una domanda riguardo allo scrolling: su Android c’è qualcosa chiamato recyclerview Crea elenchi dinamici con RecyclerView | Android Developers che riutilizza i componenti invece di aggiungerne sempre di più durante uno scroll. Sembra che Discourse non faccia questo? Perché? Viene utilizzata una strategia diversa? Ho avuto la vaga impressione che il sistema di widget vdom personalizzato sia stato creato per affrontare questo problema (di un elenco in continua crescita di elementi DOM), ma ad essere onesti non capisco ancora come questo risolva il problema. 
Forse qualcuno può fare luce su questo 
3 Mi Piace
Carichiamo solo 20 post alla volta, utilizzando quello che viene chiamato “scrolling virtuale”.
4 Mi Piace
Cosa succede ai vecchi elementi DOM? Se continuo a scorrere, immagino che sempre più elementi vengano aggiunti all’albero DOM. Vengono rimossi a un certo punto?
1 Mi Piace
No, li lasciamo in giro, abbiamo un pezzo di logica di “cloaking” che sostituisce gli elementi con un segnaposto una volta che sei molto lontano dal viewport, quindi quando ti avvicini all’elemento ci “scapottiamo” ri-renderizzando. La soglia per questa magia è piuttosto alta.
4 Mi Piace
@sam C’è un articolo che puoi collegarmi che confronta questa tecnica con il riciclo dei componenti? Sarei interessato a saperne di più. Come sei arrivato a prendere questa decisione? Immagino che anche A tour of how the Widget (Virtual DOM) code in Discourse works sia correlato a questo.
1 Mi Piace
Non credo che abbiamo un articolo, ma potrei sbagliarmi. Forse @eviltrout ricorda se abbiamo documentato alcune delle nostre decisioni in merito al post-cloaking. Non sono sicuro.
2 Mi Piace
È passato molto tempo, quindi purtroppo non ricordo.
Non credo che abbiamo mai analizzato completamente il riciclo dei componenti. L’invisibilità è stata un grande successo e ha risolto i nostri problemi all’epoca.
4 Mi Piace
@eviltrout Ho visto questo post Evil Trout Inc.
Dopo anni di attesa per una svolta nelle prestazioni di Android o Ember, abbiamo deciso che era ora di prendere l’opzione nucleare: abbiamo sostituito il motore di rendering di Ember per la nostra vista più comune con un renderer personalizzato basato sul DOM virtuale.
Quindi sembra che il sistema vdom/widget in discourse sia stato costruito in risposta ai problemi di prestazioni di Android.
Questo commit che introduce il cloaking sembra avvenire dopo il sistema vdom/widget:
Il cloaking e il sistema vdom/widget sono in qualche modo correlati? Sembra che entrambi affrontino le prestazioni. Il riciclo dei componenti ridurrebbe significativamente il numero di elementi DOM, quindi qualcosa come il sistema vdom/widget non sarebbe necessario, giusto?
2 Mi Piace
Avevamo il cloaking prima del vdom, ma è stato re-implementato dopo che ci siamo accorti che ci serviva anche lì.
Il riciclo dei componenti dovrebbe ridurre la memoria e migliorare le cose su argomenti di grandi dimensioni, ma non accelererà il tempo di rendering che i widget fanno considerevolmente.
3 Mi Piace
Non si può sottovalutare che tutti i problemi di performance riguardano compromessi. Penso che Ember faccia la cosa giusta qui e si concentri su applicazioni organizzate e scalabili man mano che aggiungi più funzionalità. Per la stragrande maggioranza delle viste nella tua applicazione, l’overhead del framework non ti preoccuperà. Tuttavia, se stai renderizzando molti componenti annidati con molti binding, la situazione può diventare patologica.
Sebbene Discourse possa sembrare semplice in superficie, ogni post viene renderizzato con un bel po’ di componenti. Abbiamo molti pulsanti dinamici, link ed effetti applicati ogni volta che un post viene renderizzato con oltre 150 attributi coinvolti.
Ho visto questo nel post del blog scritto da @eviltrout. Sembra che le performance di Ember non siano un problema in generale, ma solo nel caso specifico degli argomenti di Discourse, giusto? Gli argomenti di Discourse sono una lista molto lunga di componenti (post) che hanno molti componenti al loro interno (pulsante di risposta, pulsante “mi piace”, ecc.). Questo è ciò che porta al degrado delle performance di renderizzazione.
vdom/widgets alleviano in parte questo problema, perché rendono il processo di renderizzazione meno costoso. Ma a un certo punto la quantità di elementi DOM diventa così grande che devono essere ridotti nascondendoli.
Il riciclo dei componenti significa evitare del tutto questo problema, avendo solo un numero fisso di elementi DOM sullo schermo, che vengono riutilizzati mentre l’utente scorre il contenuto.
Per favore, correggimi se ho caratterizzato male qualcosa.
Grazie,
Spirobel 
2 Mi Piace