Ahora que React es super popular y que es casi un obligado para el desarrollo web o por lo menos es un obligado como primer herramienta a aprender para crear página/sitios web aunque después puedas brincar a otro framework más interesante como Svelte o Vue o te arrojes a los brazos de la anarquía con puro VanillaJs o incluso te vayas a lo profundo con WebAssembly yo creo que antes de dar esos brincos React estará entre las herramientas de tu cinturón.

Y bueno, los recursos para aprenderlo sobran, hay miles literalmente. Entre libros, blogs, tutos incluso podcast 100% dedicados a React y si entras a youtube y escribes React, pff.

Aquí te dejo mi curso también, por si quieres aprender React conmigo

Pero React en sí mismo evoluciona constantemente cada año y por eso usar su documentación oficial (que además está en español 💙) como fuente de verdad, es la mejor idea. 🥷🏼

Pero aún con todo esté mar de información, cuando trabajo con recién llegados al desarrollo web, e incluso con desarrolladoras(es) que ya llevan más de 4 de años de experiencia, me encuentro con que por alguna razón aún tienen malas prácticas al escribir sus componentes o al estructurar sus patrones de diseño y jerarquías y ni hablar de su flujo de datos.

Pareciera que aprender React es muy fácil, lo difícil llega cuando hay que estructurar un grupo de componentes u ordenar la lógica de un archipielago de componentes que cooperan entre sí. Por eso quiero enseñarte (o recordarte, si ya las conoces) las 5 buenas prácticas básicas en React que deberías conocer.

1. Crea más customHooks

Inmediatamente que detectes que has escrito la misma lógica para 2 componentes, crea un customHook y NO TE REPITAS para eso son, incluso para las lógicas más simples.

Esto tiene una infinidad de beneficios entre los cuales está el crear un fundamento de lógica reutilizable que se convierte en tu aliado para añadirte velocidad como desarrollador porque puedes usarlo en diferentes proyectos a través del tiempo. Incluso va evolucionando contigo conforme vas mejorando además de que crear tus propios customHooks es una gran forma de llegar a convertirte en una creadora de librerías donde la reusabilidad es el núcleo.

Así que la próxima vez que necesites formatear ese número a pesitos (1499 => $1,499.00) escribe tu propio useMoney

2. useState siempre es para casos locales, no globales

Es tan simple como se lee. useState es para uso del componente únicamente. El estado global debe entrar al componente a través de props así como las mutaciones de ese estado global, deben ocurrir a través de callbacks/métodos que se proveen ya sea por props también o por alguna herramienta que los provea como Redux actions dejando los useStates para copias locales de ese estado global (para filtrar por ejemplo) o estados básicos del componente como saber si un modal está activo o no, esto evita que tus componentes muestren estados que no concuerdan y que el prop drilling sea insostenible.

También decir en este punto que si tu app necesita de un estado global, debes tomarte el tiempo de usar una herramienta para administrarlo, hoy en día hay muchas opciones. Desde la más popular (Redux), hasta la más simple (Context) pasando por el server side rendering que puede evitar por completo esta administración.

3. Tu CSS va en el mismo JS

Este punto es muy "opinionated" es decir, que es algo controversial, recuerda que en el mundo del desarrollo siempre hay muchísimas formas de hacer/conseguir buenos resultados, algunos métodos son más eficientes y otros más sencillos, a mí me encanta este mundo porque se necesita de criterio para tomar desiciones y respaldarlas de forma inteligente para poder discutirlas con personas más inteligentes que tú y aún así que tu justificación haga sentido (es un mundo intelectual, de gente que piensa. Y eso es muy bonito).

Dicho esto. Si tu proyecto va a crecer, los archivos .css/.scss son insostenibles. No importa cuantas buenas prácticas tengas en tu nomenclatura (.container-navbar-logged-link__step-1) créeme, a largo plazo nadie va a volver a leer esas clases para modificarlas, reusarlas o actualizarlas, siempre se tiende a crear nuevas, sustituirlas o volverlas a escribir aunque ya exista alguna que hace exactamente lo mismo, ¿por qué? Porque el css es muy difícil de leer y más difícil de comprender sobre todo si no lo escribiste tú y peor aún si está escrito con identación (como con sass o less) haciendo que tus hojas de estilo que repiten lo mismo muchas veces agreguen mucho peso extra que en realidad no necesitas en tu app.

¿La alternativa? CSS in JS tener los estilos en el mismo componente es sostenible, además de ir muy bien con la filosofía de el aislamiento de un componente que posee todo en su mismo dominio/scope React ya hizo esto con el JSX ¿por qué no hacerlo con el CSS?, Emotion, styled-components entre varias más.

Una alternativa similar a esto son las librerías que te permiten usar CSS sin convertirlo en JavaScript y que también son muy populares y fáciles de usar, además cuentan con una comunidad enorme que las ama, como son Tailwind y ChakraUI <= (este es mi favorito personal 😉) Ya te hablaré más sobre Chakra y Framer-motion para darle vida a tus apps con micro-animaciones.

4. Escribe pruebas para tus componentes al mismo tiempo que los documentas

A nadie le gusta escribir test, la neta. Aquellos que los escriben o los obligan (en su trabajo) o entienden los beneficios con claridad, pero aún así dudo mucho que lo hagan sonriendo. Ya escribiré sobre los muchos beneficios que tiene hacer unit testing en tus componentes además de ser beneficioso cuando hablas de "integración continua", pero por ahora quedémonos con que es algo MUY BUENO, pero sip, tedioso.

Por eso existen herramientas e iniciativas bien chéveres que intentan cambiar la forma en la que nos acercamos al "testing" para hacerlo menos tedioso, (porque ya dijimos que es necesario) uno de esos "approach" es el Component Story Format (CSF), que no sólo es una herramienta también es un paradigma de desarrollo, comenzar a desarrollar tu app desde un sandbox que te permita jugar con tu componente al punto de que cuando esté terminado, ya incluya las pruebas "accidentalmente" (Si quieres leer más sobre esto, te dejo estos links: Github, Storybook y Cypress es un tema muy interesante). Invertir algunas semanas en implementar pero sobre todo entender porque Storybook es una buena idea vale la pena, si te llevas algo de en este post que sea esto.

5. Usa TS en vez de JS

Por último: Agregar tipos a tus componentes y hooks es lo mejor que le pudo pasar a React.

Puedo hablar muuucho sobre porque TS es muy benéfico para tus programas, y para ti como developer, es un paso adelante en tu carrera, pero sobre todo en la calidad de tu código.

Typescript prácticamente elimina la probabilidad de usar incorrectamente un componente en tiempo real es decir, inmediatamente que escribes <Componente /> Typescript estará señalando cada uno de los props necesarios para este componente así como checar el tipo correcto que se le pasa a cada uno, ahorrándote una cantidad invaluable de tiempo que YA NO INVERTIRÁS "debugueando" y te permitirá trabajar con equipos grandes sin que se estén pisando la cola.

Además tendrás una linterna poderosa que te ayudará en cada linea de código que escribas, muchos developers aún no usan TS, lo que pone en ventaja la calidad de tu código y te pone en ventaja a ti como developer "outlier" .

Si quieres saber más sobre qué es TS te dejo una entrada de mi blog personal 🤓

Podría seguir con mas buenas prácticas que he aprendido con el tiempo como: composición de forma correcta o el uso correcto de los "fragments", pero lo dejaré para una futura entrada.

Por ahora si alguna de estas 5 es nueva para ti, te recomiendo la abordes con ganas, para que sigas mejorando como React dev y destaques cada vez más.

Te mando un abrazo.

Happy coding ⚛️

Bliss.