Por qué React no es magia: lo entendí cuando dejé de pelearme con los renders

#react #performance #javascript #frontend

Cuando empecé a usar React, había algo que me frustraba más que los warnings rojos en consola: no entendía por qué mis componentes se renderizaban cuando yo “no había tocado nada”.

Era como si React tuviera vida propia.
Un día funcionaba perfecto, al siguiente estaba renderizando como si le debieran dinero.

Con el tiempo (y muchos cafés), me di cuenta de que no era React… era yo.
O más bien, era que yo no entendía cómo React tomaba decisiones, por decirlo de alguna manera.

Este post es justo sobre eso: cómo dejé de ver el render como magia negra y empecé a entenderlo paso a paso.

🧩 OK... empecemos. Lo primero que entendí: React renderiza más de lo que imaginamos

Yo creía que “renderizar” era sinónimo de “modificar el DOM”.
Y no. Para nada.

React siempre hace un render interno: recalcula, compara, analiza.
Pero eso no significa que vaya a tocar el DOM cada vez.

La primera vez que hice esto, algo hizo clic en mi cabeza:

function Counter() {
  const [count, setCount] = useState(0);

  console.log("Render...");

  return (
    <div>
      <p>Contador: {count}</p>
      <button onClick={() => setCount(count + 1)}>Sumar</button>
    </div>
  );
}

Cada clic = un render.
Pero el DOM… tranquilo, sin movimientos innecesarios.

Ese fue mi primer “aha moment 🥸☝🏼”.

🔁 Luego descubrí la parte dolorosa: los renders en cascada

Tenía un componente padre que actualizaba un estado, y un hijo que solo mostraba un texto.
Nada del otro mundo… hasta que vi que el hijo estaba renderizando con cada letra que escribía.

function Parent() {
  const [text, setText] = useState("");

  return (
    <>
      <input value={text} onChange={e => setText(e.target.value)} />
      <Child value={text} />
    </>
  );
}

function Child({ value }) {
  console.log("Child renderizado");
  return <p>{value}</p>;
}

Mi reacción:🤬
“¿Por qué el hijo también? ¡Si solo cambió el input!”

React:🥱
“Amigo… el padre cambió. ¿Qué esperabas?”

Ahí entendí otra verdad incómoda:
cuando un padre renderiza, sus hijos van con él — aunque no te guste.

⚙️ Y finalmente entendí el antídoto (cuando de verdad hace falta)

No todo se arregla con useMemo, useCallback o React.memo.
De hecho, yo los usaba como si fueran vitaminas diarias. Error.

Pero cuando el render empieza a afectar la experiencia, ahí sí ayudan.

El primer verdadero alivio lo sentí así:

const Child = React.memo(function Child({ value }) {
  console.log("Child renderizado");
  return <p>{value}</p>;
});

Con eso:

El input fluía sin lag

El hijo solo renderizaba cuando su prop cambiaba

Y yo dejé de sentir que React me estaba saboteando

¿La moraleja?
La optimización sirve cuando hay un problema real, no cuando estás nervioso y optimizas por reflejo.

🔍 Lo que realmente me cambió la perspectiva

Hubo una frase que me cambió todo:

React no intenta adivinar lo que quieres.
Solo responde a los cambios que tú mismo provocas, aunque no te des cuenta.

Cuando entendí eso, muchas cosas se acomodaron:

Pensé mejor dónde vive cada estado
Dejé de pasar props inútiles
Empecé a evitar renders por costumbre
Y escribí componentes con más intención

De repente, esos “renders misteriosos” dejaron de aparecer.

🏁 Conclusión/Aprendizaje

No escribo esto porque sea experto en renders, sino porque durante mucho tiempo me parecieron un misterio.
Y cuando finalmente los entendí, React dejó de ser frustrante y se volvió divertido.

Si tú también sentiste alguna vez que React “renderiza por capricho”, espero que este post te dé claridad.

La próxima semana voy a hablar de algo que todos usamos, pero pocos entienden realmente:
useMemo y useCallback — cuándo sí sirven y cuándo solo estorban.

Nos leemos 👋