Forem: Leonardo Trujillo

React Actions: el cambio más grande 🤯

Leonardo Trujillo — Tue, 27 Jan 2026 20:32:25 +0000

Si pensabas que el "estado" era lo único complicado en React, prepárate. React 19 trae algo que, a primera vista, parece una cosa más en la lista de "cosas nuevas que aprender", pero que en realidad es una patada en la mesa de cómo hemos manejado la interactividad hasta ahora. Hablo de las React Actions, y sí, el título no es clickbait: presiento que no todos lo entenderemos o entendimos bien. Y no te culpo, al principio yo también pensé: "¿otra abstracción más?". Pero no, esto es diferente.

¿Qué son las Actions y por qué importa su existencia? 🤔

Para simplificarlo sin perder el humor: las Actions son la respuesta de React a la pregunta: "¿Cómo podemos hacer que la interacción con el servidor sea menos... manual?". Durante años, hemos lidiado con isLoading, isError, data, setData, try/catch y toda una coreografía de estados locales para manejar el envío de un formulario o cualquier otra interacción asíncrona. Era un infierno de boilerplate.

Las Actions vienen a ser una especie de "directiva" que le dices a React: "Oye, cuando este evento ocurra (por ejemplo, un submit de un formulario), quiero que ejecutes esta función que probablemente interactúa con tu amigo el servidor". Pero lo crucial aquí es que React toma el control de la ejecución, el manejo de estados pendientes, errores y, lo más importante, la revalidación.

Imagina que eres un director de orquesta y, en lugar de decirle a cada músico cuándo tocar y cuándo parar, simplemente les dices: "Cuando yo haga esto, ustedes tocan esta sinfonía completa y ya se encargan de los detalles". Eso son las Actions. Menos micro-gestión, más delegación.

¿Cómo cambian los formularios y por qué es una maravilla (a medias)? 📝

Los formularios son el caso de uso estrella de las Actions. Antes, un formulario típico en React era algo así:

function MyOldSchoolForm() {
  const [name, setName] = useState('');
  const [email, setEmail] = useState('');
  const [isLoading, setIsLoading] = useState(false);
  const [error, setError] = useState(null);

  const handleSubmit = async (e) => {
    e.preventDefault();
    setIsLoading(true);
    setError(null);
    try {
      await fetch('/api/submit', {
        method: 'POST',
        body: JSON.stringify({ name, email }),
      });
      // Lógica de éxito, limpiar formulario, etc.
    } catch (err) {
      setError(err.message);
    } finally {
      setIsLoading(false);
    }
  };

  return (
    <form onSubmit={handleSubmit}>
      {/* Inputs y botones */}
      {isLoading && <p>Enviando...</p>}
      {error && <p style={{ color: 'red' }}>Error: {error}</p>}
    </form>
  );
}

Ahora, con las Actions, la cosa se simplifica drásticamente. Podemos vincular una función directamente al action prop de un <form>, y React se encarga del resto. Esto es especialmente potente con useFormStatus y useFormState (que veremos en otro post, ¡no te precipites!).

// En tu archivo del servidor o en un Server Component si usas Next.js/RSC
'use server'; // Opcional, pero muy común para Server Actions

async function submitForm(formData) {
  const name = formData.get('name');
  const email = formData.get('email');
  // Lógica de validación y envío al DB/API
  await new Promise(resolve => setTimeout(resolve, 1000)); // Simula un delay de red
  if (name === 'error') {
    throw new Error('Nombre no permitido.');
  }
  console.log('Formulario enviado:', { name, email });
  // revalidatePath('/') // Si estás en Next.js, por ejemplo
  return { message: 'Formulario enviado con éxito!' };
}

// En tu componente de cliente
function MyNewSchoolForm() {
  return (
    <form action={submitForm}>
      <input type="text" name="name" placeholder="Tu nombre" />
      <input type="email" name="email" placeholder="Tu email" />
      <button type="submit">Enviar</button>
      {/* Aquí usaríamos useFormStatus o useFormState para mostrar el estado */}
    </form>
  );
}

Fíjate en la magia: ¡no hay useState para isLoading o error dentro del componente del formulario! React, a través de sus nuevos hooks, nos proporciona esa información. Es como si el formulario mismo supiera lo que está pasando, sin que tengamos que programárselo explícitamente. Adios boilerplate, hola... ¿magia negra?

La relación con Server Components / Next.js: ¿es un amor verdadero o una relación complicada? 💘💔

Aquí es donde la cosa se pone picante. Las Actions, si bien pueden usarse en el cliente (aunque con menos superpoderes), alcanzan su máximo potencial cuando se combinan con los Server Components (RSC).

Cuando una Action se ejecuta en un Server Component, la función que asignas al action prop es ejecutada directamente en el servidor. Esto significa que puedes manejar la lógica de base de datos, llamadas a APIs sensibles, etc., sin exponer nada en el cliente. Es una forma increíblemente segura y eficiente de manejar mutaciones.

🚀 Un pequeño "duh" para los que pensaban que las Server Actions eran solo para Next.js: No, amigo. Next.js las ha implementado de forma brillante, pero el concepto de Server Actions (y por ende, las React Actions) es una característica de React 19 que otras soluciones (como Remix) también están adoptando o planean adoptar. Es la visión de React de un mundo más integrado entre cliente y servidor.

¿Por qué importa esta relación?

Seguridad: Las credenciales y la lógica sensible nunca tocan el navegador.
Rendimiento: Menos JavaScript enviado al cliente, ya que la lógica de mutación vive en el servidor.
Simplicidad: Adiós a la necesidad de crear endpoints API dedicados para cada pequeña mutación. Ahora, tu función de mutación puede vivir justo al lado de tu componente (o en un archivo separado marcado como 'use server').
Coherencia de datos: React es capaz de revalidar el caché de datos de forma "inteligente" después de una Action exitosa, asegurando que tu UI refleje el estado más reciente del servidor sin que tengas que refrescar la página manualmente. ¡Es como tener un useEffect mágico que solo se dispara cuando tiene sentido!

Conclusión: Prepárense para cambiar su chip 🧠

React Actions no son un simple azúcar sintáctico; son un cambio fundamental en cómo pensamos la interacción en una aplicación React. Nos empujan a considerar el "lado servidor" de nuestras aplicaciones de una manera mucho más integrada y menos separada.

Si aún estás en la fase de "¿qué demonios es esto?", no te preocupes. Estamos todos en el mismo barco. Pero la clave es empezar a internalizar que React está buscando reducir drásticamente el boilerplate para interacciones comunes y, de paso, acercar el desarrollo frontend al backend de una forma que hace unos años era impensable.

Así que, respira hondo, y prepárate para un mundo donde el onSubmit ya no es el único protagonista. Las Actions llegaron para quedarse, y su potencial es, francamente, aterradoramente emocionante.

¡Hasta el próximo post! 😁

React 19 - Primer post del año

Leonardo Trujillo — Wed, 14 Jan 2026 22:06:13 +0000

He vuelto después de unas ligeras vacaciones, no quiero perder la constancia así que aquí vamos de nuevo 😅

Después de publicar mi último post sobre el Profiler de React, tenía
planeado seguir con la serie de rendimiento y arquitectura.
Pero mientras revisaba la documentación y empezaba a leer sobre React
19, me pasó algo curioso:

En lugar de querer seguir con la serie… me dieron ganas de detenerme y
hablar de esto primero.

Decidí hacer una pausa para hablar de la nueva versión.
No desde el hype, no desde el changelog, sino desde la mirada de alguien
que usa React en proyectos reales.

Este post es el inicio de una mini-serie sobre React 19:
qué cambia, qué no, qué vale la pena mirar… y qué todavía conviene tomar
con calma.

Cuando ves "React 19" podrías pensar:
"Ok, React con más mejoras".

Pero no.

La versión no cambia tanto la API…
cambia más la forma en la que React quiere que pensemos las apps.

Cada vez empuja más hacia:

Menos lógica manual en formularios.
Más integración entre servidor y cliente.
Menos boilerplate para manejar estados async.
Más enfoque en experiencia de usuario.

React ya no quiere ser solo una librería para pintar componentes.
Quiere ayudarte a construir aplicaciones completas.

Algo importante que noté rápido

se entiende mucho mejor cuando lo ves junto a frameworks como:

Next.js
Remix
Frameworks con Server Components

Si vienes de React puro con Vite o CRA, algunas cosas pueden sentirse
raras o incluso innecesarias.

Y eso es clave:

Esta nueva versión no está pensado para todos los proyectos por igual.

Y eso, para mí, es algo positivo.

Qué sí cambia de verdad

Sin entrar todavía en ejemplos técnicos, React 19 trae mejoras reales
en:

Formularios y acciones.
Estados de carga, error y éxito.
UX asíncrona más natural.
Integración server ↔ client.
Manejo de transiciones y estados optimistas.

Pero lo mejor:

👉 No te obliga a usarlas.
👉 No rompe tu forma actual de trabajar.
👉 No te dice “así se hace ahora o estás mal”.

Suma herramientas, no reemplaza.

Qué no cambia

React sigue siendo React:

Componentes.
Props.
Estado.
Hooks.
Composición.

No necesitas reaprenderlo.
Solo necesitas entender qué nuevas opciones tienes cuando las necesites.

Para mí, el cambio es más mental que técnico
No te grita:
"Tienes que migrar ya".

Más bien te dice:
"Si quieres, aquí tienes nuevas formas de hacer las cosas".

Y ahí está la parte interesante:

No todo debe vivir en el cliente.
No todo formulario debe ser un infierno.
No todo estado async debe ser manual.
No toda UX tiene que sentirse torpe.

Pero también:

No todos los proyectos necesitan esto hoy.
No todos los equipos están listos.
No todo vale la pena migrar.

Cómo seguirá esta mini-serie

En los próximos posts voy a hablar de:

React Actions.
Formularios en React 19.
useOptimistic y UX.
Server Actions vs estado en cliente.

Pero este primer post solo tenía un objetivo:

Dejar claro que esta nueva versión no es obligatoria…
pero sí es interesante.

No es una moda.
Tampoco es algo milagroso.

Es solo otra herramienta más.
Y como todas, depende de cómo y cuándo la uses.

Nos leemos 👋

Cómo usar el Profiler de React para medir renders de verdad (y dejar de adivinar)

Leonardo Trujillo — Fri, 28 Nov 2025 19:06:05 +0000

Hubo un punto en mi carrera donde me di cuenta de algo simple:
estaba optimizando React a ciegas.

Sabía que algunos componentes renderizaban más de lo necesario, intuía que había funciones recreándose sin motivo… pero la mayoría de las veces estaba adivinando.
Y cuando optimizas sin medir, puedes terminar "arreglando" cosas que no estaban rotas.

Fue ahí cuando empecé a usar el Profiler de React, y honestamente, me cambió la forma de entender cómo mis componentes se comportaban en tiempo real.

Este post es justo sobre eso:
cómo aprovechar el Profiler para ver lo que realmente pasa… y no lo que asumimos que pasa.

🧭 El Profiler: una herramienta que todos deberían utilizar

React Developer Tools incluye una pestaña llamada Profiler.
No es tan famosa como el “Components” o el “Hooks”, pero es quizá la más útil cuando quieres mejorar rendimiento.

El Profiler te permite:

Ver cuántas veces se renderiza un componente
Ver por qué se renderizó
Medir el tiempo que tomó cada render
Entender qué parte del árbol está causando más trabajo
Comparar renders antes y después de una optimización

Antes de usarlo, mis suposiciones eran eso: suposiciones.
Después, tenía datos concretos.

📌 Cómo empezar a usarlo

Instala React DevTools (si no lo tienes).
Abre tu app en modo desarrollo.
Ve a la pestaña Profiler.
Haz clic en “Record”.
Interactúa con la app normalmente.
Detén la grabación.

Instantáneamente verás una gráfica con barras de colores.
Cada barra representa un render del árbol de componentes.

Si algo se está renderizando demasiado, lo verás ahí, sin necesidad de adivinar.

🔍 Lo que más me ayudó a entender

1. Los "renders silenciosos" existen

Hay componentes que crees que se renderizan una o dos veces… y resulta que van por la décima.

El Profiler muestra exactamente cuántas veces se repintó un componente.

2. No todos los renders son malos

Ver muchos renders no significa que tu app está mal.
Lo que buscas es:

renders muy frecuentes
componentes muy costosos
cascadas innecesarias desde un padre
o cálculos que duran más de lo razonable

React está diseñado para renderizar mucho sin problemas.
El profiler te dice cuándo sí es un problema.

3. Los patrones "costosos" saltan a la vista

Cosas como:

funciones recreadas sin necesidad
arrays y objetos nuevos en cada render
componentes hijos que dependen demasiado del padre
llamadas innecesarias a APIs o cálculos

Antes lo intuía.
Ahora puedo señalar exactamente dónde pasa.

🛠️ Un ejemplo práctico

Supongamos que tienes una lista grande:

function List({ items }) {
  return items.map(item => <Item key={item.id} item={item} />);
}

Desde fuera todo parece normal.
Pero al perfilar, notas que List se renderiza en cada interacción, incluso una interacción que no tiene nada que ver con la lista.

Ahí empiezas a cuestionarte:

¿El estado está en el lugar correcto?
¿Estoy pasando props que cambian en cada render?
¿Necesito React.memo en Item?

El Profiler te da el tipo de información que no obtienes leyendo código:
qué pasa realmente, no qué crees que pasa.

🚦 Qué sí hacer después de perfilar

Revisar si un cálculo tarda más de lo esperado
Identificar componentes que se renderizan demasiado
Ver si useMemo o React.memo harían una diferencia
Confirmar si una optimización realmente funcionó
Ajustar estados que deberían vivir en otros componentes

🛑 Qué NO hacer

Optimizar algo solo porque aparece muchas veces
Memoizar todo “por si acaso”
Añadir useCallback sin que un hijo lo necesite
Asumir que un render costoso es siempre un problema (no siempre lo es)

📘 Lo más importante que aprendí

El Profiler me ayudó a dejar de programar "por intuición" cuando se trata de performance.

Hoy optimizo menos, pero optimizo mejor.
Ya no dependo de suposiciones:
si un componente está causando problemas, el Profiler me lo confirma.

🏁 Lección aprendida

Si nunca has usado el Profiler de React, te recomiendo dedicarle 10 minutos a explorarlo.
Es una herramienta sencilla, pero te da claridad inmediata sobre cómo realmente funciona tu UI.

En el siguiente post voy a mostrar cómo interpretar una sesión completa del Profiler y cómo convertir esos datos en mejoras concretas.

Nos leemos 👋

useMemo y useCallback: cuándo sí sirven… y cuándo solo estorban

Leonardo Trujillo — Fri, 21 Nov 2025 18:53:55 +0000

Hubo una etapa de mi vida como desarrollador donde pensaba que optimizar React significaba una cosa:
agregar useMemoy useCallback a todo lo que se moviera.

Si veía un cálculo, un array filtrado, una función…
“Memoízalo, por si acaso. No vaya a ser que React sufra.”

Y sí, React sufría… pero por culpa mía.

Este post es sobre cómo dejé de usar memoization como si fuera una aspirina para todo, y aprendí a aplicarla solo donde realmente aporta algo.
Si alguna vez te ha pasado que agregas useMemo y tu app va más lenta, créeme, estás en el lugar correcto.

🧩 La sobre-optimización que me estrelló contra la realidad

En uno de mis primeros proyectos grandes, tenía una lista enorme que se re-renderizaba seguido. Yo, muy confiado, pensé:

"¿Cuál es la mejor forma de optimizar React?
Fácil: memorizo todo 🥸☝🏼"

Y lo hice.
Cada función: useCallback.
Cada array: useMemo.
Cada cálculo: useMemootra vez.
Y practicamente así con todo ^_____^

Pero algo raro pasó:
la interfaz no iba más rápida… iba peor.

Se sentía "pesada", como si React estuviera peleando contra sí mismo.

Después recibí un feedback que me dejo pensando mucho:

"Leo… no puedes optimizar algo que no sabes si necesita optimización."

Y ahí me cayó el veinte.

⚙️ La revelación: memoization NO hace tu código más rápido

Yo pensaba que useMemo y useCallbackeran como un "modo turbo".
Pero la realidad es más simple y más dura:

useMemo evita un cálculo costoso
→ Solo si ese cálculo es realmente costoso.

useCallback evita que una función cambie de referencia
→ Solo si esa función se pasa a un componente memoizado.

Antes de eso, yo memorizaba filtros que tardaban 1 ms.
O funciones que ni siquiera pasaba como prop.

Era como ponerle cinturón de seguridad a una bicicleta estacionada.

🔍 useMemo en la vida real (no en el tutorial)

El propósito real:

const sortedList = useMemo(() => {
  return heavySortFunction(list);
}, [list]);

Si heavySortFunction tarda 100 ms, esta línea te salva la vida.
Si tarda 0.5 ms, estás haciendo más trabajo del necesario.

💭 El momento en el que lo entendí

Un día estaba perfilando una app y me di cuenta de algo ridículo:
mi useMemo estaba tardando MÁS en comparar dependencias que el cálculo real que intentaba optimizar.

Ahí fue cuando dije: "Ok React, te escucho. Ya entendí."

🔧 useCallback: el primo que todos usan mal

Antes:
useCallback(() => console.log("hola"), [])
en todos lados.

Ahora sé que esta regla es real:

Si tu hijo no está memoizado, tu useCallback no sirve.

Ejemplo real en producción:

const handleClick = useCallback(() => {
  doSomething();
}, []);

Si luego haces:

<Child onClick={handleClick} />

🚦 Cuándo SÍ usar memoization (sin culpa)

Sin drama, sin misterio:

✔️ 1. Cuando un cálculo es verdaderamente pesado

Filtro gigante, sort complejo, cálculos matemáticos, parseo.

✔️ 2. Cuando pasas funciones a un componente memoizado

Ese es el matrimonio perfecto:
React.memo + useCallback.

✔️ 3. Cuando tienes listas enormes o renders costosos

Si tienes 300 items en pantalla → ahí sí vale la pena.

🛑 Cuándo NO usar memoization (cerrando ciclos tóxicos)

Esto me cambió la vida:

❌ Cuando es “por si acaso”

La sobre-optimización es el cardio del sufrimiento.

❌ Cuando lo que optimizas es rápido

No hay nada que ahorrar.

❌ Cuando el hijo no está memoizado

useCallback ahí es placebo.

❌ Cuando el componente es pequeño

Un memo innecesario solo añade complejidad.

📌 Mi checklist personal (para evitar recaer)

Antes de usar useMemo o useCallback, pregúntate:

¿Esto realmente es costoso?

¿Estoy evitando recrear algo que sí afecta a un hijo memoizado?

¿Tengo forma de medirlo?

¿Si lo quito, pasa algo?

¿Estoy optimizando para un caso real o para sentirme "más pro"?

Si la respuesta honesta es NO…
ciérralo.
No memorices.

🏁 Lección aprendida

Después de entender esto, dejé de pelearme con memoization y empecé a verla como lo que es:
una herramienta quirúrgica, no una cinta adhesiva para todo.

Hoy optimizo menos, pero optimizo mejor.
Y React me lo agradece.

En el próximo post voy a hablar del Profiler de React y cómo medir renders de verdad, sin adivinar.

Nos leemos 👋

useMemo y useCallback: cuándo sí sirven… y cuándo solo estorban

Leonardo Trujillo — Fri, 21 Nov 2025 18:53:55 +0000

Hubo una etapa de mi vida como desarrollador donde pensaba que optimizar React significaba una cosa:
agregar useMemoy useCallback a todo lo que se moviera.

Si veía un cálculo, un array filtrado, una función…
“Memoízalo, por si acaso. No vaya a ser que React sufra.”

Y sí, React sufría… pero por culpa mía.

🧩 La sobre-optimización que me estrelló contra la realidad

En uno de mis primeros proyectos grandes, tenía una lista enorme que se re-renderizaba seguido. Yo, muy confiado, pensé:

"¿Cuál es la mejor forma de optimizar React?
Fácil: memorizo todo 🥸☝🏼"

Y lo hice.
Cada función: useCallback.
Cada array: useMemo.
Cada cálculo: useMemootra vez.
Y practicamente así con todo ^_____^

Pero algo raro pasó:
la interfaz no iba más rápida… iba peor.

Se sentía "pesada", como si React estuviera peleando contra sí mismo.

Después recibí un feedback que me dejo pensando mucho:

"Leo… no puedes optimizar algo que no sabes si necesita optimización."

Y ahí me cayó el veinte.

⚙️ La revelación: memoization NO hace tu código más rápido

Yo pensaba que useMemo y useCallbackeran como un "modo turbo".
Pero la realidad es más simple y más dura:

useMemo evita un cálculo costoso
→ Solo si ese cálculo es realmente costoso.

useCallback evita que una función cambie de referencia
→ Solo si esa función se pasa a un componente memoizado.

Antes de eso, yo memorizaba filtros que tardaban 1 ms.
O funciones que ni siquiera pasaba como prop.

Era como ponerle cinturón de seguridad a una bicicleta estacionada.

🔍 useMemo en la vida real (no en el tutorial)

El propósito real:

const sortedList = useMemo(() => {
  return heavySortFunction(list);
}, [list]);

Si heavySortFunction tarda 100 ms, esta línea te salva la vida.
Si tarda 0.5 ms, estás haciendo más trabajo del necesario.

💭 El momento en el que lo entendí

Un día estaba perfilando una app y me di cuenta de algo ridículo:
mi useMemo estaba tardando MÁS en comparar dependencias que el cálculo real que intentaba optimizar.

Ahí fue cuando dije: "Ok React, te escucho. Ya entendí."

🔧 useCallback: el primo que todos usan mal

Antes:
useCallback(() => console.log("hola"), [])
en todos lados.

Ahora sé que esta regla es real:

Si tu hijo no está memoizado, tu useCallback no sirve.

Ejemplo real en producción:

const handleClick = useCallback(() => {
  doSomething();
}, []);

Si luego haces:

<Child onClick={handleClick} />

🚦 Cuándo SÍ usar memoization (sin culpa)

Sin drama, sin misterio:

✔️ 1. Cuando un cálculo es verdaderamente pesado

Filtro gigante, sort complejo, cálculos matemáticos, parseo.

✔️ 2. Cuando pasas funciones a un componente memoizado

Ese es el matrimonio perfecto:
React.memo + useCallback.

✔️ 3. Cuando tienes listas enormes o renders costosos

Si tienes 300 items en pantalla → ahí sí vale la pena.

🛑 Cuándo NO usar memoization (cerrando ciclos tóxicos)

Esto me cambió la vida:

❌ Cuando es “por si acaso”

La sobre-optimización es el cardio del sufrimiento.

❌ Cuando lo que optimizas es rápido

No hay nada que ahorrar.

❌ Cuando el hijo no está memoizado

useCallback ahí es placebo.

❌ Cuando el componente es pequeño

Un memo innecesario solo añade complejidad.

📌 Mi checklist personal (para evitar recaer)

Antes de usar useMemo o useCallback, pregúntate:

¿Esto realmente es costoso?

¿Estoy evitando recrear algo que sí afecta a un hijo memoizado?

¿Tengo forma de medirlo?

¿Si lo quito, pasa algo?

¿Estoy optimizando para un caso real o para sentirme "más pro"?

Si la respuesta honesta es NO…
ciérralo.
No memorices.

🏁 Lección aprendida

Después de entender esto, dejé de pelearme con memoization y empecé a verla como lo que es:
una herramienta quirúrgica, no una cinta adhesiva para todo.

Hoy optimizo menos, pero optimizo mejor.
Y React me lo agradece.

En el próximo post voy a hablar del Profiler de React y cómo medir renders de verdad, sin adivinar.

Nos leemos 👋

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

Leonardo Trujillo — Fri, 14 Nov 2025 23:26:24 +0000

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 👋

Por qué decidí compartir lo que sé (y lo que sigo aprendiendo) sobre desarrollo web

Leonardo Trujillo — Thu, 06 Nov 2025 01:02:51 +0000

Después de varios años construyendo productos web — desde sitios que apenas cargaban hasta apps complejas con muchos usuarios — entendí algo que suena obvio, pero que muchos olvidamos o al menos yo olvidé: aprender solo no tiene el mismo valor que aprender y compartir.

Así que decidí abrir este espacio.
No para presumir lo que sé, sino para poner en palabras las cosas que me hubiera gustado leer cuando empecé (y también las que sigo descubriendo hoy).

Cada semana voy a publicar un post sobre desarrollo frontend, React, performance y buenas prácticas. Desde lo más básico hasta temas más avanzados, con ejemplos reales, errores que me dolieron y soluciones que me funcionaron.

Si te interesa construir experiencias web más rápidas, entendibles y humanas, te invito a seguirme en este viaje.

⚙️ Tecnologías que suelo usar: React, Next.js, TypeScript, Tailwind, Redux, y todo lo que ayude a crear productos con impacto real.

🚀 Mi meta personal: compartir, aprender con la comunidad.

Nos leemos cada semana (espero 😬).

— Leo Trujillo