Lecciones aprendidas al crear un nuevo marco sobre React

Hola a todos, estoy agradecido con el equipo de React Advanced London por invitarme a compartir lo que he aprendido al crear un nuevo framework de pila completa que permite a los desarrolladores escribir código de React para construir interfaces de usuario. Un poco sobre mí, mi nombre es Shyam Swaroop y soy el cofundador y CTO de Atrilabs, una empresa que está construyendo un emocionante nuevo framework de pila completa. Estaba estudiando una maestría en la Universidad de Columbia, luego abandoné y comencé a trabajar en mi propia startup. He estado usando React durante más de un año, antes era más de una persona de Angular. Podemos encontrar el uso de JSX más allá del desarrollo web. Se ha convertido en una de las opciones principales para generar HTML, un caso de uso muy similar a SSG, SSR, o se puede decir un reemplazo para los motores de plantillas. Algunos proyectos han extendido la gramática de lenguajes como Go y Python para incluir JSX.

React va más allá del desarrollo front-end. Estamos mezclando contenido simple en archivos markdown con código de React para escribir contenido. Esto ha dado lugar a frameworks que se especializan en tareas específicas como la documentación. Un ejemplo popular sería DocuSource. React Native se utilizó para crear aplicaciones móviles nativas para Android e iOS. Hay algunos frameworks que se pueden utilizar para crear aplicaciones nativas de Windows o MacOS utilizando React. React Reconciler se puede adaptar para renderizar la interfaz de usuario en cualquier dispositivo. Recientemente me encontré con un caso de uso muy interesante que no implica renderizar la interfaz de usuario, sino sintetizar música mediante la escritura de código de React. Recuerdo el poder que sentí cuando aprendí React o Bison, donde solo escribes una gramática libre de contexto y genera el analizador. Desde entonces

Ahora que conozco React y las herramientas para manejar una base de código de React, puedo crear fácilmente un framework especializado para mejorar la productividad del equipo de desarrolladores web. Hemos visto varios frameworks basados en React y todos ellos innovan y se diferencian en sus ofertas para los desarrolladores. No fue fácil alcanzar este nivel de comodidad. Cuando decidí crear un framework de pila completa, me llevó más de un mes comprender el ecosistema de herramientas alrededor de React o JavaScript en general. Esto fue aún más difícil porque tuve que adentrarme un poco en la historia de JavaScript y cómo surgieron. Me encontré con la filosofía de diseño de React, lo que me motivó a escribir filosofías para el framework. Realmente me ayudó a decidir dos categorías principales de herramientas que nuestro framework debería utilizar. Esas son el empaquetador y el transpilador. Más sobre esto más adelante. Una vez que los tuvimos definidos, solo entonces pudimos pasar al desarrollo del framework.

Cuando pensamos en un framework, rápidamente comenzamos a pensar en que proporcionan abstracción, funciones auxiliares, componentes, renderizado en el lado del servidor, generación en el lado del servidor, etc. Damos muchas otras cosas por sentado. Por ejemplo, ¿cómo manejamos diferentes sintaxis de JavaScript y typescript en una sola base de código? ¿Cómo podemos importar archivos de typescript que no son de JavaScript en archivos de JavaScript o typescript? Por ejemplo, importamos archivos de imagen como URL de cadena y VG como componentes de React, etc. Estos se han convertido en los estándares de facto para una buena experiencia de desarrollo en cualquier framework. Esto es posible gracias a herramientas como compiladores, transpiladores, empaquetadores, formateadores y linters. El renderizado en el lado del servidor es un requisito común para la mayoría de los frameworks, si no todos. Por lo tanto, nuestro framework debe admitir React tanto en navegadores como en Node.js. En otras palabras, es crucial comprender la diferencia entre los diferentes tipos de módulos, especialmente ECMAScript y CommonJS. Cuando pensamos en qué empaquetador y herramientas de construcción utilizar, principalmente pensamos en cuán rápido se ejecutan. Pero como creador de un framework, es posible que debas pensar más en tus requisitos. Por ejemplo, si la experiencia del desarrollador implica code mods, es posible que prefieras algo como Babel en lugar de ESBuild porque Babel expone el AST para cargar como complementos, mientras que ESBuild no lo hace. Estamos utilizando Webpack y Babel juntos en un framework. Un framework permite a los desarrolladores escribir complementos, etc., donde los módulos de JavaScript se tratan como recursos diferentes. Necesitábamos una forma para que un recurso pueda apuntar a otro recurso. Una forma podría haber sido que escribas la ruta al módulo al que deseas apuntar, como en la primera declaración que ves aquí. Tiene varias desventajas. Mientras el desarrollador está escribiendo o escribiendo el código, el desarrollador no obtendrá ninguna intellisense y no habrá comprobaciones en tiempo de construcción. Para evitar esto, estamos utilizando una función de consulta de recursos llamada resource query de Webpack que podemos agregar al final de la ruta de importación, como puedes ver en el segundo ejemplo. En el segundo ejemplo, podemos ofrecer

Una pregunta importante es ¿cómo podemos insertar módulos no JavaScript como CSS, SVG, PNG, etc.? Necesitamos configurar múltiples herramientas para poder lograr esto en nuestro Necesitamos agregar tipos para archivos no JavaScript y necesitamos agregar tipos para el espacio de nombres de Node.js. Podemos hacer esto creando un archivo de declaración de tipo TypeScript e incluyéndolo en nuestro archivo tsconfig.json. Aquí vemos que estamos declarando tipos de modelos para informes obtenidos y coincidencia de diferentes patrones globales. Veamos la parte resaltada. Esto informa a las herramientas como eslint en nuestros editores de código que cuando la cadena de origen termina con svg, trate el módulo de origen como que exporta un valor de cadena predeterminado que contendrá la URL del recurso y un componente React exportado con nombre que será de tipo componente funcional react. También necesitamos manejar estas importaciones en nuestro empaquetador en nuestro caso webpack. Más sobre cómo configurar webpack para lograr esto en una sección posterior. Como se mencionó antes, utilizamos la función de consulta de recursos de webpack.export para apuntar a un módulo. Por lo tanto, tuvimos que agregar una definición de módulo más aquí. Siempre que una ruta de origen de importación termine con un signo de interrogación id. Se tratará como un módulo que exporta por defecto una cadena. El punto de entrada para comprender los entresijos de todo lo que sucede cuando realmente se realiza una compilación durante el desarrollo o la producción es el archivo webpack.config.js. Se puede encontrar en el paquete de scripts de React en la base de código de create-react-app. El create-react-app utiliza muchos cargadores que se ejecutan uno tras otro para procesar CSS, como podemos ver aquí. El webpack comenzará desde un cargador post CSS que proporciona soporte para mixins, transpila la próxima sintaxis de CSS e imágenes en línea. Tiene algunos complementos que ayudan a insertar prefijos de proveedores en tu CSS. Webpack puede manejar las importaciones de JavaScript de forma predeterminada, pero no puede manejar las declaraciones de importación en CSS. Por ejemplo, cuando usamos la directiva de importación en CSS o la función URL en CSS, utiliza el cargador de CSS para resolverlos. Si decides usar Sass o CSS, es posible que debas agregar un cargador para preprocesarlo. El create react app utiliza el cargador de Sass. Como puedes ver aquí, entramos en el cargador de Sass.

Las aplicaciones CID manejan SVGs utilizando una biblioteca de terceros llamada SVGR. Esto es diferente al manejo de otros activos que son manejados directamente por webpack como se muestra aquí. Aquí podemos ver efectos secundarios. ¿Qué significa esto? ¿Cómo afecta al paquete final?

Esto nos lleva al siguiente tema, la eliminación de código muerto o pre-shaking. Las técnicas de optimización del paquete, como la eliminación de código muerto y el ofuscado, se activan de forma predeterminada en el modo de producción. Si no estamos en modo de producción pero aún queremos obtener alguno de estos beneficios de optimización, entonces tendremos que importar los complementos de optimización por nuestra cuenta. La eliminación de código muerto o pre-shaking elimina las funciones no utilizadas de todo el mundo comenzando desde el punto de entrada e incluyendo solo las funciones que pueden ser ejecutadas. Los componentes de orden superior de React dificultan la eliminación de código muerto por parte de Tercer. Para que la eliminación de código muerto funcione, debemos utilizar la sintaxis de módulo ES2015 o ES6, es decir, import y export. Debemos asegurarnos de que ningún compilador, cargador o complemento transforme nuestro código de sintaxis ES6 y superior en un módulo CommonJS. Como precaución, si estás utilizando Babel y usas el preset env de Babel, es posible que debas configurarlo para que no convierta los módulos ES6 a CommonJS, que es su comportamiento predeterminado. Volviendo al código, Tercive detectará las importaciones de CSS como no utilizadas, por lo tanto, intentará eliminarlas. Para evitarlo, debemos establecer el campo de efectos secundarios en Webpack como verdadero. Veamos cómo funciona Tree Seeking en Webpack con un ejemplo. En este ejemplo, el archivo de índice importa wrap-button, pero no lo utiliza. El complemento Tercer de Webpack intenta determinar si puede eliminar algún código de este archivo. Pero es posible que no pueda determinarlo si la llamada a la función button-wrapper tiene algunos efectos secundarios o no. Un efecto secundario podría ser algo como cambiar un valor en el objeto window u otra variable global. El código resaltado será eliminado una vez que hayamos agregado un comentario como este, que dice Puro. Pero todavía hay preguntas con las importaciones que deben incluirse o evaluarse porque podrían contener efectos secundarios. En otras palabras, Webpack recorrerá las dependencias en este módulo y determinará si los módulos importados tienen algún efecto secundario. Esto afectará el tiempo de generación del paquete y el tamaño del paquete. Una forma de evitar esto es indicarle a Webpack que ningún módulo en este paquete tiene efectos secundarios estableciendo el campo de efectos secundarios en el archivo package.json como falso. Imagina que estamos desarrollando un cuadro de diálogo que se abre después de hacer clic en algunos botones. Tenemos que cambiar el estado de la aplicación para finalmente abrir ese cuadro de diálogo. Esto se vuelve lento y molesto para los desarrolladores frontend abrir el cuadro de diálogo después de cada cambio que realizan en ese componente de cuadro de diálogo. La solución es reemplazar de alguna manera el módulo que contiene el componente de cuadro de diálogo durante el tiempo de ejecución, y esto se conoce comúnmente como reemplazo de módulo en caliente o HMR. En el contexto de React, surge una pregunta.

¿Cómo mantenemos el estado del componente después de que se haya reemplazado el módulo que contiene este componente? El complemento Fast Refresh de React se encarga de reaplicar el estado de la aplicación una vez que el módulo se ha recargado. Para lograr esto, necesita inyectar algo de código en cada módulo. Utilizamos el complemento Babel React Refresh para manejar esto por nosotros.

¿Cómo decidimos si los cambios realizados en el módulo deben provocar una recarga de página completa o un reemplazo en caliente del módulo? Para decidir si reemplazar en caliente el módulo o recargar la página completa, podemos implementar algunas comprobaciones en el módulo, como que todas las importaciones del módulo deben ser un componente de React para que el módulo sea elegible para HMR. Afortunadamente, implementar HMR para React es bastante fácil con herramientas de empaquetado como Webpack. Los empaquetadores de módulos como Webpack y Ruler han expuesto una API de HMR que se puede implementar en un módulo. Veamos el código.

Aquí estamos agregando un cargador de Babel que se ejecutará para todos los módulos de JavaScript y TypeScript fuera de los módulos de Node. Y el segundo y último paso es incluir el complemento React Refresh de Webpack en la configuración de Webpack. ¿Cómo hacemos HMR para archivos CSS y otros archivos similares? Durante el desarrollo, un complemento puede reemplazar los archivos CSS con módulos de JavaScript. Esto hace posible recargar en caliente los módulos de JavaScript para emular HMR para los archivos CSS. En Webpack, podemos usar tile loader para lograr esto. Si estás interesado en crear un marco de trabajo completo, puedes consultar nuestro repositorio de código abierto aquí. Puedes encontrarme en las redes sociales con este nombre de usuario. Gracias por escuchar.