¡Es 2019! Todos piensan que conocen la división de código. Entonces, ¡revisemos dos veces!
¿Qué significa la división de código?
En resumen, la división de código consiste en no cargar todo. Entonces estás leyendo esta página, no tienes que cargar un sitio completo. Cuando selecciona una sola fila de una base de datos, no tiene que tomar todo.
Obvio? La división del código también es bastante obvia, no solo sobre sus datos, sino sobre su código.
¿Quién (¿Qué?) ¿Está dividiendo el código?
React.lazy ? No, solo lo usa. La división de código se realiza en un nivel de paquete: paquete web, parcela o simplemente su sistema de archivos en el caso de módulos esm "nativos". La división de código es solo archivos, archivos que puede cargar en algún lugar "más tarde". Entonces, a las preguntas " ¿Qué es la división de código de alimentación? ", La respuesta es: un "paquete".
¿Quién (Qué) está usando la división de código?
React.lazy está usando. Simplemente usando la división de código de su paquete. Simplemente llamando a import cuando se procesó. Y eso es todo.
¿Qué hay de React-loadable?
React.lazy reemplazó. Y proporcionó más funciones, como Suspense para controlar el estado de carga. Entonces, use React.Lazy en React.Lazy lugar.
Sí, eso es todo. Gracias por leer y que tengas un buen día.
¿Por qué el artículo no está terminado?
Bueno Hay algunas zonas grises sobre React.lazy y la división de código que olvidé mencionar.
Zona gris 1 - prueba
No es fácil probar React.lazy debido a su asincronía . Estaría simplemente "vacío", siempre y cuando todavía no esté cargado (incluso si lo está): Promises e devoluciones de import , y acepta perezosamente, promesas , que siempre se ejecutaron en el siguiente tic .
¿Solución propuesta? No lo creería, pero la solución propuesta es utilizar thenables sincrónicos: consulte la solicitud de extracción . Entonces, ¡hagamos que nuestras imports SINCRÓNICAS! (para solucionar un problema vago para las pruebas o cualquier otro caso del lado del servidor)
const LazyText = lazy(() => ({ then(cb) { cb({default: Text});
No es difícil convertir la función de importación en una función sincronizable memorizable.
const syncImport = (importFn) => { let preloaded = undefined; const promise = importFn().then(module => preloaded = module);
Zona gris 2 - SSR
Si NO necesita SSR, ¡continúe leyendo el artículo!
React.lazy es React.lazy SSR. Pero requiere Suspense para funcionar, y Suspenso NO es amigable con el servidor .
Hay 2 soluciones:
Esta es una buena opción, pero no sería del todo amigable para el cliente. Por qué Definamos la segunda solución posible:
- Use una biblioteca especializada para rastrear los scripts, fragmentos y estilos usados, y cárguelos en el lado del cliente (¡especialmente los estilos!) Antes de reaccionar la hidratación. O bien, representaría agujeros vacíos en lugar de sus componentes divididos en código. Una vez más, no cargó el código que acaba de dividir, por lo que no puede procesar nada de lo que va a hacer.
He aquí las bibliotecas de división de código
- Componente universal : la biblioteca más antigua y aún mantenible. "Inventó" la división de código en términos de Webpack enseñado a la división de código.
- Cargable por reacción : muy popular, pero una biblioteca sin mantenimiento. Hizo que el código escupiera algo popular. Los problemas están cerrados, por lo que no hay comunidad alrededor.
- Componentes cargables : una biblioteca completa de funciones, es un placer usarla, con la comunidad más activa.
- Componente importado : una biblioteca única, no vinculada a Webpack, es decir, capaz de manejar parcela o esm.
- Componente React-async : biblioteca ya muerta (pero popular), que tuvo un impacto significativo en todo lo relacionado con la división de código, el recorrido personalizado del árbol React y la SSR.
- Otra biblioteca, había muchas bibliotecas, muchas de las cuales no sobrevivieron a la evolución de Webpack o React 16, no las he enumerado aquí, pero si conoces a un buen candidato, solo envíame un mensaje.
¿Qué biblioteca elegir?
Es fácil, no reacciona cargable , es pesado, sin mantenimiento y obsoleto, incluso si todavía es mega popular. (y gracias por popularizar la división de código, una vez más)
Componentes cargables : puede ser una muy buena opción. Está muy bien escrito, se mantiene activamente y admite todo de forma inmediata. Admite "importaciones dinámicas completas", lo que le permite importar archivos dependiendo de los accesorios proporcionados, pero por lo tanto no se pueden tipificar. Admite suspenso, por lo que podría reemplazar React.lazy.
Componente universal , en realidad "inventores" de importaciones dinámicas completas, lo implementaron en Webpack. Y muchas otras cosas a bajo nivel, lo hicieron. Yo diría que esta biblioteca es un poco dura y un poco menos fácil de usar. La documentación de los componentes cargables es inmejorable. Vale la pena si no usa esta biblioteca, luego lea la documentación: hay tantos detalles que debe saber ...
Componente importado por reacción : es un poco extraño. Es independiente del paquete, por lo que nunca se rompería (no hay nada que romper), funcionaría con Webpack 5 y 55, pero eso tiene un costo. Mientras que las bibliotecas anteriores durante SSR agregarían todas las secuencias de comandos utilizadas al cuerpo de la página, y podrá cargar todas las secuencias de comandos en paralelo: los nombres de archivos no conocidos importados y llamarán a las "importaciones" originales (por eso paquete independiente) para cargar fragmentos usados, pero solo puede realizar llamadas desde el paquete principal, por lo que todos los scripts adicionales se cargarán solo después de que se descargue y ejecute el principal. No admite importaciones dinámicas completas, como React.lazy y, como resultado, puede escribirse. También es compatible con suspenso. Utiliza thenables sincrónicos en SSR. También tiene un enfoque absolutamente diferente para CSS y un soporte perfecto para la representación de secuencias.
No hay diferencia en calidad o popularidad entre las bibliotecas que figuran en la lista, y todos somos buenos amigos, así que elige de todo corazón.
Zona gris 3 - render híbrido
SSR es algo bueno, pero, ya sabes, difícil. Los proyectos pequeños pueden querer tener un SSR, hay muchas razones para tenerlo, pero es posible que no quieran configurarlo y mantenerlo.
SSR podría ser realmente, REALMENTE difícil. Prueba razzle o ve con Next.js si quieres una victoria rápida.
Por lo tanto, la solución más fácil para SSR, especialmente para un SPA simple, sería la representación previa. Como abrir su SPA en un navegador y presionar el botón "Guardar". Como:
- React-snap : utiliza el titiritero (también conocido como Chrome sin cabeza) para representar su página en un "navegador" y guarda un resultado como una página HTML estática.
- Rendertron : que hace lo mismo, pero de una manera diferente (en la nube ).
La representación previa es "SSR" sin "Servidor". Es SSR usando un Cliente. Magia! Y trabajando fuera de la caja ... ... ... pero no para escupir código.
Entonces, acabas de renderizar tu página en un navegador, guardaste HTML y pediste cargar las mismas cosas. Pero no se usó el código específico del lado del servidor (para recopilar todos los fragmentos usados), ¡porque NO HAY SERVIDOR !
En la parte anterior, he señalado las bibliotecas que están vinculadas a webpack en términos de recopilación de información sobre fragmentos usados: no podían manejar el renderizado híbrido en absoluto.
La versión 2 de componentes cargables (incompatible con la versión 5 actual) fue parcialmente compatible con react-snap. El apoyo se ha ido.
El componente importado por reacción podría manejar este caso, siempre y cuando no esté unido al paquete / lado, por lo que no hay diferencia para SSR o híbrido, sino solo para reacción instantánea, siempre que sea compatible con la "hidratación del estado", mientras que el rendertron no.
Esta capacidad de reaccionar-componente importado se encontró durante la redacción de este artículo, no se conocía antes - ver ejemplo Es muy facil.
Y aquí debe usar otra solución, que es perpendicular a todas las demás bibliotecas.
Componente de reacción previa
Esta biblioteca fue creada para una hidratación parcial y podría rehidratar parcialmente su aplicación, manteniendo el resto aún deshidratado. Y funciona para renderizadores SSR e híbridos sin ninguna diferencia.
La idea es simple:
- durante SSR: renderice el componente, envuelto con un <div />
- en el cliente: busque ese div y use innerHTML hasta que Component esté listo para reemplazar HTML muerto.
- no tiene que cargar, y espere un trozo con un componente dividido antes de
hydrate para NO generar un agujero blanco en su lugar , solo use HTML pre-renderizado, que es absolutamente igual al que representaría un componente real , y que ya existe: viene con una respuesta de servidor (o hidrid).
Es por eso que tenemos que esperar a que se carguen todos los fragmentos antes de hidratarse, para que coincida con el HTML renderizado por el servidor. Es por eso que podríamos usar piezas de HTML renderizado por el servidor hasta que el cliente no esté listo: es igual al que solo vamos a producir.
import {PrerenderedComponent} from 'react-prerendered-component'; const importer = memoizeOne(() => import('./Component'));
Hay otro artículo sobre esta tecnología , puede leer. Pero lo principal aquí es que resuelve "Flash de contenido descargado" en otro, no es una forma común de bibliotecas de división de código . Esté abierto a nuevas soluciones.
TLDR?
- no use react-loadable, no agregaría ningún valor valioso
- React.lazy es bueno, pero demasiado simple todavía.
- SSR es algo difícil, y debes saberlo
- El renderizado híbrido dirigido por titiriteros es una cosa. A veces algo aún más difícil.