javascript - have - ¿React Native tiene un ''DOM virtual''?
react cdn example (4)
De la página wiki de ReactJS sobre Virtual DOM:
React crea un caché de estructura de datos en memoria, calcula las diferencias resultantes y luego actualiza el DOM visualizado del navegador de manera eficiente. Esto le permite al programador escribir código como si toda la página estuviera renderizada en cada cambio, mientras que las bibliotecas React solo presentan subcomponentes que realmente cambian.
En otras palabras, el DOM virtual nos permite mejorar el rendimiento al evitar manipulaciones directas con el DOM.
Pero ¿qué pasa con React Native ?
Sabemos que, en teoría, en otras plataformas hay vistas nativas y componentes de IU. No hay nada sobre el propio DOM. Entonces, ¿podemos decir que React Native tiene "DOM virtual" allí o estamos hablando de otra cosa?
Por ejemplo, hay una section en las especificaciones de Weex que describe los métodos para trabajar directamente con DOM-tree. Y mi suposición es que potencialmente podemos pensar que React Native también debería tener algún tipo de DOM-tree, así como la capa de abstracción "Virtual DOM", que es la idea principal de React.
Así que mi pregunta es:
¿React Native tiene algún tipo de "DOM virtual" (o su representación) y, de ser así, cómo se traslada este "DOM virtual" a varias plataformas?
ACTUALIZAR:
El objetivo de esta pregunta es arrojar algo de luz sobre cómo React Native administra la representación de los componentes de la interfaz de usuario nativos. ¿Hay algún enfoque específico y, de ser así, cómo se llama oficialmente?
ACTUALIZACIÓN 2:
Este artículo describe la nueva arquitectura React llamada Fiber que se parece a la respuesta a esta pregunta.
En breve
Bueno ... en esencia, sí, al igual que el DOM virtual de Reactjs, React-Native crea una jerarquía de árbol para definir el diseño inicial y crea una diferencia de ese árbol en cada cambio de diseño para optimizar las representaciones. Excepto que React-Native administra las actualizaciones de la interfaz de usuario a través de un par de capas de arquitectura que, al final, traducen cómo deben representarse las vistas al intentar optimizar los cambios al mínimo con el fin de ofrecer la representación más rápida posible.
Una explicación más detallada.
Para entender cómo reaccionar nativo crea vistas en segundo plano, necesitarás entender los fundamentos, y para eso, prefiero comenzar desde cero.
1.El motor de diseño de yoga
Yoga es un motor de diseño multiplataforma escrito en C que implementa Flexbox a través de enlaces a las vistas nativas (Java Android Views / Objective-C iOS UIKit) .
Todos los cálculos de diseño de las distintas vistas, textos e imágenes en React-Native se realizan a través del yoga, este es básicamente el último paso antes de que nuestras vistas se muestren en la pantalla.
2. Árbol de sombra / Nodos de sombra
Cuando react-native envía los comandos para representar el diseño, se ensambla un grupo de nodos en la sombra para crear un árbol de sombras que represente el lado nativo mutable del diseño (es decir, escrito en el correspondiente idioma nativo correspondiente, Java para Android y Objective-C). para iOS) que luego se traduce a las vistas reales en pantalla (usando Yoga).
3. ViewManager
ViewManger es una interfaz que sabe cómo traducir los tipos de vista enviados desde JavaScript a sus componentes de interfaz de usuario nativos. ViewManager sabe cómo crear un nodo de sombra, un nodo de vista nativo y actualizar las vistas. En el marco React-Native, hay muchos ViewManager que permiten el uso de los componentes nativos. Si, por ejemplo, algún día le gustaría crear una nueva vista personalizada y agregarla a reaccion-native, esa vista tendrá que implementar la interfaz de ViewManager
4. UIManager
El UIManager es la pieza final del rompecabezas, o en realidad la primera. Los comandos declarativos de JavaScript JSX se envían al comando nativo como imperativo que le dice a React-Native cómo diseñar las vistas, paso a paso de manera iterativa. Por lo tanto, como primer procesamiento, UIManager enviará el comando para crear las vistas necesarias y continuará enviando los datos de actualización a medida que la IU de la aplicación cambie con el tiempo.
Así que React-Native básicamente aún utiliza la capacidad de Reactjs para calcular la diferencia entre la representación de representación anterior y la actual y envía los eventos al UIManager en consecuencia
Para conocer el proceso un poco más en profundidad, recomiendo la siguiente presentation de Emil Sjölander de la Conferencia React-Native EU 2017 en Wroclaw
Aquí hay una simplificación excesiva: ReactJS genera el DOM que se puede representar en los navegadores. Como ya sabe, el DOM virtual ayuda a ReactJS a realizar un seguimiento eficiente del delta de lo que ha cambiado. Para React Native para iOS, en última instancia, genera código UIKit. Lo mismo ocurre con React Native para Android, pero en lugar de generar DOM o UI Kit, la salida se crea mediante los SDK de Android. Así que el DOM virtual es solo un paso intermedio. Se puede considerar como una combinación de la estructura de datos interna para guardar los datos que describen dónde representar el botón y el cuadro de texto, lo que sucede cuando se presiona el botón, etc. y un algoritmo eficiente para realizar un seguimiento de lo que ha cambiado. El mismo código se puede utilizar para todas las plataformas. Sólo el paso final es diferente. Dependiendo de la plataforma, tiene un código que genera el DOM, el código UIKit o el nombre que se llame a la IU de Android.
No sé si esta es la respuesta a su pregunta, pero encontré esto en los documentos oficiales de React:
React construye y mantiene una representación interna de la interfaz de usuario renderizada. Incluye los elementos React que devuelves de tus componentes. Esta representación permite a React evitar la creación de nodos DOM y el acceso a los existentes más allá de la necesidad, ya que puede ser más lento que las operaciones en objetos JavaScript. A veces se le conoce como un "DOM virtual", pero funciona de la misma manera en React Native.
Así que diría que sí, gestiona una representación interna muy similar a la utilizada en React.js. Entonces supongo que utiliza las API de Javascript para representar vistas nativas tal como lo sugiere el artículo que has leído .
EDITAR Esta publicación proporcionada por Sebas en un comentario también es interesante porque un miembro del equipo React (y React Native) dice que:
React Native muestra que ReactJS siempre ha sido más sobre "cero DOM" que "virtual DOM" (contrariamente a la creencia popular).
Parece que el llamado ''Reactual DOM virtual'' está mucho más cerca de una estructura / representación interna de los elementos que pueden asignarse a varias tecnologías que a un DOM HTML.
Este artículo describe la nueva arquitectura React llamada Fiber . Parece ser la respuesta correcta sobre lo que está sucediendo en React Native o al menos lo que React Native intentará lograr en el futuro más cercano.
El DOM es solo uno de los entornos de renderizado a los que React puede procesar, los otros objetivos principales son las vistas nativas de iOS y Android a través de React Native. (Esta es la razón por la que "virtual DOM" es un poco inapropiado.)
La razón por la que puede admitir tantos objetivos es porque React está diseñado para que la reconciliación y la representación sean fases separadas. El reconciliador hace el trabajo de calcular qué partes de un árbol han cambiado; el renderizador luego usa esa información para actualizar realmente la aplicación renderizada.
Esta separación significa que React DOM y React Native pueden usar sus propios renderizadores mientras comparten el mismo reconciliador, proporcionado por el núcleo de React.
La fibra reimplementa el reconciliador.