React es fácil de empezar y también fácil de desordenar. La diferencia entre un código que da gusto mantener y uno que asusta rara vez está en trucos avanzados: suele estar en algunos hábitos simples. Estas buenas prácticas de React son para quienes ya escriben componentes, pero quieren dejar de repetir los mismos tropiezos.
Componentes pequeños, una sola responsabilidad
El mejor componente es el que hace una cosa y la hace bien. Cuando un componente empieza a mezclar obtención de datos, lógica de negocio y mucho JSX, se convierte en un nudo difícil de entender y de probar.
Algunas señales de que ya es hora de dividirlo: tienes que desplazarte mucho para leer todo el componente, contiene varios fragmentos de estado que no se relacionan entre sí o dudas al ponerle un nombre porque hace demasiadas cosas. Dividirlo pronto es más barato que desenredarlo después.
Estado lo más cerca posible de quien lo usa
Una tentación común es llevar todo el estado al nivel superior "para facilitar las cosas". Casi siempre ocurre lo contrario: cuanto más lejos está el estado de quien realmente lo usa, más componentes se vuelven a renderizar sin necesidad y más difícil resulta seguir el flujo.
Deja cada fragmento de estado en el componente que lo necesita. Solo sube el estado —el famoso "lifting"— cuando dos componentes realmente necesitan compartir la misma información y, aun así, súbelo solo hasta el ancestro común más cercano, ni un nivel más.
useEffect no significa "hazlo cuando se renderice"
Este es el malentendido que más bugs genera entre quienes están aprendiendo. useEffect existe para sincronizar tu componente con algo externo a React: una solicitud de red, un evento del DOM, un temporizador o una suscripción. No es un hook genérico de "ejecuta este código en cada renderizado".
Si estás usando un efecto solo para calcular un valor a partir de props o estado, probablemente no necesites ningún efecto. Consulta la siguiente sección.
Deriva, no dupliques
Guardar en el estado una información que se puede calcular a partir de otra es buscar problemas de sincronización: tarde o temprano, las dos copias dejarán de coincidir. Si tienes una lista de elementos y quieres obtener el total, no guardes el total en un estado separado: calcúlalo al renderizar. Menos estado significa menos cosas que mantener sincronizadas y menos formas de equivocarse.
Las keys de las listas no son decoración
Cuando renderizas una lista, React usa la key para saber qué elemento es cuál entre un renderizado y otro. Usa como key un id estable de los datos.
El atajo de usar el índice del array parece inofensivo y funciona, hasta que la lista se reordena, recibe un elemento en medio o pierde uno. Entonces React se confunde sobre lo que cambió y puedes ver que el estado termina en el elemento equivocado. Un id estable resuelve esto sin esfuerzo.
Props y nombres que se explican por sí mismos
El código bueno se lee casi como un texto. Nombra los componentes y las props según su intención, no según su apariencia: isLoading dice más que flag, y onConfirm dice más que handleClick2.
También desconfía cuando un componente acumula demasiadas props booleanas (isBig, isPrimary, isDisabled, isRound...). Suele ser una señal de que intenta ser varios componentes al mismo tiempo. Y ahí volvemos a la primera regla: divídelo en piezas más pequeñas.
Ninguna de estas prácticas es sofisticada, y precisamente ese es el punto. Componentes pequeños, estado en el lugar correcto, efectos solo para sincronizar y datos derivados en vez de duplicados: al combinarlo todo, obtienes una base de código que crece sin convertirse en un campo minado. React lo agradece, y tu yo del futuro también.
