Por qué una SPA necesita un router

Tu app de React vive en UNA sola página HTML —por eso se llama SPA (Single Page Application)—. Pero los usuarios esperan varias "pantallas" con sus propias URLs: /gastos, /perfil, /gastos/5. ¿Cómo tienes muchas vistas navegables, con botones de atrás/adelante que funcionan y URLs que se pueden compartir, sin recargar la página entera cada vez? Ese es el trabajo de un ROUTER. Hoy entiendes el problema y ves el mecanismo crudo del navegador que un router envuelve —funcionando en vivo—.

Un edificio, muchas salas

El mecanismo crudo: la History API

Antes de una librería, el navegador ya trae lo esencial: la History API, que cambia la URL SIN recargar (pushState) y avisa cuando el usuario pulsa atrás/adelante (popstate). Este playground es un "router" mínimo hecho a mano con eso —ya lo viste en JavaScript (SC-02, M14)—:

Al pulsar un botón, pushState cambia la URL y setRuta cambia lo que se muestra —sin recarga—. Un objeto paginas mapea cada ruta a su contenido. Eso es un router en su forma más pura: mantener sincronizados la URL y la vista. Un router de verdad (React Router) hace ESTO, pero resolviendo lo difícil: parámetros (/gastos/:id), rutas anidadas, carga de datos por ruta, protección de rutas… todo lo que a mano se vuelve un enredo.

Por qué no lo haces a mano

Mini-reto

Amplía el mini-router: 1) agrega una cuarta ruta /ayuda con su contenido; 2) resalta el botón de la ruta activa (compara ruta con el destino de cada botón y cambia su estilo); 3) agrega un enlace "volver a inicio" que use ir("/inicio"). Observa cómo, con solo pushState + estado, ya tienes navegación sin recargas —y anticipa por qué querrías una librería cuando esto crezca a parámetros y anidamiento—.

Qué sigue

Ya entiendes el mecanismo. La próxima lección trae React Router: cómo declarar rutas con <Routes> y <Route>, y navegar con <Link> sin recargar —la versión declarativa y robusta de lo que acabas de hacer a mano—.