⚛️ De Props A Context Y De Ahí Al Desastre: Errores Que Me Enseñaron Más Que El Código

Son las 3 de la madrugada. Durante este sprint la procrastinación decidió colarse sin avisar y de pronto, heme aquí una noche antes del deadline, gran parte del trabajo del sprint se acumuló como si fuera una avalancha 🌊. El detonante: un gran refactor que, para ser honesto, nadie me pidió. Igualito que el meme, yo tenía grandes planes para refactorizar el componente en el que estoy trabajando. A la primera oportunidad que tuve, alguien en mi equipo propuso un "Generic Framework" para ayudar a minimizar el tiempo de desarrollo para integrar nuevas herramientas de terceros (lo siento, no puedo dar detalles pero creo que ha sido el trabajo más ambicioso de mi carrera profesional), y aproveché para proponer varios tickets con refactors que ya tenía mucho tiempo queriendo hacer, lo que no sabía era que me iba a meter el pie yo solito... es decir, sí es una solución para un problema real, pero con pasos extra para remediar las pobres técnicas que apliqué cuando entré a la empresa y era un poco más inexperto, y de paso resolver gran parte de la deuda técnica que sólo yo sabía que teníamos 😅. Como sea he aprendido de todos mis errores y siento que ya subí un nivel más, por eso decidí documentar esta experiencia para la posteridad.

En ese momento me encontraba odiando mi vida, peleando contra el sueño y peleando también con el Context API de React. Había creado varios, anidando Providers como si no hubiera un mañana, y metiendo lógica compleja en reducers. Todo se veía bonito, claro, pero aún con todo eso, me llega la famosa ✨punzada✨ para decirme que tal vez algo no está del todo bien por aquí.

¿Estoy abusando del context? —me pregunté—. ¿De verdad necesito tener casi absolutamente todo en un estado global?

Fue ahí cuando, medio dormido, necesitaba la aprobación de algún externo para mi hipótesis, y como tenía apuro, en vez de buscar en foros de Reddit, le pregunté a la IA si esto podía ser un problema. Spoiler: sí, en la mayoría de los casos. Resulta que para sorpresa de nadie, cada componente que consume un Context en específico, aunque no use directamente algún valor de una propiedad en el mismo, termina haciendo un re-render. Algo que claramente se me estaba olvidando por completo. Yo simplemente me estaba dejando llevar por lo fácil que era, quería evitar hacer prop-drilling de cualquier manera, pero cuando abusas de alguna técnica es inevitable que no tenga efectos secundarios.

Así que para fundamentar más mi hipótesis, necesitaba de una evidencia visual, ya sabía cuál iba a ser el resultado, pero igual uno debe de desconfiar siempre hasta de su propia sombra... Así que como el desarrollador profesional que soy, decidí debugear los re-renders con un console.log.

En efecto, es React 🚬⚛️

Te explico: Mi componente maneja una lista de items los cuales renderiza en diferentes secciones o hace uso de algunos items por separado, es por eso que lo manejo con un Context, el problema comenzó cuando decidí que el estado del formulario que añade items a esta lista, también la quería manejar en un estado global... por pereza y simplicidad, decidí que era buena idea guardar estos valores dentro del mismo context, pero ¡oh sorpresa! cada vez que el onChange se ejecutaba para actualizar el estado de estos valores, también "triggerea" un re-render a el componente que sólo se dedica a renderizar la lista de los items, algo totalmente innecesario, por supuesto.

Podrás decir que es parte de trabajar con React, una de las razones por las que he visto que le llueve hate a esta librería son por los re-renders innecesarios y lo díficil que es evitarlo (y la interminable lucha de frameworks, que si Angular o Vue son mejores, blah blah blah), y tal vez tengan razón. Lo que he aprendido es que a veces esos re-renders innecesarios no son un problema... hasta que lo son. Es cuando la experiencia y el criterio propio entra en juego, definir el balance entre dejarlo pasar, o tomar medidas preventivas para que esto no se convierta en un grave problema de rendimiento en el futuro.

Desafortunadamente no tenía energías suficientes para reestructurar todo. El sprint terminaba el día siguiente y prometí a mi manager que no habría carry-over... Y a lo mejor no es necesario hacer toda una reestructuración, así que mi solución fue dividir el estado en Context más específicos. Ya vi que parte del problema fue que, por pereza, metí demasiadas propiedades en un solo contexto general.

Siempre me pregunté el por qué usar librerías externas para manejar estado global si ya teníamos el Context API de React. Pero ahora empiezo a entenderlo. Incluso en casos que puedan parecer “simples”, estoy seguro que librerías como Zustand que se ha vuelto muy popular, puedan ofrecer soluciones para este tipo de problemas de rendimiento y con una interfaz muy ligera.

Me emociona mucho tener este tipo de revelaciones, ya que cobra más sentido este meme. Estoy casi seguro que en el futuro volveré a usar el Context API de React, o tal vez ya no esté usando para nada React...

Así que ya tengo varias tareas: investigar bien cómo funcionan otras librerías que manejan estados globales como Zustand, y de paso re-visitar otro tipo de soluciones, se me viene a la mente el patrón de diseño Observer, que quizás se aplique a algunos de mis casos de uso (o tal vez es lo mismo y aún no lo sé).

En fin. Lo importante es que hoy casi me convierto en el villano de mi propio refactor y nada me hubiera costado dejarlo como estaba, pero al menos me di cuenta a tiempo y pude terminar con una solución más aceptable.