Cuándo usar React: criterios de decisión para interfaces con estado y complejidad

React como decisión de producto y de ingeniería

Usar React no es “porque sí”: es una elección que tiene sentido cuando tu interfaz necesita manejar cambios frecuentes, múltiples estados de UI y crecimiento del código sin volverse frágil. En este capítulo verás criterios concretos para decidir, comparando con alternativas más simples (HTML/JS directo o plantillas) y detectando señales de sobreingeniería.

Cuándo React suele ser una buena elección

1) La UI se compone de piezas repetibles y combinables

React brilla cuando la pantalla se arma con partes que se repiten en distintas secciones o páginas (tarjetas, filas, paneles, modales, formularios), y esas partes evolucionan con el tiempo. No se trata solo de “reutilizar”, sino de poder cambiar una pieza y que el cambio sea consistente en todos los lugares donde se usa.

2) Hay interacción frecuente y estados de UI que cambian

Si el usuario filtra, ordena, busca, selecciona, edita, abre/cierra paneles, navega entre vistas, o la UI reacciona a entradas en tiempo real, aparece una necesidad constante de sincronizar lo que se ve con lo que “es verdad” en los datos. En interfaces así, el enfoque imperativo de “buscar un nodo y cambiarle algo” tiende a crecer en complejidad.

3) Necesitas sincronización de estado entre partes de la interfaz

Cuando una acción en un lugar afecta a otros (por ejemplo, un contador en el header, un carrito, un resumen lateral, un badge de notificaciones), la dificultad no es el renderizado en sí, sino mantener coherencia. React suele facilitar este tipo de consistencia al estructurar la UI alrededor de un estado que gobierna el renderizado.

4) Escalabilidad del front-end (crecimiento del código y del dominio)

Si el proyecto va a crecer en pantallas, reglas de negocio, validaciones, permisos, variantes de UI y casos borde, conviene invertir temprano en una arquitectura que soporte cambios. React suele encajar bien cuando el front-end deja de ser “una página” y pasa a ser una aplicación con múltiples flujos.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

5) Trabajo en equipo y necesidad de consistencia

En equipos, la consistencia importa: patrones repetibles, separación clara de responsabilidades y facilidad para revisar cambios. React suele ayudar a que varias personas trabajen en paralelo sobre partes distintas sin pisarse tanto, especialmente si la UI está bien modularizada.

Cuándo una alternativa simple suele ser mejor

HTML + CSS + JS directo (sin framework)

• Landing pages o sitios informativos con contenido mayormente estático.
• Interacción mínima: un acordeón, un menú móvil, un modal simple, validación ligera de un formulario.
• Un par de widgets aislados en una página existente (por ejemplo, un selector de fecha o un “me gusta”).

En estos casos, añadir React puede aumentar el peso mental y operativo: build, bundling, estructura de proyecto, convenciones, etc. Si la UI cambia poco y el estado es pequeño, el enfoque directo suele ser más rápido y suficiente.

Plantillas (server-side o estáticas) con “sprinkles” de JS

• Contenido generado desde el servidor con pequeñas mejoras interactivas.
• Paneles administrativos simples donde la mayoría de la navegación recarga páginas.
• Formularios tradicionales con validación y feedback básico.

Si la mayor parte del trabajo es renderizar HTML desde datos y la interacción es limitada, una solución basada en plantillas puede ser más simple de mantener, especialmente si el equipo ya domina ese stack.

Señales de que React puede ser excesivo (overengineering)

• El problema real es contenido, no interacción: la página cambia por campañas o textos, no por estados de UI.
• La lógica de estado cabe en unas pocas variables y no hay sincronización entre secciones.
• La UI no requiere consistencia compleja: no hay múltiples vistas que dependan del mismo estado.
• El equipo no tiene tiempo para adoptar convenciones y prácticas (estructura, pruebas, revisiones) y el proyecto es pequeño o de vida corta.
• El costo de build y tooling supera el beneficio: para un micrositio, un bundle y pipeline completo puede ser innecesario.
• Se está eligiendo React por moda sin requisitos claros de estado, interacción o crecimiento.

Marco de decisión: preguntas concretas

Usa este marco como checklist. No necesitas responder “sí” a todo; busca patrones.

A) Complejidad de UI y estado

• ¿Cuántos estados de UI existen (cargando, vacío, error, éxito, edición, selección, etc.)?
• ¿La UI cambia por acciones frecuentes del usuario (filtrar, ordenar, editar en línea, arrastrar/soltar)?
• ¿Hay estado compartido entre secciones (lo que pasa en un componente afecta a otros)?
• ¿Hay sincronización con datos remotos (refrescos, reintentos, invalidación, polling)?

B) Mantenibilidad y evolución

• ¿Se espera que la UI crezca en pantallas, variantes o reglas?
• ¿Cambios futuros implicarán tocar muchos archivos si no hay una estructura de componentes clara?
• ¿Hay riesgo de “spaghetti DOM”: muchos querySelector, listeners dispersos y estados duplicados?

C) Costo de adopción

• ¿El equipo ya conoce React o tiene tiempo para aprenderlo sin frenar el proyecto?
• ¿El proyecto justifica el costo de configuración, convenciones y disciplina (revisiones, pruebas, estructura)?
• ¿La entrega es urgente y el alcance es pequeño y estable?

D) Trabajo en equipo

• ¿Varias personas trabajarán en paralelo en la UI?
• ¿Necesitas una base común para compartir piezas y patrones?

Guía práctica paso a paso para decidir

Paso 1: Describe la interfaz como una lista de interacciones

Escribe en bullets qué puede hacer el usuario y qué cambia en pantalla. Ejemplo:

• Buscar productos por texto.
• Filtrar por categoría y precio.
• Ordenar por relevancia o precio.
• Abrir detalle sin recargar.
• Agregar al carrito y ver contador actualizado.

Si la lista es corta y local (1–2 interacciones simples), probablemente no necesitas React.

Paso 2: Cuenta “puntos de estado” y “puntos de sincronización”

Puntos de estado: variables que cambian y afectan el renderizado (texto de búsqueda, filtros, selección, modo edición, etc.). Puntos de sincronización: lugares donde el mismo dato debe verse consistente en más de un sitio (carrito en header y en sidebar, filtros y resultados, etc.).

Si ambos son bajos, HTML/JS directo suele ser suficiente. Si alguno es alto, React empieza a tener sentido.

Paso 3: Evalúa el “costo de cambio”

Haz una simulación mental: “Si mañana agrego una columna, un filtro nuevo y un estado de error, ¿cuántos lugares toco?” Si la respuesta es “muchos” y con riesgo de inconsistencias, React puede reducir ese costo al centralizar el renderizado en función del estado.

Paso 4: Decide el alcance: ¿React para todo o para una parte?

No siempre es binario. Si tienes una página mayormente estática con un área altamente interactiva, puedes considerar React solo para ese módulo. Señales de que un módulo aislado es buen candidato:

• El módulo tiene su propio estado y reglas.
• La interacción es rica (filtros, edición, validación, vistas internas).
• El resto del sitio no necesita compartir ese estado.

Paso 5: Verifica el “riesgo de sobreingeniería” con un test rápido

Responde estas preguntas con honestidad:

• ¿Podría implementarlo con JS directo en menos de 200–300 líneas sin volverse ilegible?
• ¿El estado es local y no se comparte?
• ¿La UI no crecerá (o el proyecto dura poco)?
• ¿El equipo no tiene margen para adoptar prácticas y estructura?

Si la mayoría es “sí”, React probablemente es demasiado para este caso.

Ejemplos comparativos (decisión aplicada)

Ejemplo 1: Landing con formulario de contacto

• Interacción: validar campos, mostrar mensaje de envío.
• Estado: 2–3 flags (valores, error, enviado).
• Sincronización: casi nula.

Decisión típica: HTML/JS directo o plantillas. React suele ser innecesario.

Ejemplo 2: Catálogo con filtros, paginación y carrito

• Interacción: filtros combinables, búsqueda, paginación, detalle, carrito.
• Estado: múltiples variables y estados de carga/error.
• Sincronización: carrito y contadores en varios lugares; filtros afectan resultados.

Decisión típica: React encaja bien por complejidad de estado y consistencia.

Ejemplo 3: Dashboard con widgets y actualizaciones

• Interacción: selección de rango de fechas, tabs, widgets que dependen del mismo filtro.
• Estado: compartido entre widgets; estados de carga por sección.
• Sincronización: alta (un filtro impacta todo).

Decisión típica: React suele ser una buena base para escalar y mantener coherencia.

Checklist final de decisión (rápido)

• ¿Hay interacción frecuente y múltiples estados de UI? React suma.
• ¿Hay estado compartido y necesidad de consistencia entre secciones? React suma.
• ¿El front-end crecerá y lo tocarán varias personas? React suma.
• ¿La UI es estática o con interacción mínima y local? React resta.
• ¿El costo de adopción supera el beneficio para el alcance actual? Evita React o úsalo solo en un módulo.