Mira el video:
¿Cuáles errores puedes estar cometiendo escribiendo código de React?
🎬 Este artículo está basado en este video de YouTube, si te gusta más el video aquí lo tienes.
Regularmente tratamos de evitar patrones que sabemos que son erróneos, como no dejar pasar las props directamente al state del componente hijo, o no utilizar propTypes (aunque nadie quiere usar propTypes por eso usamos TypeScript).
Pero también, hay patrones que aunque parecen inofensivos, podrían causarte problemas.
Veamos 3 patrones que vas a querer evitar.
1. Inicializar state usando propiedades
Este patrón se refiere a utilizar las propiedades (props) que se reciben en un componente para inicializar su estado interno. Entiéndase que el useState se ejecutará solo la primera vez que el componente es montado, eso quiere decir que el valor inicial de este estado nunca cambiará, así que es posible que una diferente ejecución de tu padre con nuevos valores para las propiedades del componente hijo, no resulte en un estado actualizado correcto para tu componente hijo ya que el useState mantiene los valores con los que la instancia fue montada originalmente. Que el padre cambié no desmonta al hijo.
¿Cuál es el patrón?
¿Cómo evitarlo o arreglarlo?
Preferir el uso directo de los props.
Utiliza useEffect para sincronizar el estado con alguna propiedad.
🎬 ¿Te está gustando este contenido? Tenemos más tutoriales en video en nuestro canal de YouTube.
2. Usar índice como key
Este patrón se refiere a utilizar el índice del map cuando estamos usando una lista:
Esto no es necesariamente malo, esta práctica es inofensiva, es muuuuy común, y bastante sencilla.
Pero definitivamente la respuesta al ¿Cuándo si puedo usar un índice? Es...
Cuando tenemos una lista estática, sin orden relevante y sin posibilidad de ser modificada, puedes utilizar el índice de la iteración como key.
¿Cuál es el problema?
Si añadimos un nuevo elemento o lo eliminamos de la lista de nuestra iteración: La reconciliación de React puede resultar en una corrupción de los resultados ya que confundirá un elemento de la lista con otro.
¿Cómo evitarlo o arreglarlo?
Preferir el uso del ID, u otra propiedad que sea distinta para cada elemento de la lista. Siempre que la lista esté sujeta a cambios.
3. Usar spread operator para pasar props
Este patrón no recibe suficiente atención porque no es algo que te lastime al día de hoy pero puede convertirse en algo muy difícil de debuggear mañana.
Este patrón se refiere a expandir todas las propiedades de un objeto en el componente:
Normalmente para que no tengas que escribir de forma explícita cada una de ellas.
¿Cuál es el problema?
Añadir una propiedad al componente puede crear un conflicto con el objeto "props".
Si el objeto props incluye un onClick, la línea anterior no será explícita sobre cuál de los dos onClick se está refiriendo.
¿Cómo evitarlo o arreglarlo?
Preferir la desestructuración de las propiedades, especificando primero las propiedades que sí usarás, y después expandiendo lo que sobre con el operador rest (los 3 puntos).
De esta forma sabemos siempre que onClick tiene los valores que nosotros le estamos pasando y el resto puede variar.
Conclusión
La programación con patrones nos ayuda a comunicarnos mejor entre developers, tenemos un lenguaje común que nos permite hablar de soluciones (y errores) de forma general, es verdad que lo anterior no representa errores necesariamente, solo que pueden resultar en comportamientos inesperados por eso se clasifican como anti-patterns.
Abrazo. bliss.
¿Por qué deberías usar Cloudflare Workers?
Checa este otro Post
