Tengo una pregunta sobre el scroll: En Android existe algo llamado recyclerview Crea listas dinámicas con RecyclerView | Android Developers Reutiliza componentes en lugar de añadir más y más durante un scroll. ¿Parece que Discourse no hace esto? ¿Por qué es así? ¿Se utiliza una estrategia diferente? Tengo la vaga idea de que el sistema de widgets vdom personalizado se creó para abordar este problema (de una lista en constante crecimiento de elementos DOM), pero para ser honesto, todavía no entiendo cómo eso resuelve el problema. 
Tal vez alguien pueda arrojar algo de luz sobre esto 
3 Me gusta
Cargamos solo 20 publicaciones a la vez, utilizando lo que se llama “desplazamiento virtual”.
4 Me gusta
¿qué pasa con los elementos DOM antiguos? Si sigo desplazándome, imagino que se añadirán más y más elementos al árbol DOM. ¿Se eliminan en algún momento?
1 me gusta
No, los dejamos alrededor, tenemos una pieza de lógica de “ocultación” que reemplaza los elementos con un marcador de posición una vez que estás muy lejos del viewport, luego, cuando te acercas al elemento, lo volvemos a mostrar al renderizarlo de nuevo. El umbral para esta magia es bastante alto.
4 Me gusta
@sam ¿Hay algún artículo que puedas enlazarme que compare esta técnica con el reciclaje de componentes? Me interesaría leer más al respecto. ¿Cómo tomaste esta decisión? Me imagino que A tour of how the Widget (Virtual DOM) code in Discourse works también está relacionado con esto.
1 me gusta
No creo que tengamos un artículo, pero puedo estar equivocado. Quizás @eviltrout recuerde si documentamos algunas de nuestras decisiones sobre el enmascaramiento posterior. No estoy seguro.
2 Me gusta
Ha pasado mucho tiempo, así que lamentablemente no lo recuerdo.
No creo que llegáramos a analizar completamente los componentes de reciclaje. El camuflaje fue una gran victoria y resolvió nuestros problemas en ese momento.
4 Me gusta
@eviltrout Vi esta publicación Evil Trout Inc.
Después de años de esperar un avance en el rendimiento de Android o Ember, decidimos que era hora de tomar la opción nuclear: reemplazamos el motor de renderizado de Ember para nuestra vista más común con un renderizador personalizado basado en DOM virtual.
Así que parece que el sistema vdom/widget en Discourse se construyó como respuesta a los problemas de rendimiento de Android.
Este commit que introduce el cloaking parece ocurrir después del sistema vdom/widget:
¿El cloaking y el sistema vdom/widget están relacionados de alguna manera? Parece que ambos abordan el rendimiento. Reciclar componentes reduciría significativamente la cantidad de elementos del DOM, por lo que algo como el sistema vdom/widget no sería necesario, ¿verdad?
2 Me gusta
Teníamos ocultación antes del vdom, pero se reintrodujo después de que nos dimos cuenta de que también la necesitábamos allí.
Reciclar componentes debería reducir la memoria y mejorar las cosas en temas grandes, pero no acelerará el tiempo de renderizado que los widgets hacen considerablemente.
3 Me gusta
No se puede subestimar que todos los problemas de rendimiento se basan en compensaciones. Creo que Ember hace lo correcto aquí y se enfoca en aplicaciones que están organizadas y escalan a medida que agregas más funciones. Para la gran mayoría de las vistas en tu aplicación, la sobrecarga del framework no te preocupará. Sin embargo, si estás renderizando muchos componentes anidados con muchos enlaces, la situación puede volverse patológica.
Si bien Discourse puede parecer simple en la superficie, cada publicación se renderiza con bastantes componentes. Tenemos muchos botones dinámicos, enlaces y efectos aplicados cada vez que se renderiza una publicación con más de 150 atributos involucrados.
Vi esto en la publicación del blog que escribió @eviltrout. Parece que el rendimiento de Ember no es un problema en general, sino solo en el caso específico de los temas de Discourse, ¿verdad? Los temas de Discourse son una lista muy larga de componentes (publicaciones) que tienen muchos componentes dentro de ellos (botón de respuesta, botón de me gusta, etc.). Esto es lo que conduce a la degradación del rendimiento de renderizado.
El vdom/widgets alivia este problema hasta cierto punto, porque hace que el proceso de renderizado sea menos costoso. Pero en algún momento, la cantidad de elementos DOM se vuelve tan grande que deben reducirse ocultándolos.
Reciclar componentes significa evitar este problema por completo, al tener solo un número fijo de elementos DOM en la pantalla, que se reutilizan a medida que el usuario se desplaza por el contenido.
Por favor, corrígeme si he caracterizado algo mal.
Gracias,
Spirobel 
2 Me gusta