useEffect conlleva un cambio de mentalidad
¿Porqué tu equipo de desarrollo ya debería estar implementando React Hooks en tu proyecto?
Los ciclos de vida han estado con nosotros en el desarrollo hace un tiempo ya, yo los conocí por primera vez cuando intente aprender Android (no sabía programar ni sabía lo que estaba haciendo) pero entendí que las aplicaciones en mi teléfono pasaban por diferentes estados según abría, pausaba o cerraba una aplicación, y entendí que podía ejecutar acciones dentro de estas diferentes etapas de la aplicación, es por ello que cuando conocí los ciclos de vida de React, me hizo mucho sentido, pero al mismo tiempo solo podía ver claramente dos estados en web, cuando el componente se monta o coloca y cuando el componente se desmonta o se remueve, en realidad no hay necesidad de mucho más, ¿entonces porqué tantos ciclos de vida en React? cosas como ComponentShuldUpdate o ComponentWillReceiveProps, en realidad más que ciclos de vida React utiliza la mayoría de estos métodos para solventar la ausencia de una ejecución de efectos secundarios, a la hora de tomar la decisión de renderizarse o no, entre otras muchas inseguridades de una clase.
El Hook que sustituye estos ciclos de vida de una clase es sólo uno y se llama useEffect, principalmente porque el equipo de desarrollo de React llama efectos secundarios o “side effects” a las acciones realizadas antes o después de que un componente es renderizado, como por ejemplo consumir datos de una API, colocar callbacks o quitarlos así como hacer llamadas a otros servicios.
Si quieres saber más sobre React hooks clic aquí.
Los tres ciclos de vida que se comprimen en useEffect son: componentDidMount, componentDidUpdate y componentWillUnmount, los ciclos de vida que no están contemplados por ahora en Hooks son componentDidCatch y getDerivedStateFromError (hablando de la versión v16.8) aunque el equipo de desarrollo de react ha comentado que planean incluirlos más adelante.
useEffect; Un cambio de mentalidad.
Al hablar de useEffect, debemos concentrarnos justo en eso, en los efectos secundarios, por años los desarrolladores React hemos entendido los componentes como un proceso de montado, desmontado y actualización, del cual es muy difícil salir, este Hook, no solo sustituye los ciclos de vida de la clase Component, si no que también viene a hacer un cambio de mentalidad pues para usarlo en todo su potencial debemos dejar de verlo cómo tres ciclos de vida comprimidos en 1, que es como normalmente se enseña.
Para poder dominarlo y entrar al nuevo paradigma de desarrollo con React Hooks debemos dejar de pensar en “Este componente hace esto al ser montado” el cambio de mentalidad debe ser: “Este componente debe realizar los siguientes efectos secundarios”.
De esta forma no solo colocaremos un [] en este hook pensando en montar y desmontar si no que pensamos en cómo nuestro estado cambia y por consiguiente el componente debe re dibujar estos cambios, por ejemplo, normalmente pensamos que al montarse el componente debemos traer desde una API, datos con un id que obtuvimos desde props, pero al pensar en montar y desmontar nunca consideramos que el componente debería traer de nuevo los datos si el id cambia, y de allí surgen muchos de los problemas que tenemos con React los que ya lo usamos para proyectos reales, nuestros datos cambian pero como nuestro componente ya está montado, para poder traer de nuevo los datos no podemos desmontar y volver a montar (muchos lo intentan, si, yo sé que haz usado location.reload() no lo niegues) así que tenemos que comparar el state o los props y terminamos usando otros 3 ciclos de vida como componentWillReceiveProps, shouldComponentUpdate o peor aún forceUpdate(), solo para reflejar un cambio, mientras que con el cambio de mentalidad de useEffect, nosotros podemos “observar” por llamarlo de alguna manera, los datos de nuestro componente y si existe un cambio podemos ejecutar las acciones necesarias para generar los efectos secundarios de este cambio, si no quisiéramos observar ningún estado, useEffect se ejecuta cada vez que el componente se renderiza (no todo el tiempo), asegurándose de que los efectos secundarios al renderizado se ejecuten. Es entonces que dejamos de pensar en montar y desmontar.
Cuando comencé a explorar Hooks supe desde el principio que sería un paradigma diferente, que tendríamos que reaprender a escribir componentes, que terminaríamos reescribiendo nuestras apps, que la forma de enseñar React evolucionaría, que sería más accesible para mucho y más complejo con el tiempo, pero todo esto por el desuso de las clases, este pensamiento se reforzó en mí cuando comencé a olvidarme de this en mis componentes, a tener acceso directo a mis diferentes states, cuando no necesité implementar Redux en la mayoría de mis proyectos gracias a useContext, pero ahora que puedo ir más profundo en el uso de useEffect, que dejo de visualizarlo cómo un ciclo de vida y comienzo a verlo como lo que es; una herramienta maravillosa para ejecutar efectos secundarios según el cambio de mi state, independientemente si el componente esta montado o no. Es en estos momentos que estoy completamente convencido de que React Hooks es un parteaguas del desarrollo a base de componentes.
Escribir componentes funcionales con React Hooks, no solo te dará mayor velocidad y te permitirá reciclar prácticamente todos tus componentes, también te hará un mejor desarrollador, y si tienes un equipo de desarrollo que está usando React, deberías motivarlo para que comience a usar Hooks, lo cual hará que tu producto pueda crecer más rápido, tenga features más complejos y sea mucho más compatible. ¿Porqué? porque crear componentes con React Hooks es más fácil, más rápido, es disfrutable, fomenta la creatividad y sobre todo son más sustentables (no tienen que ser monstruos con clases enromes).
Si ya estas haciendo Hooks; bienvenido a la nueva era de ReactJS.
