javascript - ejemplos - ¿Por qué se dice que el concepto de Virtual DOM de React es más eficaz que la comprobación de modelos sucios?

react js

Question

Vi una charla de desarrollo de React en http://www.youtube.com/watch?v=x7cQ3mrcKaY y el orador mencionó que la comprobación de suciedad del modelo puede ser lenta. Pero, ¿el cálculo de la diferencia entre los DOM virtuales en realidad es incluso 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 saber todos los pros y los contras.

Answer 1

Realmente me gusta el poder potencial del DOM virtual (especialmente la representación del lado del servidor) pero me gustaría saber todos los pros y los contras.

- OP

React no es la única biblioteca de manipulación de DOM. Le animo a comprender las alternativas leyendo este artículo de Auth0 que incluye una explicación detallada y puntos de referencia. Resaltaré aquí sus pros y sus contras, como usted preguntó:

React.js ''DOM virtual

PROS

• Rápido y eficiente algoritmo "difusor".
• Múltiples frontends (JSX, hyperscript)
• Ligero lo suficiente para funcionar en dispositivos móviles
• Mucha tracción y mentalidad.
• Se puede usar sin React (es decir, como un motor independiente)

CONTRAS

• Copia completa en memoria del DOM (mayor uso de memoria)
• No hay diferenciación entre elementos estáticos y dinámicos.

Ember.js ''Glimmer

PROS

• Algoritmo difuso rápido y eficiente
• Diferenciación entre elementos estáticos y dinámicos.
• 100% compatible con la API de Ember (obtiene los beneficios sin actualizaciones importantes de su código existente)
• Representación ligera en memoria del DOM

CONTRAS

• Pretende ser utilizado sólo en Ember
• Solo un frontend disponible

DOM incremental

PROS

• Reducción del uso de memoria.
• API simple
• Se integra fácilmente con muchos frontends y frameworks (creados desde el principio como backend de motores de plantillas)

CONTRAS

• No es tan rápido como otras bibliotecas (esto es discutible, consulte los puntos de referencia a continuación)
• Menos uso de la mente y de la comunidad.

Answer 2

Aquí hay un comentario del miembro del equipo de React, Sebastian Markbåge, que arroja algo de luz:

React hace la diferencia en la salida (que es un formato serializable conocido, atributos DOM). Esto significa que los datos de origen pueden ser de cualquier formato. Puede ser estructuras de datos inmutables y estado dentro de los cierres.

El modelo angular no conserva la transparencia referencial y, por lo tanto, es inherentemente mutable. Usted muta el modelo existente para rastrear los cambios. ¿Qué sucede si su fuente de datos son datos inmutables o una nueva estructura de datos cada vez (como una respuesta JSON)?

La comprobación sucia y Object.observe no funcionan en el estado del alcance de cierre.

Estas dos cosas son muy limitantes a los patrones funcionales, obviamente.

Además, cuando la complejidad de su modelo crece, cada vez es más caro hacer un seguimiento sucio. Sin embargo, si solo se diferencian en el árbol visual, como React, entonces no crece tanto, ya que la cantidad de datos que puede mostrar en la pantalla en cualquier punto dado está limitada por las IU. El enlace de Pete anterior cubre más de los beneficios de perf.

https://news.ycombinator.com/item?id=6937668

Answer 3

Recientemente leí un artículo detallado sobre el algoritmo diff de React aquí: http://calendar.perfplanet.com/2013/diff/ . Por lo que entiendo, lo que hace reaccionar rápido es:

• Operaciones de lectura / escritura de DOM por lotes.
• Actualización eficiente de subárbol solamente.

Comparado con el de comprobación sucia, las diferencias clave de IMO son:

1. Modelo de comprobación de suciedad : el componente React se establece explícitamente como sucio cada setState se llama a setState , por lo que no se necesita una comparación (de los datos) aquí. Para el control de la suciedad, la comparación (de los modelos) siempre ocurre en cada bucle de resumen.

2. Actualización de DOM : las operaciones de DOM son muy caras porque la modificación del DOM también se aplicará y calculará los estilos CSS, diseños. El tiempo ahorrado por la modificación innecesaria del DOM puede ser más largo que el tiempo empleado en difuminar el DOM virtual.

El segundo punto es aún más importante para los modelos no triviales, como uno con una gran cantidad de campos o una lista grande. Un cambio de campo del modelo complejo dará como resultado solo las operaciones necesarias para los elementos DOM que involucran ese campo, en lugar de la vista / plantilla completa.

Answer 4

Soy el autor principal de un módulo de virtual-dom , por lo que podría responder sus preguntas. De hecho, hay 2 problemas que deben resolverse aquí.

1. ¿Cuándo vuelvo a renderizar? Respuesta: Cuando observo que los datos están sucios.
2. ¿Cómo vuelvo a renderizar eficientemente? Respuesta: Usar un DOM virtual para generar un parche de DOM real

En React, cada uno de sus componentes tiene un estado. Este estado es como un observable que puede encontrar en las bibliotecas de estilo de nocaut u otras MVVM. Esencialmente, React sabe cuándo volver a renderizar la escena porque puede observar cuando estos datos cambian. La verificación sucia es más lenta que los observables porque debe sondear los datos en un intervalo regular y verificar todos los valores en 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 hacer una nueva representación en la cola.

El DOM virtual se utiliza para la representación eficiente del DOM. Esto no está realmente relacionado con la comprobación sucia de sus datos. Podría volver a generar utilizando un DOM virtual con o sin comprobación sucia. Tiene razón al considerar que existe cierta sobrecarga en el cálculo de la diferencia entre dos árboles virtuales, pero la diferencia de DOM virtual consiste en comprender qué es necesario actualizar en 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.

Nuestro objetivo es volver a representar el árbol virtual solo cuando el estado cambia. Por lo tanto, usar un observable para verificar si el estado ha cambiado es una forma eficiente de evitar repeticiones de procesamiento innecesarias, lo que causaría muchas diferencias innecesarias de árboles. Si nada ha cambiado, no hacemos nada.

Un DOM virtual es bueno porque nos permite escribir nuestro código como si estuviéramos representando la escena completa. Detrás de escena, queremos calcular una operación de parche que actualice el DOM para ver cómo esperamos. Por lo tanto, si bien el algoritmo DOM diff / patch virtual probablemente no sea la solución óptima , nos brinda una manera 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 anterior de DOM. Tampoco tenemos que volver a renderizar la escena completa, lo que podría ser mucho menos eficiente que parchearla.

Answer 5

Virtual Dom no es inventado por reaccionar. Es parte de HTML dom. Es ligero y separado de los detalles de implementación específicos del navegador.

Podemos pensar en el DOM virtual como la copia local y simplificada de React del DOM HTML. Le permite a React hacer sus cálculos dentro de este mundo abstracto y omitir las operaciones DOM "reales", a menudo lentas y específicas del navegador. En realidad no hay una gran diferencia entre DOM y VIRTUAL DOM.

A continuación se muestran los puntos por los que se utiliza Virtual Dom (fuente https://hackernoon.com/virtual-dom-in-reactjs-43a3fdb1d130 ):

Cuando tu lo hagas:

document.getElementById(''elementId'').innerHTML = "New Value" Following thing happens:

1. El navegador necesita analizar el HTML
2. Elimina el elemento hijo de elementId
3. Actualiza el valor DOM con nuevo valor.
4. Vuelva a calcular el css para el padre y el niño
5. Actualice el diseño, es decir, cada elemento coordine exactamente en la pantalla
6. Recorre el árbol de renderizado y píntalo en la pantalla del navegador

Recalcular el CSS y los diseños modificados utiliza un algoritmo complejo que afecta el rendimiento.

Además de actualizar las propiedades del DOM, es decir. valores. Sigue un algoritmo.

Ahora, supongamos que si actualiza DOM 10 veces directamente, entonces todos los pasos anteriores se ejecutarán uno por uno y la actualización de los algoritmos DOM tomará tiempo para actualizar los valores de DOM.

Es por esto que Real DOM es más lento que el DOM virtual.