Matando Bugs con Amabilidad

Un poco sobre mí, soy el mantenedor del proyecto de código abierto Atri Engine, que es un nuevo framework de desarrollo web de pila completa. También soy cofundador y CEO de Atri Labs, la empresa detrás de este proyecto. Con el framework Atri, se puede crear la parte frontal de un sitio web escribiendo código de React y su paquete en NodeJs, Python, etc. Hay muchas herramientas de productividad integradas en él, como un editor visual que se puede utilizar para crear la parte frontal de un sitio web y complementar tu código de React. Así es como se ve ese editor visual. Como puedes ver, hay numerosas interacciones en una página. Por ejemplo, podemos agregar componentes, darles estilo y moverlos. También podemos ver qué tan receptivo es nuestro sitio web haciendo clic en diferentes tamaños de pantalla.

Al crear este framework, para nuestro equipo fue muy importante entender y caracterizar antipatrones en nuestra gran base de código de React, porque un código subóptimo en una interacción puede afectar toda la aplicación. Además, el objetivo de nuestro framework es admitir la creación de sitios web de calidad de producción. Por lo tanto, para nosotros era muy importante establecer estándares internos rigurosos en cuanto a la calidad del código. En esta charla, compartiré los tipos de errores que hemos identificado en nuestra base de código y las barreras de protección que hemos implementado para evitarlos en el futuro. Cubriré cómo prevenir tres tipos de comportamientos inesperados en el código. Primero, un componente no se actualiza después de un evento del usuario. Segundo, el componente se actualiza parcialmente después de un evento del usuario, ya que el estado anterior aún está presente. Y tercero, el componente se renderiza de manera inesperada. Inicialmente, mientras construíamos nuestro framework, nos encontrábamos con estos errores repetidamente. Así que nuestro primer recurso fue usar declaraciones de impresión aleatorias como un verdadero desarrollador. Pero, por supuesto, más adelante tuvimos que crear algún método al respecto. Utilizamos un tema central para codificar pistas que sean fáciles de recordar y que nos puedan ayudar a identificar antipatrones. Y ese tema proviene de la documentación oficial de React, que establece que un código de React debe ser independiente de la secuencia en la que los componentes se renderizarán y cuándo se renderizarán. La primera pista es si estamos usando hooks sin un array de dependencias. Creemos que una forma de visualizar el código de React es como una colección de piezas de código interdependientes. Por lo tanto, si no se puede establecer una relación de dependencia en el código, es muy probable que esto resulte en errores. Así que si podemos llevarnos algo de esta charla, debería ser esto. Seamos tan paranoicos como Sharvi en este icónico episodio de Always Sunny cuando veamos o escribamos hooks como useState, useRef, etc., que no tienen arrays de dependencias. Otra forma de evitar el uso innecesario de useState es utilizando el contexto del controlador de eventos para almacenar el estado.

Estado. Aquí estoy demostrando esto usando el componente de deslizador personalizado. El código de la izquierda tiene antipatrones. Por ejemplo, hay cuatro useStates y tres callbacks. El estado de startPosition registra la posición inicial del cursor. El código de la derecha es su versión refactorizada. Observa que no tenemos ningún useState y solo un callback porque hemos utilizado el contexto local del callback para almacenar toda la información en curso relacionada con las interacciones del usuario. Cuando aplicamos esta refactorización a nuestro framework, pudimos reducir drásticamente la proporción de useState por componente. Nuestra proporción actual de número de useStates respecto al número total de hooks y componentes personalizados es de aproximadamente 1 a 3. Para darte una idea del tamaño de nuestra base de código, tiene alrededor de 100 hooks personalizados y alrededor de 200 componentes.

La siguiente pista para los antipatrones es si estás utilizando anidamiento para organizar componentes. Ten en cuenta que al usar anidamiento, si no prestas atención, es posible que pases estados duplicados a los hijos. Esto puede llevar a inconsistencias de estados entre el padre y los hijos. Recuerda que nuestro código debe ser independiente de la secuencia en la que los componentes se renderizarán. Además, debe haber una única fuente de verdad para cada estado, de lo contrario, esto resultará en errores.

Lo segundo a tener en cuenta aquí es que rastrear los cambios en el estado es el paso más lento en la depuración. Dado que el anidamiento permite cambios de estado en cada nivel, lleva más tiempo depurar.

La tercera pista es si estás utilizando muchos estados no controlados o muchos componentes no controlados. Somos conscientes de que hay un debate activo sobre el uso de componentes controlados, pero creemos que se deben preferir los componentes controlados, especialmente si el número de interacciones por página es alto. En nuestro framework, hemos logrado reducir los errores en más del 80% mediante el uso de componentes controlados.

Entonces, para resumir, ten mucho cuidado cuando uses hooks sin dependencias y cuando uses anidamiento para organizar componentes. Definitivamente debemos evitar dos antipatrones. El primero es usar props en el contexto o como estado inicial, y el segundo es usar el antipatrón de destruir y recrear. Como su nombre lo indica, este antipatrón se refiere a eliminar el componente del DOM y destruir todos los hooks y estados creados durante la primera llamada de función. Luego, se crea el componente nuevamente desde cero. Este antipatrón puede provocar problemas como el efecto de parpadeo.

Hay cuatro patrones de codificación que recomendamos a nuestros desarrolladores que prefieran para reducir los errores. El primero es usar props en JSX. El segundo, utilizar el contexto del controlador de eventos para almacenar el estado. Tercero, en lugar de intentar hacer que useState funcione de alguna manera con parches, cambia a un hook que tome dependencias como UseMemo. Y cuarto, utiliza componentes controlados siempre que sea posible. Gracias por escuchar. Estas son mis redes sociales. Si estás interesado en leer más sobre estos antipatrones, puedes consultar mi publicación en el blog. Allí discuto estos antipatrones con más detalle. También he utilizado una aplicación de ejemplo en el blog que demuestra estos antipatrones. Por último, este es el enlace al framework de desarrollo web de pila completa que estamos construyendo. Si estás interesado en contribuir a nuestro proyecto o compartir comentarios, por favor échale un vistazo. Y si te gusta lo que estamos construyendo, por favor comienza nuestro repositorio. ¡Gracias!