Explora cómo Jordan Walke y React introdujeron componentes reutilizables, vistas declarativas y renderizado dirigido por estado, transformando la arquitectura frontend moderna.
Jordan Walke es un ingeniero de software conocido por crear React mientras trabajaba en Facebook. Antes de React, los frontends se construían a menudo alrededor de páginas, plantillas y una creciente pila de “código pegamento” que intentaba mantener HTML, CSS y JavaScript sincronizados. La idea clave de Walke fue invertir el modelo: en lugar de tratar la UI como un conjunto de documentos que parcheas con el tiempo, trátala como un árbol de pequeños componentes reutilizables que compones en características más grandes.
Esto no fue solo una nueva librería: fue una nueva forma de pensar sobre el trabajo de UI. Un componente agrupa una pieza de la interfaz con la lógica y el estado que necesita, y luego expone una interfaz limpia (props) al resto de la aplicación. Eso hace que la UI se sienta más como construir con piezas de Lego que como editar una única página frágil.
React importó porque ayudó a los equipos a:
Recorreremos las ideas prácticas que hicieron a React influyente:
No necesitas ser un experto en frameworks para seguir esto. El objetivo es clarificar el modelo mental—para que reconozcas buenos patrones de React, evites conceptos erróneos comunes y apliques los mismos principios fuera de React.
Antes de React, muchos equipos construían interfaces ricas hilando plantillas, manipulación del DOM al estilo jQuery y una creciente pila de reglas “cuando ocurre X, actualiza Y”. Funcionaba—hasta que la UI se volvía compleja.
Un patrón común era: obtener datos, renderizar HTML y luego adjuntar manejadores de eventos que mutaban el DOM directamente. En el momento en que cambiaba el estado (un nuevo elemento, un error de validación, un toggle), alguien tenía que recordar cada lugar que dependía de ello.
Eso llevaba a bugs como:
A medida que las pantallas evolucionaban, las mismas reglas de negocio terminaban duplicadas en múltiples handlers: “deshabilitar el botón si el campo está vacío”, “resaltar elementos no leídos”, “mostrar estado vacío si no hay resultados”. Cuando cambiaban los requisitos, había que buscar en archivos no relacionados para actualizar cada copia.
Los datos pueden modelarse con unas pocas estructuras claras: una lista de posts, un objeto usuario, un conjunto de filtros. La UI, sin embargo, añade combinaciones: carga vs. cargado, error vs. éxito, leído vs. no leído, edición vs. visualización, filtrado vs. sin filtrar—a menudo todo a la vez.
Imagina un feed de noticias:
Sin una regla predecible como “la UI es una función del estado”, terminas coordinando muchas ediciones del DOM que pueden entrar en conflicto. La meta de React fue hacer las actualizaciones confiables: cambia los datos/estado y la UI se vuelve a renderizar para coincidir—cada vez.
Un componente es una pequeña parte de la interfaz de usuario que puedes nombrar, reutilizar y razonar sobre ella de forma aislada. En lenguaje llano: un componente toma entradas y devuelve cómo debería verse la UI para esas entradas.
Ese encuadre “entradas → salida” es el corazón del modelo de componentes. En lugar de tratar una pantalla como una gran plantilla, la divides en bloques con propósito—botones, tarjetas, menús, formularios y secciones completas—y luego los ensamblas.
En React, las entradas más comunes son las props (propósito de “propiedades”). Las props son valores que pasas a un componente para configurarlo: texto, números, flags, manejadores de eventos o incluso otra UI.
La salida es la UI que el componente renderiza. Si las props cambian, el componente puede producir una salida distinta—sin que tú busques manualmente dónde actualizar el DOM.
Por ejemplo, un componente Button puede recibir props como label, disabled y onClick. Un UserCard puede recibir name, avatarUrl y status. Puedes leer la interfaz del componente (sus props) igual que leerías una especificación de producto: “¿Qué necesita esta UI para renderizar correctamente?”
Dividir la UI en componentes da frutos rápidamente:
Modal, Input o Dropdown puede aparecer en varias páginas.Esto supone un gran cambio respecto a copiar y retocar marcado por página. Los componentes hacen que la duplicación parezca innecesaria—y con el tiempo, inaceptable.
React te anima a diseñar UI como diseñarías un sistema: como partes componibles. Una “página de Checkout” se convierte en un árbol de componentes—CheckoutPage que contiene OrderSummary, ShippingForm y PaymentMethod. Cada parte tiene entradas claras y una responsabilidad definida.
Ese cambio—pensar primero en componentes—es una de las razones por las que React modificó la arquitectura frontend. Dio a los equipos una unidad compartida de diseño y desarrollo: el componente.
El mayor cambio mental de React es la UI declarativa: describes cómo debe ser la interfaz para un estado dado, y React se encarga de actualizar la página cuando ese estado cambia.
En lugar de localizar elementos, editar texto, alternar clases y mantener el DOM sincronizado, te concentras en la “forma” de la UI. Cuando los datos cambian, la UI se vuelve a describir y React calcula el conjunto mínimo de cambios necesarios.
JSX es una forma conveniente de escribir la estructura de un componente usando una sintaxis parecida al HTML dentro de JavaScript. No es un nuevo lenguaje de plantillas que debas aprender desde cero; es una abreviatura para “este componente renderiza este árbol de elementos”.
El beneficio clave es que el marcado y la lógica que decide qué mostrar conviven, lo que hace que los componentes sean más fáciles de entender en aislamiento.
El código imperativo se centra en cómo actualizar la UI paso a paso:
// Imperativo: mantener el DOM sincronizado manualmente
function setLoggedIn(isLoggedIn) {
const el = document.querySelector('#status');
el.textContent = isLoggedIn ? 'Welcome back' : 'Please sign in';
el.classList.toggle('ok', isLoggedIn);
el.classList.toggle('warn', !isLoggedIn);
}
El código declarativo se centra en qué debe ser la UI para el estado actual:
function Status({ isLoggedIn }) {
return (
\u003cp className={isLoggedIn ? 'ok' : 'warn'}\u003e
{isLoggedIn ? 'Welcome back' : 'Please sign in'}
\u003c/p\u003e
);
}
Porque el render se expresa como una descripción pura, los componentes tienden a ser más legibles, más fáciles de revisar y más simples de refactorizar. Diseñadores, ingenieros con enfoque en producto y compañeros nuevos suelen seguir JSX sin buscar entre manejadores de eventos y mutaciones del DOM.
Esta claridad mejora la colaboración: las decisiones de UI son visibles en un solo lugar y los cambios tienen menos probabilidades de crear efectos secundarios ocultos en otra parte de la interfaz.
“El estado” es simplemente los datos que pueden cambiar con el tiempo mientras un usuario interactúa con la UI. Puede ser el texto actual en un cuadro de búsqueda, si un menú está abierto, los elementos en un carrito o el resultado de una petición de red. Si puede cambiar y la pantalla debe reflejar ese cambio, es estado.
La jugada clave de React es tratar el render como una consecuencia del estado, no como una secuencia de pasos manuales en el DOM. Describes cómo debe ser la UI para un estado dado. Cuando el estado se actualiza, React vuelve a renderizar las partes relevantes.
Ese modelo mental difiere de “encuentra un elemento, luego actualiza su texto, luego alterna esta clase”. En su lugar, actualizas el estado y la UI se actualiza de forma natural porque se deriva de ese estado.
El flujo de datos en una sola dirección significa que los datos se mueven en una sola vía:
props.Esto reduce sorpresas porque puedes seguir la trayectoria de una actualización: ocurre un evento, el estado cambia en un lugar y la UI vuelve a renderizarse desde ese nuevo estado. Hay menos ambigüedad de “¿quién cambió este valor?”.
function Counter() {
const [count, setCount] = React.useState(0);
return (
\u003cdiv\u003e
\u003cp\u003eCount: {count}\u003c/p\u003e
\u003cbutton onClick={() =\u003e setCount(count + 1)}\u003eAdd\u003c/button\u003e
\u003c/div\u003e
);
}
Aquí, count es estado. Hacer clic en el botón actualiza el estado con setCount. React vuelve a renderizar y el párrafo muestra el nuevo número. Nunca editas el DOM directamente.
El mismo patrón escala a filtrar listas (estado = texto del filtro, UI = elementos filtrados) o a la validación de formularios (estado = valores y errores de campos, UI = mensajes). Los datos cambian primero; la vista es solo el resultado.
La idea clave de React no es “redibujar la página más rápido”. Es: tratar la UI como el resultado del estado y, cuando el estado cambia, comparar lo que quieres ahora con lo que tenías antes—luego actualizar solo lo que realmente cambió.
Cuando cambia el estado o las props de un componente, React ejecuta tus componentes otra vez para producir una nueva descripción de la UI. Piénsalo como tomar dos instantáneas:
En lugar de limpiar el DOM y reconstruirlo, React intenta calcular el conjunto mínimo de operaciones DOM necesarias para pasar de A a B.
El “DOM virtual” es simplemente la representación en memoria de la UI de React: un árbol ligero de elementos (y la salida de los componentes) que describe lo que debe estar en pantalla. No es un segundo navegador ni un DOM más rápido. Es una estructura de datos que React puede inspeccionar y comparar eficientemente.
La reconciliación es el proceso de descubrir qué cambió entre el árbol virtual anterior y el siguiente. React usa heurísticas para hacerlo rápidamente, como:
<div> no es un <span>)keys) ayudan a identificar ítems en listas para que React pueda emparejar “el mismo elemento” entre rendersUna vez que React sabe qué cambió, aplica actualizaciones puntuales al DOM real.
Esto no es magia. El rendimiento depende de los patrones: keys estables, evitar re-renders innecesarios, mantener el trabajo del componente pequeño y no hacer cálculos caros durante el render. React puede reducir el churn del DOM, pero tu estructura de componentes y el flujo de datos siguen determinando qué tan fluida se siente la app.
El mayor truco de escalado de React no es una bandera de función ni un plugin: es la composición: construir pantallas anidando componentes, pasando datos via props y usando children para permitir que un componente “envuelva” otra UI.
Cuando los equipos adoptan la composición, dejan de pensar en páginas únicas y comienzan a pensar en pequeñas partes fiables que se pueden reordenar sin reescribirlo todo.
childrenEl anidado es la versión visual de la estructura de la UI: una página contiene secciones, que contienen tarjetas, que contienen botones. Las props son las perillas de configuración (texto, estados, callbacks). Y children es cómo creas componentes que dan estructura permitiendo a quien los usa decidir qué va dentro.
Un buen modelo mental: props personalizan, children rellenan, el anidado ensambla.
Componentes de layout definen estructura y espaciado sin poseer lógica de negocio. Ejemplos: Page, SidebarLayout, Stack, Modal. A menudo dependen de children para que el mismo layout envuelva muchas pantallas.
Inputs reutilizables estandarizan el comportamiento y estilo de formularios: TextField, Select, DatePicker. En lugar de copiar etiquetas, estados de error y mensajes de validación en cada pantalla, centralizas esas decisiones y expones una simple API de props.
Componentes lista/ítem mantienen la UI repetida predecible. Una división común es ItemList (fetching, paginación, estados vacíos) más ItemRow (cómo se ve una entrada). Esto facilita cambiar el render sin romper el manejo de datos.
Los hooks son la forma moderna de reutilizar comportamiento con estado (como toggles, estado de formularios o fetches) entre componentes sin forzarlos a tener la misma forma de UI. Esa separación ayuda a los equipos a evolucionar el diseño mientras mantienen la lógica consistente.
La composición es cómo los sistemas de diseño se mantienen consistentes: los componentes se convierten en los bloques aprobados y los layouts definen reglas de espaciado y jerarquía. Cuando el sistema actualiza—colores, tipografía, estados de interacción—los productos heredan mejoras con menos ediciones manuales.
El estado es solo “datos que pueden cambiar”. En React, dónde vive ese estado importa tanto como el propio estado.
El estado local pertenece a un solo componente (o un widget pequeño) y no necesita ser leído en otro lugar. Piensa: si un dropdown está abierto, el valor actual de un input o qué pestaña está seleccionada.
Mantener ese estado local reduce la coordinación y hace los componentes más reutilizables. Una buena regla: si solo un componente lo necesita, no lo exportes al resto de la app.
El estado compartido es dato que varias partes de la UI deben concordar. Ejemplos comunes:
Cuando múltiples componentes necesitan la misma fuente de verdad, duplicar estado conduce a desajustes (“el header dice 3 ítems, la página del carrito dice 2”).
Elevar el estado: mover el estado al padre común más cercano y pasarlo hacia abajo por props. A menudo es la opción más simple y mantiene el flujo explícito.
Context: útil cuando muchos componentes necesitan el mismo valor sin “prop drilling”, como tema o auth. Context es mejor para preocupaciones de alcance app relativamente estables.
Stores externos: cuando el estado crece en complejidad (actualizaciones frecuentes, datos derivados, workflows entre páginas), una store dedicada puede centralizar la lógica y las actualizaciones.
El flujo unidireccional de React brilla cuando hay un dueño claro para cada pieza de estado. Busca una única fuente de verdad donde sea práctico y deriva lo demás (contadores, totales, listas filtradas) desde ese estado en lugar de almacenar duplicados.
La mayor victoria diaria de React no es un truco de render: son los límites de componentes que convierten el trabajo de UI en cambios más pequeños y seguros. Cuando un componente tiene una responsabilidad clara y una “superficie” pública estable (sus props), los equipos pueden refactorizar internals sin forzar reescrituras a lo largo de la app. Esa estabilidad facilita las revisiones de código, reduce roturas accidentales y ayuda a los nuevos miembros a entender dónde hacer cambios.
Un modelo mental útil es: dadas props y estado, un componente debería describir la UI de forma predecible. Aunque existen efectos y APIs del navegador, la mayor parte de la lógica de un componente puede permanecer determinista. Por eso las pruebas mantenibles en React a menudo se centran en comportamiento y salida:
props/estado específicos y aserta qué pueden ver y hacer los usuarios.Las comprobaciones de accesibilidad encajan naturalmente aquí: si pruebas usando roles y nombres accesibles, detectas etiquetas faltantes, estados de enfoque rotos y semántica inconsistente temprano. Chequeos de consistencia (linting, formateo, uso del sistema de diseño) refuerzan la misma idea: los componentes predecibles son más fáciles de mantener.
Cuando los componentes exponen una API pequeña de props y ocultan detalles de implementación, varias personas pueden trabajar en paralelo—uno ajusta estilos, otro cambia el fetch de datos, otro actualiza pruebas—sin estorbarse mutuamente.
Props forman una API pequeña y estable (evita props “sarten” con todo).props en profundidad.El rendimiento en React suele ser menos sobre “React es lento” y más sobre cuánto trabajo le pides al navegador. La UI más rápida es la que hace menos: menos nodos DOM, menos layout/reflow, menos cálculos caros y menos viajes de red.
Un problema frecuente son las re-renderizaciones innecesarias: un pequeño cambio de estado provoca que un gran subárbol vuelva a renderizar porque el estado vive demasiado arriba o porque las props cambian de identidad constantemente (nuevos objetos/funciones creados inline).
Otro punto clásico son las listas pesadas—centenares o miles de filas con imágenes, formato y manejadores. Aunque cada fila sea “barata”, el trabajo total se acumula y el scroll se vuelve entrecortado.
Empieza por la estructura:
También enfócate en lo que los usuarios perciben: reduce la latencia de entrada, acelera el primer paint significativo y mantiene interacciones suaves. Mejorar en 20 ms una interacción frecuente puede importar más que recortar 200 ms en una pantalla rara.
El estado derivado es dato que puedes calcular a partir de otro estado/props (como fullName desde firstName + lastName, o items filtrados desde una lista + query). Almacenarlo suele crear bugs: ahora tienes dos fuentes de verdad que pueden desviarse.
Prefiere computar valores derivados durante el render (o memoizar la computación si es cara). Guarda solo lo que no puedes derivar—típicamente entrada del usuario, respuestas del servidor e intención de la UI (como “panel abierto?”).
React no solo introdujo una forma más agradable de escribir UI; empujó a los equipos a reorganizar cómo se construyen, comparten y mantienen los frontends. Antes de que los componentes fueran el modelo mental por defecto, muchos proyectos trataban la UI como páginas con scripts y plantillas dispersas. Con React, la unidad de arquitectura pasó a ser cada vez más el componente: una pieza de UI con una API clara (props) y comportamiento predecible.
React encajó con el auge de las single-page applications (SPAs). Cuando el render está gobernado por estado, la “página” deja de ser una plantilla servida por el servidor y pasa a ser la composición de componentes más el ruteo del cliente. Ese cambio hizo habitual estructurar el código alrededor de áreas de funcionalidad y partes de UI reutilizables en lugar de archivos HTML separados.
Una vez que la UI se construye con piezas reutilizables, es natural estandarizarlas. Muchas organizaciones pasaron de copiar/pegar marcado a construir librerías de componentes: botones, controles de formulario, modales, primitivas de layout y patrones como estados vacíos. Con el tiempo, esas librerías evolucionaron a sistemas de diseño—componentes compartidos más guías—para que los equipos puedan lanzar experiencias consistentes sin reinventar la UI en cada pantalla.
Los componentes impulsaron que los equipos nombraran las cosas de la misma manera. Cuando todos hablan de un <Button>, <Tooltip> o <CheckoutSummary>, las conversaciones se vuelven más concretas: la gente discute comportamientos y límites, no solo apariencia. Ese vocabulario compartido también ayuda a los nuevos miembros a incorporarse más rápido porque el sistema se descubre mediante el código.
El éxito de React influyó en cómo la comunidad frontend pensó sobre UI: desarrollo component-first, render declarativo y flujo de datos predecible se volvieron expectativas comunes. Otros frameworks adoptaron ideas similares, aun cuando los detalles de implementación diferían, porque las prácticas subyacentes demostraron ser más fáciles de escalar en equipos reales.
React ganó reputación por facilitar la evolución de UIs complejas, pero no es “gratis”. Conocer las compensaciones ayuda a adoptar la tecnología por las razones correctas y a evitar decisiones de imitación.
React tiene una curva de aprendizaje: componentes, hooks y modelos mentales como actualizaciones de estado y efectos llevan tiempo. El React moderno también asume tooling (bundling, linting, TypeScript opcional pero común), lo que añade configuración y mantenimiento. Finalmente, React introduce capas de abstracción—librerías de componentes, ruteo, patrones de fetch—que pueden ser útiles pero también ocultar complejidad hasta que algo falla.
“React es solo la vista.” En teoría sí; en la práctica, React moldea fuertemente tu arquitectura. Los límites de componentes, la propiedad del estado y los patrones de composición influyen en el flujo de datos y en cómo los equipos organizan el código.
“El DOM virtual siempre es más rápido.” El DOM virtual trata principalmente de actualizaciones predecibles y ergonomía para desarrolladores. React puede ser rápido, pero el rendimiento depende de patrones de render, memoización, tamaños de listas y evitar re-renders innecesarios.
React es una buena opción para apps con muchos estados interactivos, bases de código duraderas y múltiples desarrolladores trabajando en paralelo. Para un sitio de marketing mayormente estático o un puñado de widgets pequeños, opciones más simples (templates server-side, JS ligero o frameworks mínimos) pueden ser más fáciles de enviar y mantener.
Si estás prototipando una app en React y quieres validar estas ideas rápido (límites de componentes, propiedad del estado, patrones de composición), un flujo de trabajo de prototipado rápido puede ayudar. Por ejemplo, Koder.ai te permite describir características en chat y generar un frontend React funcional más un backend Go/PostgreSQL, luego iterar con snapshots/rollback y exportar el código fuente cuando estés listo para tomar el control manualmente. Es una manera práctica de probar decisiones de arquitectura en una característica real antes de comprometerte a una construcción completa.
Próximo paso: prototipa una funcionalidad real, mide complejidad y velocidad del equipo, y escala los patrones de forma deliberada—no por defecto.
Jordan Walke creó React mientras trabajaba en Facebook. React importó porque reemplazó el frágil “pegamento” del DOM y las actualizaciones manuales con un enfoque basado en componentes y dirigido por el estado, lo que facilitó escalar, depurar y mantener interfaces complejas.
Los templates suelen esparcir reglas de UI entre marcado y controladores de eventos dispersos ("cuando ocurre X, actualiza Y"). Los componentes agrupan UI + lógica detrás de una interfaz pequeña (props), de modo que puedes componer funcionalidades desde piezas predecibles en lugar de parchear páginas con el tiempo.
Un componente es una unidad reutilizable que toma entradas (normalmente props) y devuelve cómo debe verse la UI para esas entradas.
En la práctica, procura:
props pequeña y legibleLas props son las entradas que pasas a un componente para configurarlo (texto, flags, callbacks u otra UI). Trátalas como un contrato:
disabled, onSubmit) frente a objetos vagosprops cambie la salida de forma natural (evita mutar el DOM manualmente)UI declarativa significa describir qué debe ser la interfaz para el estado actual, no cómo actualizar el DOM paso a paso.
En la práctica:
JSX es una sintaxis que te permite escribir la estructura de la UI con una apariencia similar al HTML dentro de JavaScript. Es útil porque el marcado y la lógica de renderizado conviven, lo que hace que un componente sea más fácil de leer y revisar como una unidad.
El estado es cualquier dato que puede cambiar con el tiempo y que debe afectar lo que el usuario ve (texto de inputs, estado de carga, contenidos del carrito, etc.).
Una regla práctica: guarda la fuente de la verdad (entrada del usuario, respuestas del servidor, intención de la UI) y deriva el resto (contadores, listas filtradas) a partir de ella.
El flujo de datos unidireccional significa:
propsEsto facilita la depuración porque puedes trazar las actualizaciones de forma lineal: evento → cambio de estado → re-render.
El DOM virtual es la representación en memoria de la UI que usa React. Cuando cambian state o props, React compara la descripción anterior de la UI con la nueva y actualiza el DOM real solo donde hace falta.
Para evitar problemas comunes:
key estables en listasEmpieza simple y escala según la necesidad:
Prefiere una única fuente de la verdad y deriva el resto para evitar desajustes.