Dr. Mario's 2nd 🧠

📖 The Road to React

3 min read

¿Por qué me leo esto?

Desde mi experiencia, tengo la sensación que cuando uno monta equipos de ingeniería con la idea de que la gente sea full-stack y trabaje con las funcionalidades end-to-end en mente, al final lo que uno acaba teniendo es un equipo de backend con capacidades muy mediocres en frontend. Hablo de no ser capaz de:

  • Gestionar estado de una manera “mantenible”, sin bugs a la mínima de cambio.
  • No provocar 200 re-renderizados (menos mal que los frameworks son rápidos renderizando).
  • Entender cómo funciona un formulario y no tener que reprogramarse toda la lógica de gestión del mismo.
  • Tener una apariencia… “pasable”. No te hablo ya ni de animaciones…

Buscaba desde hace tiempo algún libro que afrontara la tarea de “canonizar” las buenas prácticas en React, que tuviera en cuenta su “nueva normalidad” (hooks, uso de Context en lugar de meterme Redux a palazos…), y que me sirviera tanto para liberarme del boilerplate y solucionarme los casos de uso típicos, como para onboarding de full-stacks. Y ahora estando llevando Bistrohub, creo que es buen momento.

La documentación oficial de React está genial, pero su grano es demasiado fino: es difícil ver ejemplos completos que combinen distintas de sus herramientas.

De Reddit llegó la recomendación de este libro y la verdad que cumple. No lo he evaluado mejor porque sí que me hubiera gustado algo más de profundidad.

Apuntes

  • El recordatorio de que el “key” en las listas de elementos debería ser estable.

We avoid using the index of the item in the array to make sure the key attribute is a stable identifier. If the list changes its order, for example, React will not be able to identify the items properly.

Esto está de lujo explicado en la documentación de React: Lists and Keys - React

  • Nested de-structuring
const Item = ({ 
	item: { 
		title, 
		url, 
		author, 
		num_comments, 
		points, 
	}, 
}) => (
	<div>
     //Whatever your component does...
  </div>
);

  • Uso de useEffect para efectos secundarios, bien usado. Por ejemplo aquí para guardar en localStorage algo cada vez que cambia el estado.

  • Cómo inicializar un estado con una llamada a API

  • Uso apropiado de los callbacks, con memoización para evitar re-renderizar sin necesidad

  • ¿Un useState o múltiples?

There is nothing wrong with multiple useState hooks in one React component. Be wary once you see multiple state updater functions in a row, however. These conditional states can lead to impossible states, and undesired behavior in the UI.

Y luego todo el apartado de performance, que vendrá bien como referencia cuando lo necesite (como por ejemplo el memoized rendering).

Graph View

Backlinks