B / Blog sobre React
Seis decisiones de base React antes de acelerar la entrega
Una forma práctica de establecer las pocas decisiones frontend que hacen que la entrega React posterior sea más segura, coherente y fácil de asumir por otro equipo.
- Arquitectura React
- Bases de producto
- Transferencia de responsabilidad
Una base React duradera no es una lista larga de bibliotecas. Es un conjunto pequeño de decisiones que mantiene coherente el trabajo de producto cuando llegan más funcionalidades, desarrolladores e integraciones.
El objetivo no es predecir todos los requisitos futuros. Es eliminar la ambigüedad de las decisiones que, de otro modo, se tomarán de forma distinta en cada funcionalidad y demostrar esas decisiones en un recorrido representativo del producto.
B-01
Evaluar las decisiones según su alcance y reversibilidad
No todas las elecciones merecen atención al nivel de la base. Evalúa cada decisión frente a cuatro preguntas:
- Alcance: ¿cuántas funcionalidades o equipos dependerán de ella?
- Reversibilidad: ¿puede cambiarse gradualmente sin coordinar todo el producto?
- Coste del fallo: ¿qué ocurre si la decisión es incorrecta en producción?
- Responsabilidad: ¿el equipo que recibe el producto podrá entenderlo y evolucionarlo?
Una decisión de gran alcance y difícil de revertir pertenece a la base. Una elección local y fácil de sustituir pertenece a la funcionalidad que la necesita. Esta distinción evita que un proyecto de base se convierta en un programa especulativo de plataforma.
B-02
1. Dibujar los límites de responsabilidad
Haz visibles las principales responsabilidades del frontend antes de elegir nombres de carpetas. Un mapa útil de límites muestra dónde pertenecen la composición de rutas, el comportamiento de las funcionalidades, las reglas de dominio, la adaptación de API, la UI compartida y las cuestiones de plataforma.
La prueba es explicativa, no estética: un desarrollador debería poder colocar un comportamiento nuevo y explicar por qué esa capa lo asume. Si la respuesta depende de quién implemente la tarea, el límite todavía no resulta útil.
B-03
2. Asignar la responsabilidad sobre los datos y el estado
Separa los datos del servidor, el estado de la URL, el estado de los formularios, el estado transitorio de la interfaz y el estado de cliente realmente compartido. Define dónde se lee, transforma, almacena en caché, invalida y restablece cada uno.
Esta decisión evita dos extremos costosos: obtener los mismos datos del servidor a través de varias abstracciones de cliente o centralizar el estado de interacción local en un almacén global. El modelo correcto sigue la duración y la autoridad de los datos, no la comodidad de una única API.
B-04
3. Diseñar las rutas de carga, vacío, error y recuperación
El camino feliz no es un contrato de funcionalidad completo. Decide cómo deben comportarse la carga a nivel de ruta, la carga parcial, los resultados vacíos, el error de validación, el error de autorización, el fallo de proveedor y el reintento.
Estos estados afectan a los límites de componentes y al flujo de datos. Diseñarlos después del camino feliz suele revelar que la abstracción original no puede representar con claridad el comportamiento real del producto.
B-05
4. Dar una responsabilidad a cada capa de pruebas
La estrategia de pruebas debe responder qué riesgos se protegen y dónde. Las reglas puras de dominio, el comportamiento de componentes, los contratos de integración y un número reducido de recorridos críticos de usuario no necesitan la misma herramienta ni el mismo alcance.
La base debe ofrecer ejemplos representativos y criterios claros de selección, no una cantidad objetivo de pruebas. La cobertura solo es útil como señal cuando las pruebas protegen un comportamiento que el equipo entiende y pretende mantener.
B-06
5. Establecer el límite de la UI reutilizable
Define cómo se relacionan las variables semánticas, los elementos accesibles, los componentes de producto y la composición específica de funcionalidades. Un botón o un campo pertenece al sistema compartido cuando su comportamiento y contrato visual son estables entre contextos. Un panel complejo de producto suele permanecer cerca de la funcionalidad hasta que la repetición demuestre lo contrario.
Así se evitan tanto la duplicación sin control como un sistema de diseño lleno de abstracciones prematuras. La reutilización debe seguir una igualdad demostrada, no solo un parecido visual.
B-07
6. Hacer que la operabilidad forme parte de la arquitectura
Decide qué debe ser observable cuando falla el producto: errores de ruta, fallos importantes de proveedores, regresiones de rendimiento y eventos de conversión relevantes. Establece al mismo tiempo los límites de privacidad para que los datos personales, los tokens y el contenido de formularios no entren accidentalmente en registros o analíticas.
Define también la ruta de entrega: entornos, responsabilidad sobre la configuración, controles de lanzamiento, expectativas de reversión y quién recibe las señales de producción. Un frontend que puede construirse, pero no operarse con confianza, no es una base completa.
B-08
Demostrar la base con un corte vertical
La mejor validación es una funcionalidad representativa que atraviese los límites reales: enrutamiento, acceso a datos, validación, interacción, estados de error, UI reutilizable, pruebas, observabilidad y despliegue. Utilízala para descubrir dónde las decisiones escritas resultan incómodas o incompletas.
El resultado debe ser compacto y ejecutable:
- Un mapa de límites que nombre responsabilidades y dirección de dependencias.
- Un registro breve para cada decisión de gran alcance y sus concesiones.
- Un corte vertical implementado que los desarrolladores puedan inspeccionar y ampliar.
- Patrones representativos de componentes, integraciones y pruebas.
- Una sesión de traspaso en la que el equipo receptor modifique por sí mismo el corte.
La base está preparada cuando reduce el número de decisiones ocultas dentro de la siguiente funcionalidad, no cuando se han construido todas las abstracciones posibles.