Vi una charla de desarrollo de React en (Pete Hunt: React: Rethinking best practices — JSConf EU 2013) y el orador mencionó que la verificación sucia del modelo puede ser lenta. Pero, ¿no es el cálculo de la diferencia entre los DOM virtuales en realidad aún menos eficiente ya que el DOM virtual, en la mayoría de los casos, debería ser más grande que el modelo?
Realmente me gusta el poder potencial del DOM virtual (especialmente la representación del lado del servidor), pero me gustaría conocer todos los pros y los contras.
Solución
Soy el autor principal de un módulo virtual-dom, por lo que podría responder a sus preguntas. De hecho, hay 2 problemas que deben resolverse aquí.
- ¿Cuándo vuelvo a renderizar? Respuesta: Cuando observo que los datos están sucios.
- ¿Cómo puedo volver a renderizar de manera eficiente? Respuesta: Uso de un DOM virtual para generar un parche DOM real
En React, cada uno de sus componentes tiene un estado. Este estado es como un observable que puede encontrar en knockout u otras bibliotecas de estilo MVVM. Esencialmente, React sabe cuándo volver a renderizar la escena porque es capaz de observar cuándo cambian estos datos. La comprobación sucia es más lenta que la observable porque debe sondear los datos a intervalos regulares y comprobar todos los valores de la estructura de datos de forma recursiva. En comparación, establecer un valor en el estado indicará a un oyente que algún estado ha cambiado, por lo que React puede simplemente escuchar los eventos de cambio en el estado y volver a renderizar en cola.
El DOM virtual se utiliza para la re-representación eficiente del DOM. Esto no está realmente relacionado con la verificación sucia de sus datos. Puede volver a renderizar utilizando un DOM virtual con o sin comprobación sucia. Tiene razón en que hay cierta sobrecarga en el cálculo de la diferencia entre dos árboles virtuales, pero la diferencia DOM virtual se trata de comprender qué necesita actualizarse en el DOM y no si sus datos han cambiado o no. De hecho, el algoritmo diff es un verificador sucio en sí mismo, pero se usa para ver si el DOM está sucio en su lugar.
Nuestro objetivo es volver a renderizar el árbol virtual solo cuando cambie el estado. Por lo tanto, el uso de un observable para verificar si el estado ha cambiado es una forma eficiente de evitar reprocesiones innecesarias, lo que causaría muchas diferencias de árbol innecesarias. Si nada ha cambiado, no hacemos nada.
Un DOM virtual es bueno porque nos permite escribir nuestro código como si estuviéramos re-renderizando toda la escena. Detrás de escena queremos calcular una operación de parche que actualiza el DOM para que se vea como esperamos. Entonces, si bien el algoritmo virtual DOM diff / patch probablemente no sea la solución óptima, nos brinda una forma muy agradable de expresar nuestras aplicaciones. Simplemente declaramos exactamente lo que queremos y React / virtual-dom resolverá cómo hacer que su escena se vea así. No tenemos que hacer manipulación manual de DOM o confundirnos sobre el estado DOM anterior. Tampoco tenemos que volver a renderizar toda la escena, lo que podría ser mucho menos eficiente que parchearla.
Otras respuestas
Realmente me gusta el poder potencial del DOM virtual (especialmente la representación del lado del servidor), pero me gustaría conocer todos los pros y los contras.
— OP
React no es la única biblioteca de manipulación DOM. Te animo a que entiendas las alternativas leyendo este artículo de Auth0 que incluye explicaciones detalladas y puntos de referencia. Destacaré aquí sus pros y sus contras, como usted preguntó:
DOM virtual de React.js
PROS
- Algoritmo de «diferenciación» rápido y eficiente
- Múltiples frontends (JSX, hiperscript)
- Lo suficientemente ligero como para ejecutarse en dispositivos móviles
- Lots of traction and mindshare
- Can be used without React (i.e. as an independent engine)
CONS
- Full in-memory copy of the DOM (higher memory use)
- No differentiation between static and dynamic elements
Ember.js’ Glimmer
PROS
- Fast and efficient diffing algorithm
- Differentiation between static and dynamic elements
- 100% compatible with Ember’s API (you get the benefits without major updates to your existing code)
- Lightweight in-memory representation of the DOM
CONS
- Meant to be used only in Ember
- Only one frontend available
Incremental DOM
PROS
- Reduced memory usage
- Simple API
- Easily integrates with many frontends and frameworks (meant as a template engine backend from the beginning)
CONS
- Not as fast as other libraries (this is arguable, see the benchmarks below)
- Less mindshare and community use
