Cuando trabajas con server side rendering en React, uno de los pasos fundamentales es separar la configuración de rutas para el cliente y el servidor. Cada lado maneja objetos distintos: el cliente necesita un historial del navegador, mientras que el servidor trabaja con un arreglo de rutas. Aquí se explica cómo instalar las dependencias necesarias, crear el browser history, definir el enrutador del cliente y preparar las rutas del servidor.
¿Qué dependencias necesitas para manejar rutas en SSR?
Antes de tocar cualquier archivo, es necesario instalar dos paquetes clave [00:24]:
- history: permite crear un historial de navegación que se asigna al enrutador del cliente.
- react-router-config: agrega capas de configuración al enrutador, especialmente útil del lado del servidor.
Además, si react-router no está entre tus dependencias, también debes instalarlo con npm install react-router [03:04]. Una verificación rápida en el package.json te confirma si ya lo tienes disponible.
¿Cómo se configura el enrutador del lado del cliente?
Dentro del archivo index.js del frontend, se importa createBrowserHistory desde el paquete history [02:07]. Con este método se crea una constante llamada history:
javascript
import { createBrowserHistory } from 'history';
const history = createBrowserHistory();
Después, se importa Router desde react-router y se envuelve la aplicación justo debajo del Provider. Al componente Router se le pasa la propiedad history que acabas de crear [03:30]:
javascript
import { Router } from 'react-router';
<Provider store={store}>
<Router history={history}>
<App />
</Router>
</Provider>
El concepto de browser history es esencial: le da al enrutador la capacidad de rastrear las páginas visitadas y gestionar la navegación sin recargas completas del navegador. Una vez guardado, se verifica que el build compile de manera exitosa.
¿Por qué las rutas del servidor se definen como un arreglo?
Del lado del servidor se necesita un archivo separado, por ejemplo serverRoutes.js [04:38]. La razón es que el static router de react-router espera recibir un arreglo de objetos, donde cada objeto describe una ruta con tres propiedades principales:
- path: la URL de la ruta.
- exact: indica si debe coincidir de forma exacta.
- component: el componente de React que se renderiza.
La estructura replica lo que ya tienes en app.js, pero en formato de datos:
javascript
import Home from './containers/Home';
import Login from './containers/Login';
import Register from './containers/Register';
import Player from './containers/Player';
import NotFound from './containers/NotFound';
const routes = [
{ path: '/', exact: true, component: Home },
{ path: '/login', exact: true, component: Login },
{ path: '/register', exact: true, component: Register },
{ path: '/player/:id', exact: true, component: Player },
{ name: 'NotFound', component: NotFound },
];
export default routes;
Para la ruta de not found no se define un path, sino un name, ya que actúa como fallback cuando ninguna otra ruta coincide [06:16].
¿Cómo hacer el initial state reutilizable?
El initial state es el estado inicial de la aplicación, normalmente un objeto extenso con datos precargados. Mantenerlo directamente en el archivo principal resta legibilidad y dificulta su reutilización [06:44].
La solución es extraerlo a un archivo independiente llamado initialState.js en la raíz del frontend:
javascript
const initialState = {
// datos del estado inicial
};
export default initialState;
Después, en el archivo donde se necesita, simplemente se importa:
javascript
import initialState from './initialState';
Si al crear archivos nuevos el servidor no detecta los cambios automáticamente, reinicia nodemon de forma manual [07:42]. Una vez importado correctamente, la aplicación vuelve a funcionar con un estado inicial accesible tanto para el cliente como para el servidor.
¿Qué papel juega ESLint en este proceso?
Durante toda la configuración se mencionan ajustes de ESLint, la herramienta de análisis estático de código [01:35]. Por ejemplo, el quick fix para cambiar double quotes por single quotes reduce la cantidad de errores reportados. También se usa la opción de corregir todos los problemas del proyecto de una vez con la acción de fix all auto-fixable problems, lo que deja el código en verde y cumpliendo los estándares definidos [07:20].
Mantener esta separación entre rutas de cliente y servidor, junto con un estado inicial modular, prepara el terreno para aplicar server side rendering de manera limpia. ¿Ya tienes clara la diferencia entre el Router con history y el arreglo de rutas para el static router? Comparte tu experiencia configurando estos enrutadores.
