1. Característica La plantilla de
fragmentos
admite tipos de fragmentos y cadenas, correspondientes a las matrices y cadenas de ReactElement
v16.2.0 también proporciona compatibilidad con fragmentos JSX: <> </> control de errores a nivel de componente de
límite
de error, compatibilidad para capturar excepciones internas en el árbol de subcomponentes y una solución para la capa de interfaz de usuario
Portal
permite que el árbol de componentes sea inconsistente con la estructura del árbol DOM y se usa en escenarios como tarjetas flotantes, información sobre herramientas, etc.
Por ejemplo, en la estructura DOM de información sobre herramientas, target y tip son generalmente hermanos (requeridos para el diseño), mientras que, lógicamente, tip pertenece al target, que es una relación padre-hijo. Los portales se utilizan para manejar este escenario.
En particular, después de que se procesa el burbujeo de eventos, el componente principal del componente de portales aún puede recibir notificaciones de burbujeo (antes de React 16, se construyó un sistema de eventos para suavizar la diferencia en el burbujeo de eventos DOM. Por cierto, el ejemplo de burbujeo burbujeante es compatible)
La compatibilidad con atributos DOM personalizados tiene una
lista blanca integrada de nombres de atributos HTML / SVG. Los atributos personalizados se bloquearán e ignorarán. React 16 elimina esta restricción.
Hay dos razones para eliminar esta restricción. Una es que el filtrado de propiedades incorporado de esta capa no es compatible con propiedades nuevas no estándar (como la etapa de propuesta) y otras bibliotecas / marcos (como Angular, Polymer); en segundo lugar, es necesario en el paquete Incorporada en una lista blanca de atributos que no son de tamaño pequeño, que es difícil de mantener
Se
afirma que la renderización mejorada del lado del servidor es 3 veces más rápida que React 15 (escenario de referencia, se dice que un escenario empresarial es 1,3 veces más rápido), y ha hecho varias cosas:
Corriente de soporte
El process.env redundante (acceder a esta variable en el entorno del nodo requiere mucho tiempo) se elimina durante la construcción
El cliente ya no calcula la suma de comprobación, pero reutiliza el DOM existente tanto como sea posible (similar a la implementación de inferno para la reutilización del nodo DOM, pero la reutilización inferno parece haber encontrado algunos problemas, y ahora solo se proporciona como una opción en lugar de una característica destacada)
Nota: React 16 parece tener algunos problemas de reutilización del nodo DOM:
However, it’s dangerous to have missing nodes on the server render as this might cause sibling nodes to be created with incorrect attributes.PD ¿A qué escenas peligrosas se debe prestar atención? El blog oficial se puede dar más adelante, y no está claro por el momento.
Tamaño de archivo reducido Reducción del
paquete de React (refactorizado, estrategia de empaque aplanado y reemplazado con rollup), tamaño 30% más pequeño
2. El
mayor cambio en *** debería ser ***, esta vez me di cuenta en serio (el *** anterior parece haber sido recogido en el suelo)
1. El nuevo
lado del servidor API agrega renderToNodeStream, renderToStaticNodeStream correspondientes a renderToString, renderToStaticMarkup, respectivamente
Hidrato añadido en el lado del cliente
2. Verificación de consistencia suelta La verificación del
lado del cliente no es tan estricta:
En React 15, el cliente realizará una verificación de consistencia a nivel de personaje en los *** resultados obtenidos, y si hay una discrepancia, el cliente regenerará y reemplazará todo el resultado.
React 16 permite un orden de atributos inconsistente y no repara automáticamente atributos inconsistentes, y hará cambios a nivel de subárbol cuando encuentre una estructura de etiqueta no coincidente, en lugar de reemplazar la totalidad
Además, la suma de comprobación (data-react-checksum) y el id (data-reactid) en la estructura HTML del servidor también se eliminan, y el tamaño del cuerpo de la respuesta se reducirá mucho:
<!-- react 15 -->
<div data-reactroot="" data-reactid="1"
data-react-checksum="122239856">
<!-- react-text: 2 -->This is some <!-- /react-text -->
<span data-reactid="3">server-generated</span>
<!-- react-text: 4--> <!-- /react-text -->
<span data-reactid="5">HTML.</span>
</div>
<!-- react 16 -->
<div data-reactroot="">
This is some <span>server-generated</span> <span>HTML.</span>
</div>
3. La optimización del rendimiento
elimina el acceso a process.env.NODE_ENV redundante de forma predeterminada, sin necesidad de compilar y eliminar manualmente
*** Ya no es necesario crear un DOM virtual de una sola vez, todo es mucho más rápido
La transmisión de soporte brinda las siguientes ventajas de rendimiento:
El servidor lo envía mientras realiza, en lugar de esperar a que se complete el *** antes de enviarlo todo a la vez, TTFB (el tiempo hasta el primer byte) es más rápido
El cliente dibuja mientras se conecta, en lugar de esperar hasta que el contenido de la respuesta esté completo antes de comenzar a dibujar. Los puntos de tiempo para analizar, dibujar y cargar recursos externos son todos avanzados
4. Error Boundary y Portal
React 16 no son compatibles *** Error Boundary y Portal no son compatibles
La representación del componente de terminal de servicio es incorrecta y no será bloqueada por Límite de error. Con el fin de transmitir las ventajas de rendimiento, se sacrifica el límite de error:
This is intentional / a known limitation. With streaming rendering it’s impossible to “call back” markup that has already been sent, and we opted to keep renderToString and renderToNodeStream’s output identical.
No solo renderToNodeStream, renderToStaticNodeStream no admite Error Boundary, ni renderToString. Como se mencionó anteriormente, para mantener los resultados de salida consistentes, no hay dos mecanismos para mantener
PD: Para obtener más información sobre *** Error Boundary, consulte componentDidCatch no funciona en el renderToString de React 16
La función del Portal puede causar "reflujo", que es lo mismo que Límite de error. No puede ser compatible con el mecanismo de transmisión (por supuesto, es imposible insertar el contenido del Portal en la transmisión que se ha enviado)
3. La
nueva arquitectura central de Fiber (tomó 2 años) para reescribir completamente el mecanismo de renderizado de componentes. La característica más crítica es el renderizado asíncrono, que implementa el renderizado programable (resuelve completamente el problema de que el proceso de montaje no se puede interrumpir una vez que se inicia. problema)
El proceso de refactorización es
algo enorme y el proceso de ejecución de la refactorización es muy interesante. hablando en general:
No tire de una nueva rama para hacerlo. Se cambia a través del interruptor de función useFiber, que se dice que simplifica el mantenimiento diario / manejo de conflictos, etc.
El primer paso es hacer un esqueleto (esqueleto). Admite parte de la API y luego ejecuta lentamente todos los casos de prueba (el llamado TDD, desarrollo impulsado por pruebas y finalmente 2000 casos)
Ayudas de ingeniería. Incluyendo seguimiento de progreso, seguimiento de resultado de prueba única (para descubrir fácilmente lo que está arreglado en un envío, lo que está roto, el método es muy simple: agregue tests-failing.txt, tests-pasando.txt al seguimiento de git), verificación continua del entorno de producción ( El llamado "dogfooding", todo el proceso desde la etapa inicial hasta el último paso de la prueba se "verifica realmente" continuamente, lo que puede considerarse una creencia visible)
Encuentre una empresa adecuada como banco de pruebas. Después de que esté casi estable, demuestre que está listo para la producción a través del negocio real y obtenga datos a través de la prueba A / B, deje que 200 millones de usuarios ayuden a sentirlo y luego corte a la cantidad total; al mismo tiempo, el sistema interno se corta por completo y el escenario de verificación se expande; finalmente, React La aplicación nativa viene en escala de grises
No directamente en el nuevo mecanismo. Por el momento, todavía se ejecuta de forma sincrónica (aunque Fiber admite la función asincrónica), prepárese para esperar unos meses más para suavizar la transición
Para el proceso de refactorización específico, vea React 16: Una mirada dentro de una reescritura compatible con API de nuestra biblioteca de interfaz de usuario
Por lo tanto, la representación asincrónica no se admite temporalmente:
This initial React 16.0 release is mostly focused on compatibility with existing apps. It does not enable asynchronous rendering yet. We will introduce an opt-in to the async mode later during React 16.x. We don’t expect React 16.0 to make your apps significantly faster or slower, but we’d love to know if you see improvements or regressions.Ventajas y
novedades
El manejo de errores a nivel de componente, los retornos de render a múltiples componentes y otras características que no eran fáciles de implementar antes se pueden crear después de la refactorización
Ventaja de experiencia
La fibra no es necesariamente más rápida, pero será más suave (dividir las tareas de renderizado y equilibrar la programación para evitar ocupar el hilo principal durante mucho tiempo), además del control de prioridad de tareas, lo que permite la animación y otras ejecuciones prioritarias.
La diferencia es bastante obvia, consulte React Stack vs Fiber
Materiales de referencia
React v16.0
Novedades del renderizado del lado del servidor en React 16
Cómo React Fiber puede hacer que sus aplicaciones web y móviles sean más fluidas y con mayor capacidad de respuesta