Cuando una página necesita resolver varias peticiones al servidor, la interfaz completa se bloquea hasta que la última respuesta llega. Parallel routing en Next.js rompe esa limitación al dividir la página en subpáginas independientes, cada una con su propio loader, permitiendo que la información aparezca de forma progresiva sin dejar al usuario esperando una pantalla vacía.
¿Qué problema resuelve el parallel routing?
En una aplicación típica es común que una sola página necesite datos de distintas fuentes. Por ejemplo, una vista de "Mi cuenta" puede requerir tanto la información del usuario como el historial de órdenes [0:10]. Ambas peticiones pueden ejecutarse en paralelo (parallel fetching), pero la UI no se pinta hasta que la más lenta termina. Eso significa que, aunque una respuesta llegue en milisegundos, el usuario no ve nada hasta que la otra también resuelve.
El parallel routing soluciona esto dividiendo la página en rutas paralelas que se renderizan de forma independiente. Cada ruta puede mostrar su propio loading state mientras obtiene sus datos [1:00].
¿Cómo se implementan las parallel routes en Next.js?
La implementación parte de una convención de carpetas dentro del directorio de la página. En el ejemplo práctico se trabaja con la ruta my-account y se crean dos carpetas con el prefijo arroba (@), que es la nomenclatura especial que indica a Next.js que se trata de una parallel route [5:30]:
@user_info — contiene un page.tsx con la lógica para obtener y mostrar los datos del cliente.@orders_info — contiene un page.tsx encargado de traer y listar el historial de órdenes.
Cada carpeta funciona como una subpágina autónoma. La query getCustomerOrders, ubicada en services/shopify/graphql/customers, devuelve el número total de órdenes y la lista detallada [1:45]. Al separar esa lógica en su propia ruta paralela, se desacopla del resto de la UI.
¿Qué papel juega el layout en las parallel routes?
Para que las rutas paralelas se inyecten en la vista, es necesario crear un archivo layout.tsx dentro de la carpeta de la página [7:05]. Este layout recibe las parallel routes como props adicionales junto con children:
tsx
interface MyAccountLayoutProps {
children: React.ReactNode;
ordersInfo: React.ReactNode;
userInfo: React.ReactNode;
}
export default function MyAccountLayout(props: MyAccountLayoutProps) {
return (
<>
{props.children}
{props.userInfo}
{props.ordersInfo}
</>
);
}
children representa la página principal (en este caso solo un <h1>My account</h1>), mientras que userInfo y ordersInfo se renderizan de forma independiente. Si una tarda más que la otra, el usuario ya ve la que llegó primero.
¿Cómo agregar loaders independientes a cada ruta?
Basta con colocar un archivo loading.tsx dentro de cada carpeta @user_info y @orders_info [8:20]. Ese componente se muestra automáticamente mientras la data de esa ruta paralela se resuelve. Al recargar con Command + Shift + R se puede comprobar que cada sección muestra su loader por separado, confirmando que las rutas funcionan de manera independiente.
¿Cuándo vale la pena usar parallel routes?
No siempre es necesario recurrir a este patrón. Cuando las queries están optimizadas —como en el caso de GraphQL donde las respuestas son rápidas— la diferencia es apenas perceptible [9:10]. Sin embargo, la recomendación es clara: si la página realiza tres o cuatro llamadas y la mayoría son pesadas (por ejemplo, endpoints que tardan cuatro o cinco segundos para traer datos de visualización), las parallel routes aportan una mejora significativa en la experiencia de usuario.
- Útil cuando hay múltiples fetches sin relación entre sí.
- Ideal para dashboards o páginas con datos de distintas fuentes.
- Permite mostrar contenido parcial en lugar de una pantalla en blanco.
Si has trabajado con páginas donde el tiempo de carga se siente eterno, prueba dividirlas en rutas paralelas y comparte tu experiencia en los comentarios.
