Patrones Avanzados y Control de Navegación

Bienvenido a la Parte 12 de nuestra serie completa de enrutamiento en SvelteKit. En este punto, ya construiste bases sólidas y exploraste los patrones fundamentales. Ahora entramos en territorio que verdaderamente distingue las aplicaciones de nivel productivo de los proyectos básicos.

Este artículo no se trata solo de mostrarte más funcionalidades—se trata de entender cuándo y por qué usarlas. Cada patrón que veremos resuelve desafíos arquitectónicos específicos que encontrarás a medida que tus aplicaciones crezcan en complejidad.

Lo que Dominarás

Al final de este artículo, entenderás:

Param Matchers: Cómo validar rutas en la capa de enrutamiento (y por qué es fundamentalmente diferente a validar en las funciones load)
Grupos de Rutas: El pensamiento arquitectónico detrás de organizar layouts sin contaminar las URLs
Ruptura de Layout: Cuándo salirse de la jerarquía de layouts es la decisión correcta vs. una mala práctica
Shallow Routing: El modelo mental detrás del estado en la URL que no activa navegaciones completas
Ciclo de Vida de Navegación: Cómo interceptar, modificar y responder a cada fase de la navegación

Más importante aún, entenderás el proceso de toma de decisiones para elegir entre estos patrones.

El enrutamiento avanzado no se trata de usar cada funcionalidad, sino de elegir la herramienta correcta para cada problema. Una aplicación bien arquitecturada usa estos patrones con moderación pero de forma estratégica.

Param Matchers: Validación a Nivel de Ruta

El Problema: Defensa en Profundidad

Empecemos con un escenario que confunde a muchos desarrolladores. Tienes una ruta de perfil de usuario:

src/routes/users/[id]/+page.svelte

Tu función load obtiene el usuario por ID y retorna sus datos. Simple. Pero ¿qué ocurre cuando alguien visita /users/hello o /users/../admin?

El enfoque ingenuo es validar en tu función load:

// The approach most developers start with
export const load: PageLoad = async ({ params }) => {
	if (!/^\d+$/.test(params.id)) {
		error(400, 'Invalid user ID')
	}
	// fetch user...
}

Esto funciona, pero estás resolviendo el problema en la capa incorrecta.

Piénsalo: estás aceptando la coincidencia de ruta, iniciando la función load, potencialmente incluso pasando por middleware o hooks—todo para una URL que nunca fue válida en primer lugar. En una aplicación con alto tráfico, esto agrega carga innecesaria. Más importante aún, crea una discrepancia de categoría: "formato de URL inválido" no es un 400 Bad Request, es "esta página no existe."

Los Param matchers resuelven esto en la propia capa de enrutamiento. Las URLs inválidas simplemente no coinciden con la ruta—caen hacia otras rutas o generan un 404.

La validación pertenece a la capa más temprana posible. Las restricciones de base de datos capturan lo que la lógica de negocio no detecta. La lógica de negocio captura lo que la validación de API no detecta. La validación de API captura lo que la validación de enrutamiento no detecta. Cada capa es una red de seguridad para la que está encima.

Creando tu Primer Matcher

Los matchers viven en src/params/ y exportan una función match. La función recibe el segmento de URL y retorna true si es válido:

// src/params/integer.ts
import type { ParamMatcher } from '@sveltejs/kit'

export const match: ParamMatcher = (param) => {
	return /^\d+$/.test(param)
}

Aplica el matcher usando la sintaxis = en el nombre de la carpeta de tu ruta:

src/routes/users/[id=integer]/+page.svelte

Ahora el comportamiento cambia de forma fundamental:

/users/123 → Coincide, params.id = '123'
/users/456789 → Coincide, params.id = '456789'
/users/hello → NO coincide, SvelteKit prueba otras rutas
/users/12.5 → NO coincide (no es un entero)

Nota el cambio en el modelo mental: no estamos lanzando errores para entradas inválidas. Estamos diciendo "esta ruta simplemente no existe para valores no enteros."

La Cascada de Enrutamiento: Por Qué Importa

Cuando una URL no coincide con un matcher, SvelteKit no genera un 404 de inmediato. Continúa revisando otras rutas. Esto permite poderosos patrones de disambiguación:

src/routes/
├── users/
│   ├── [id=integer]/+page.svelte   ← /users/123
│   └── [username]/+page.svelte     ← /users/johndoe

Ambas rutas tienen parámetros dinámicos, pero sirven propósitos completamente distintos. El matcher crea prioridad automática:

Intenta [id=integer] primero (los matchers tienen mayor especificidad)
Si no coincide, cae hacia [username]

Esto es un cambio radical para el diseño de APIs. Puedes tener /users/123 para IDs de usuario y /users/johndoe para nombres de usuario sin ninguna lógica condicional en tu código. El enrutador maneja la disambiguación automáticamente.

Este patrón refleja cómo diseñarías una API REST. La capa de enrutamiento se convierte en tu primera línea de validación de entrada, y tus funciones load pueden confiar en que recibirán parámetros bien formados. Este es el Principio de Responsabilidad Única aplicado al enrutamiento.

Construyendo una Biblioteca Práctica de Matchers

En aplicaciones de producción, querrás una colección de matchers reutilizables. Aquí hay patrones probados en la práctica:

Matcher de Enteros

// src/params/integer.ts
import type { ParamMatcher } from '@sveltejs/kit'

export const match: ParamMatcher = (param) => {
	return /^\d+$/.test(param)
}

Matcher de UUID

// src/params/uuid.ts
import type { ParamMatcher } from '@sveltejs/kit'

// Matches UUID v1-5 format
const UUID_REGEX = /^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i

export const match: ParamMatcher = (param) => {
	return UUID_REGEX.test(param)
}

Por qué importa: Los UUIDs son notoriamente fáciles de escribir mal. Sin validación, un usuario que guarda en favoritos /products/550e8400-e29b-41d4-a716-44665544000 (con el último dígito faltante) vería un error de base de datos en lugar de un 404 limpio.

Matcher de Slug

// src/params/slug.ts
import type { ParamMatcher } from '@sveltejs/kit'

export const match: ParamMatcher = (param) => {
	// Lowercase letters, numbers, hyphens
	// Must start with letter, 3-100 chars
	return /^[a-z][a-z0-9-]{2,99}$/.test(param)
}

Decisión de diseño: Exigimos que empiece con una letra para prevenir slugs como 123-product que podrían confundirse con rutas basadas en ID.

Matcher de Fecha

// src/params/date.ts
import type { ParamMatcher } from '@sveltejs/kit'

export const match: ParamMatcher = (param) => {
	// YYYY-MM-DD format
	if (!/^\d{4}-\d{2}-\d{2}$/.test(param)) {
		return false
	}

	// Verify it's actually a valid date (not 2025-02-30)
	const date = new Date(param + 'T00:00:00Z')
	return !isNaN(date.getTime()) && param === date.toISOString().split('T')[0]
}

¿Por qué la validación adicional? La expresión regular sola aceptaría 2025-02-30 (el 30 de febrero no existe). El constructor Date valida la lógica de calendario real.

Nota que usamos hora UTC (T00:00:00Z). Sin esto, el comportamiento del análisis de fechas varía según la zona horaria del servidor, lo que genera bugs del tipo "funciona en desarrollo, falla en producción."

Matchers con Tipos Seguros

Aquí es donde los matchers se vuelven verdaderamente poderosos. Puedes crear matchers que no solo validan cadenas, sino que también restringen tipos de TypeScript:

// src/params/category.ts
import type { ParamMatcher } from '@sveltejs/kit'

const categories = ['electronics', 'clothing', 'books', 'home', 'sports'] as const
export type Category = (typeof categories)[number]

export const match = ((param: string): param is Category => {
	return categories.includes(param as Category)
}) satisfies ParamMatcher

La magia ocurre en tu función load:

// src/routes/shop/[category=category]/+page.ts
import type { PageLoad } from './$types'
import type { Category } from '$params/category'

export const load: PageLoad = async ({ params }) => {
	// TypeScript knows params.category is 'electronics' | 'clothing' | 'books' | 'home' | 'sports'
	// NOT just string!
	const category: Category = params.category
}

Los predicados de tipo (param is Category) son una funcionalidad de TypeScript poco aprovechada. Combinados con satisfies, obtienes tanto validación en tiempo de ejecución como estrechamiento de tipos en tiempo de compilación. Esto es defensa en profundidad a nivel de tipos.

La Restricción Fundamental: Los Matchers Son Universales

Esta es la limitación crítica que sorprende a muchos desarrolladores:

Los matchers se ejecutan TANTO en el servidor como en el navegador. El código de tu matcher se envía al cliente para la navegación del lado del cliente. Esto significa:

Permitido en Matchers	No Permitido en Matchers
Validación pura de cadenas	Consultas a base de datos
Operaciones con RegEx	Acceso al sistema de archivos
Lógica sincrónica simple	Importaciones de `$lib/server/*`
	Variables de entorno (salvo las públicas)

// AVOID: This will break client-side navigation
import { db } from '$lib/server/database'

export const match: ParamMatcher = async (param) => {
	const user = await db.users.findUnique({ where: { id: param } })
	return !!user
}

// PREFERRED: Validate format, check existence in load function
export const match: ParamMatcher = (param) => {
	return /^[a-f0-9]{24}$/.test(param) // MongoDB ObjectId format
}

La regla general: Los matchers validan el formato, las funciones load validan la existencia.

Si te encuentras queriendo acceso a la base de datos en un matcher, estás intentando resolver el problema equivocado. La pregunta no es "¿existe este usuario?" sino "¿es este un formato de ID de usuario válido?" Las verificaciones de existencia pertenecen a las funciones load, donde tienes todas las capacidades del servidor.

Grupos de Rutas: Organización Arquitectónica Sin Contaminación de URLs

Los grupos de rutas resuelven uno de los problemas más comunes en el crecimiento de las aplicaciones SvelteKit: ¿cómo organizas tus layouts y tu código sin forzar esa organización en tus URLs?

El Problema: Los Layouts Quieren Apropiarse de las URLs

Imagina que estás construyendo un producto SaaS. Tienes tres secciones distintas:

Páginas de marketing (/, /about, /pricing) — Públicas, layout de marketing con grandes secciones hero
Páginas de la app (/dashboard, /settings, /profile) — Autenticadas, layout de app con barra lateral
Páginas de autenticación (/login, /register, /forgot-password) — Públicas, layout minimalista centrado

El instinto natural en SvelteKit es crear jerarquías de layouts:

src/routes/
├── +layout.svelte           ← Root layout
├── marketing/
│   ├── +layout.svelte       ← Marketing layout
│   ├── +page.svelte         ← /marketing (wait, we wanted /)
│   └── about/+page.svelte   ← /marketing/about (not /about!)
├── app/
│   ├── +layout.svelte
│   └── dashboard/+page.svelte  ← /app/dashboard (not /dashboard!)

Las URLs están contaminadas con tu estructura organizacional. Los usuarios ven /app/dashboard cuando deberían ver /dashboard.

Grupos de Rutas: Organización Sin URLs

Los grupos de rutas usan paréntesis para crear límites de layout que son invisibles para las URLs:

src/routes/
├── (marketing)/
│   ├── +layout.svelte       ← Marketing layout
│   ├── +page.svelte         ← / (the homepage!)
│   ├── about/
│   │   └── +page.svelte     ← /about
│   └── pricing/
│       └── +page.svelte     ← /pricing
├── (app)/
│   ├── +layout.svelte       ← App layout with sidebar
│   ├── +layout.server.ts    ← Auth protection for all app routes
│   ├── dashboard/
│   │   └── +page.svelte     ← /dashboard
│   └── settings/
│       └── +page.svelte     ← /settings
└── (auth)/
    ├── +layout.svelte       ← Minimal centered layout
    ├── login/
    │   └── +page.svelte     ← /login
    └── register/
        └── +page.svelte     ← /register

Los paréntesis le indican a SvelteKit: "esto es organizacional, no un segmento de URL." Los usuarios ven /dashboard, no /(app)/dashboard.

Los grupos de rutas se tratan de separación de preocupaciones. Cada grupo puede tener su propio layout, su propia función de carga de layout, sus propios límites de error. No solo estás organizando archivos—estás creando mini-aplicaciones independientes dentro de tu app.

El Patrón de Autenticación: Una Verificación, Muchas Rutas

Uno de los usos más poderosos de los grupos de rutas es la autenticación centralizada. En lugar de verificar la autenticación en cada función de carga, lo haces una vez a nivel del grupo:

// src/routes/(app)/+layout.server.ts
import { redirect } from '@sveltejs/kit'
import type { LayoutServerLoad } from './$types'

export const load: LayoutServerLoad = async ({ locals, url }) => {
	// This runs for ALL routes in the (app) group
	// /dashboard, /settings, /profile, /billing - all protected automatically
	if (!locals.user) {
		// Preserve where they were trying to go for post-login redirect
		const redirectTo = encodeURIComponent(url.pathname + url.search)
		redirect(303, `/login?redirectTo=${redirectTo}`)
	}

	// User is authenticated - make their data available to all child routes
	return {
		user: {
			id: locals.user.id,
			name: locals.user.name,
			email: locals.user.email,
			avatar: locals.user.avatar
		}
	}
}

Por qué esto es mejor que las verificaciones por ruta:

DRY: Una verificación de autenticación cubre rutas ilimitadas
Imposible de olvidar: Las nuevas rutas en (app) quedan protegidas automáticamente
Fuente única de verdad: La lógica de autenticación cambia en un solo lugar
Disponibilidad de datos: Los datos del usuario fluyen automáticamente hacia todas las rutas hijas

<!-- src/routes/(app)/+layout.svelte -->
<script lang="ts">
	import type { LayoutProps } from './$types'
	import Sidebar from '$lib/components/Sidebar.svelte'
	import Header from '$lib/components/Header.svelte'

	let { data, children }: LayoutProps = $props()
</script>

<div class="app-layout">
	<Sidebar user={data.user} />

	<div class="main-area">
		<Header user={data.user} />

		<main>
			{@render children()}
		</main>
	</div>
</div>

<style>
	.app-layout {
		display: grid;
		grid-template-columns: 250px 1fr;
		min-height: 100vh;
	}

	.main-area {
		display: flex;
		flex-direction: column;
	}

	main {
		flex: 1;
		padding: 2rem;
	}
</style>

Ahora todas las páginas en (app) tienen acceso a data.user porque los datos del layout fluyen hacia los hijos.

Este patrón escala perfectamente. ¿Necesitas acceso basado en roles? Crea grupos (admin) y (user). ¿Necesitas niveles de suscripción? Crea grupos (free), (pro), (enterprise). El sistema de archivos se convierte en tu arquitectura de autorización.

Ubicación de la Página de Inicio: La Pregunta de la Página Raíz

Puedes colocar +page.svelte directamente en un grupo de rutas para crear la página raíz:

src/routes/
├── (marketing)/
│   ├── +layout.svelte
│   └── +page.svelte         ← This IS the homepage (/)
└── (app)/
    └── dashboard/
        └── +page.svelte     ← /dashboard

Esto mantiene tu página de inicio junto a sus páginas hermanas de marketing, usando el layout de marketing.

La Trampa de los Conflictos: Un Solo Grupo por URL

Aquí hay un error que te dará errores de compilación crípticos:

src/routes/
├── (marketing)/
│   └── +page.svelte         ← /
└── (app)/
    └── +page.svelte         ← Also / - CONFLICT!

Solo un grupo puede reclamar una ruta URL determinada. Los grupos de rutas afectan los layouts, no la resolución de URLs. Dos grupos no pueden tener ambos una página en la misma URL.

Piensa en los grupos de rutas como "contenedores de layout", no como "espacios de nombres de URL". El espacio de URLs es plano—los grupos solo te permiten aplicar diferentes layouts a diferentes partes de ese espacio plano.

Escapar de los Layouts: La Válvula de Escape

Los layouts se anidan. Ese es su poder y, ocasionalmente, su problema. A veces una página profundamente anidada necesita escapar completamente de su jerarquía de layouts.

Entendiendo Por Qué Querrías Esto

Considera un dashboard empresarial con esta estructura:

src/routes/
├── +layout.svelte                  ← Root: nav, footer
├── (app)/
│   ├── +layout.svelte              ← App chrome: sidebar
│   └── dashboard/
│       ├── +layout.svelte          ← Dashboard nav: tabs, breadcrumbs
│       └── reports/
│           ├── +layout.svelte      ← Reports: toolbar, filters
│           └── [id]/
│               └── +page.svelte    ← Uses ALL 4 layouts!

Para /dashboard/reports/123, el usuario ve:

Root layout → App layout → Dashboard layout → Reports layout → Page content

Eso son potencialmente cuatro capas de navegación, barras laterales y elementos de interfaz. Pero ¿qué pasa si necesitas:

Embeber un reporte en un iframe en el sitio web de un cliente (sin elementos de interfaz)
Imprimir un reporte (solo el contenido, sin navegación)
Mostrar una vista de presentación en pantalla completa (autenticación de la app, pero sin UI que distraiga)

Necesitas salir de la cadena de layouts.

La Sintaxis `@`: Eligiendo Tu Ancestro de Layout

El símbolo @ en los nombres de archivo especifica dónde "reiniciar" la cadena de layouts:

+page@.svelte           ← Reset to root layout only
+page@(app).svelte      ← Reset to (app) layout (keep auth, skip dashboard/reports chrome)
+page@dashboard.svelte  ← Reset to dashboard layout (skip just reports chrome)

Ejemplo del Mundo Real: Reportes Embebibles

src/routes/
├── +layout.svelte
├── (app)/
│   ├── +layout.svelte
│   └── dashboard/
│       ├── +layout.svelte
│       └── reports/
│           ├── +page.svelte              ← Full app chrome - internal use
│           └── [id]/
│               ├── +page.svelte          ← Full app chrome - viewing a report
│               └── embed/
│                   └── +page@.svelte     ← ROOT ONLY - embeddable!

La página de embed sale hasta el layout raíz únicamente:

<!-- src/routes/(app)/dashboard/reports/[id]/embed/+page@.svelte -->
<script lang="ts">
	import type { PageProps } from './$types'

	let { data }: PageProps = $props()
</script>

<!-- No navigation, no sidebar, no header, no footer -->
<!-- Clean slate for iframe embedding -->
<div class="embedded-report">
	<h1>{data.report.title}</h1>
	<ReportChart data={data.report.chartData} />
</div>

<style>
	.embedded-report {
		padding: 1rem;
		font-family: system-ui;
		/* iframe-friendly styles */
	}
</style>

Ahora /dashboard/reports/123/embed muestra solo el contenido del reporte—perfecto para <iframe src="/dashboard/reports/123/embed">.

El patrón de embed es increíblemente útil para integraciones. Los clientes pueden embeber tus reportes en sus dashboards, páginas de Notion o herramientas internas. Una sola página sirve dos contextos de UX completamente diferentes.

Cuándo NO Usar la Ruptura de Layout

Romper el layout es una herramienta poderosa. Como todas las herramientas poderosas, puede causar daño cuando se usa incorrectamente.

Señales de que podrías estar abusando de @:

Múltiples páginas en la misma carpeta usando diferentes reinicios con @
Modelo mental complejo de "qué página usa qué layouts"
Miembros del equipo confundidos sobre la herencia de layouts

Considera primero las alternativas:

<!-- Alternative: Conditional layout content -->
<!-- src/routes/(app)/dashboard/+layout.svelte -->
<script lang="ts">
	import { page } from '$app/state'

	let { data, children } = $props()

	// Hide sidebar for specific routes
	const isMinimalMode = $derived(
		page.url.pathname.includes('/embed') ||
			page.url.pathname.includes('/fullscreen') ||
			page.url.pathname.includes('/print')
	)
</script>

{#if isMinimalMode}
	<main class="minimal">
		{@render children()}
	</main>
{:else}
	<Sidebar user={data.user} />
	<main class="with-sidebar">
		{@render children()}
	</main>
{/if}

Cuándo usar @ vs layouts condicionales:

Usa `@` cuando...	Usa layouts condicionales cuando...
La página es verdaderamente independiente	Solo estás ocultando algunos elementos de UI
Necesitas un manejo diferente de `<head>`	La página sigue perteneciendo al mismo contexto
El rendimiento importa (menos código de layout)	Quieres animar entre modos
La página puede renderizarse sin JavaScript	Necesitas preservar el estado durante el cambio de modo

Romper el layout se trata de identidad, no de apariencia. Una página de embed no es "el dashboard sin barra lateral", es una página fundamentalmente diferente que resulta mostrar contenido similar. Si solo estás alternando visibilidad, usa condicionales.

Ruteo Superficial: Estado de URL Sin Transiciones de Página

El ruteo superficial es una de las características más elegantes de SvelteKit, pero también una de las más incomprendidas. Construyamos el modelo mental desde los principios básicos.

El Problema: Modales, Filtros y Estado Compartible

Considera una galería de fotos. Cuando un usuario hace clic en una miniatura:

Sin ruteo superficial:

Navegación completa a /photos/123
Posición de scroll del navegador perdida
El componente de galería se desmonta y se vuelve a montar
Estado de animación perdido
Se siente lento y brusco

Lo que los usuarios realmente quieren:

El modal se abre sobre la galería
La URL se actualiza a /photos/123 (¡para poder compartir el enlace!)
El botón de retroceso cierra el modal
La galería permanece montada debajo

Este es el problema del "URL de modal"—quieres estado basado en URL sin navegación basada en URL.

El Modelo Mental: Historial Sin Hidratación

pushState y replaceState modifican la pila de historial del navegador y la barra de URL sin activar el sistema de navegación de SvelteKit. No se ejecutan funciones de carga. No se vuelven a montar los layouts. Solo cambian la URL y el estado.

Piénsalo como "navegación cosmética" — la URL cambia para fines de compartir y marcar como favorito, pero tu app realmente no navega. La clave es que tu app admite dos experiencias diferentes para la misma URL dependiendo de cómo llegó el usuario:

Hizo clic desde dentro de la app: La galería ya está renderizada; pushState agrega una entrada al historial para que el botón de retroceso funcione, y el modal se abre sobre la página existente.
Llegó directamente desde un enlace compartido: El +page.svelte real de /photos/123 se renderiza con carga completa de datos del lado del servidor, mostrando la foto en su propio contexto independiente.

Misma URL, dos experiencias diferentes, ambas correctas. Esto es mejora progresiva aplicada al estado de URL.

<script lang="ts">
	import { pushState } from '$app/navigation'
	import { page } from '$app/state'

	// The gallery data - stays loaded
	let photos = $state([
		/* ... */
	])

	function openPhoto(id: string) {
		// Update URL and store state, but DON'T navigate
		pushState(`/photos/${id}`, { selectedPhotoId: id })
	}

	function closePhoto() {
		// Go back in history (closes modal, restores previous URL)
		history.back()
	}

	// Derive modal visibility from state
	const selectedPhoto = $derived(
		page.state.selectedPhotoId ? photos.find((p) => p.id === page.state.selectedPhotoId) : null
	)
</script>

<!-- Gallery stays rendered -->
<div class="gallery">
	{#each photos as photo}
		<button onclick={() => openPhoto(photo.id)}>
			<img src={photo.thumbnail} alt={photo.title} />
		</button>
	{/each}
</div>

<!-- Modal overlays when photo selected -->
{#if selectedPhoto}
	<div class="modal-backdrop" onclick={closePhoto}>
		<div class="modal" onclick={(e) => e.stopPropagation()}>
			<img src={selectedPhoto.fullSize} alt={selectedPhoto.title} />
			<h2>{selectedPhoto.title}</h2>
			<button onclick={closePhoto}>Close</button>
		</div>
	</div>
{/if}

La URL muestra /photos/123 pero nunca salimos de la página de la galería. El usuario comparte el enlace, y quien lo recibe llega a la ruta /photos/123 con el contenido completo de la página.

El shallow routing se trata de intención. La URL /photos/123 significa "estoy viendo la foto 123." Pero cómo llegué ahí importa para la UX. ¿Haciendo clic desde la galería? Mostrar un modal. ¿Llegando desde un enlace compartido? Mostrar la página completa. La misma URL, experiencias distintas.

Patrón Avanzado: Precarga de Datos para Modales

El ejemplo anterior asume que la galería ya tiene todos los datos de las fotos. ¿Pero qué pasa si el modal necesita datos adicionales (imagen en alta resolución, comentarios, metadatos)?

preloadData de SvelteKit te permite obtener datos de una ruta sin navegar:

<script lang="ts">
	import { preloadData, pushState, goto } from '$app/navigation'
	import { page } from '$app/state'
	import PhotoDetail from './[id]/+page.svelte'

	async function openPhoto(id: string, event: MouseEvent) {
		// Don't interfere with ctrl+click (open in new tab)
		if (event.metaKey || event.ctrlKey || event.shiftKey) return

		event.preventDefault()
		const href = `/photos/${id}`

		// Fetch the data that /photos/[id] would load
		const result = await preloadData(href)

		if (result.type === 'loaded' && result.status === 200) {
			// Success: open modal with preloaded data
			pushState(href, { photoData: result.data })
		} else if (result.type === 'redirect') {
			// The route redirected (maybe photo was deleted)
			goto(result.location)
		} else {
			// Error loading data: fall back to full navigation
			goto(href)
		}
	}
</script>

<!-- Links work normally for accessibility, JS enhances them -->
{#each photos as photo}
	<a
		href="/photos/{photo.id}"
		onclick={(e) => openPhoto(photo.id, e)}
		data-sveltekit-preload-data="hover"
	>
		<img src={photo.thumbnail} alt={photo.title} />
	</a>
{/each}

{#if page.state.photoData}
	<div class="modal-backdrop" onclick={() => history.back()}>
		<div class="modal" onclick={(e) => e.stopPropagation()}>
			<!-- Render the actual page component with preloaded data! -->
			<PhotoDetail data={page.state.photoData} />
		</div>
	</div>
{/if}

Nota que usamos etiquetas <a>, no <button>. Esto es fundamental para la accesibilidad y el SEO. Los lectores de pantalla anuncian los enlaces correctamente, los motores de búsqueda pueden rastrearlos, y ctrl+clic abre nuevas pestañas. JavaScript mejora, no reemplaza.

`replaceState`: Actualizar Sin Historial

A veces quieres actualizar la URL sin crear una nueva entrada en el historial. Los filtros son el ejemplo clásico—cada pulsación de tecla en un cuadro de búsqueda no debería crear un paso en el botón de retroceso.

<script lang="ts">
	import { replaceState } from '$app/navigation'
	import { page } from '$app/state'

	function updateFilters(key: string, value: string) {
		const url = new URL(page.url)

		if (value) {
			url.searchParams.set(key, value)
		} else {
			url.searchParams.delete(key)
		}

		// Update URL without creating history entry
		replaceState(url, page.state)
	}
</script>

<input
	type="search"
	value={page.url.searchParams.get('q') ?? ''}
	oninput={(e) => updateFilters('q', e.currentTarget.value)}
	placeholder="Search..."
/>

<select onchange={(e) => updateFilters('sort', e.currentTarget.value)}>
	<option value="">Sort by...</option>
	<option value="newest">Newest first</option>
	<option value="price-low">Price: Low to High</option>
	<option value="price-high">Price: High to Low</option>
</select>

Usa pushState cuando: El cambio de estado es un "destino" (abrir un modal, ver un ítem)

Usa replaceState cuando: El cambio de estado es incremental (filtrar, ordenar, entrada en un formulario)

Hooks del Ciclo de Vida de Navegación: Control Total

SvelteKit te proporciona hooks para interceptar cada fase de la navegación. Aquí es donde implementas advertencias de "cambios sin guardar", animaciones de transición de página, analíticas e indicadores de carga personalizados.

Los Tres Hooks: Cuándo Se Ejecutan

User clicks link
       ↓
┌─────────────────────────┐
│   beforeNavigate()      │ ← Can CANCEL navigation
│   "Should we leave?"    │
└────────────┬────────────┘
             ↓
┌─────────────────────────┐
│   onNavigate()          │ ← Can DELAY navigation
│   "Prepare for change"  │   (View Transitions live here)
└────────────┬────────────┘
             ↓
      [ Navigation happens ]
      [ DOM updates ]
             ↓
┌─────────────────────────┐
│   afterNavigate()       │ ← React to completed navigation
│   "Navigation finished" │   (Analytics, scroll, cleanup)
└─────────────────────────┘

`beforeNavigate`: El Guardián

Este hook se ejecuta primero y puede cancelar la navegación por completo. Perfecto para proteger contra "cambios sin guardar":

<script lang="ts">
	import { beforeNavigate } from '$app/navigation'

	let hasUnsavedChanges = $state(false)
	let formContent = $state('')

	beforeNavigate((navigation) => {
		if (!hasUnsavedChanges) return // Let navigation proceed

		if (navigation.willUnload) {
			// User is leaving the site entirely (closing tab, external link)
			// cancel() here triggers browser's native "Leave site?" dialog
			navigation.cancel()
		} else {
			// Internal navigation - show custom confirmation
			if (!confirm('You have unsaved changes. Leave anyway?')) {
				navigation.cancel()
			}
		}
	})

	function handleInput(e: Event) {
		formContent = (e.target as HTMLTextAreaElement).value
		hasUnsavedChanges = true
	}

	function handleSave() {
		// Save logic...
		hasUnsavedChanges = false
	}
</script>

<form>
	<textarea oninput={handleInput} value={formContent}></textarea>
	<button type="button" onclick={handleSave}>Save</button>
</form>

Usa cancel() con moderación. A los usuarios no les gusta sentirse atrapados. Solo bloquea la navegación cuando haya trabajo genuinamente sin guardar, y siempre proporciona una forma clara de descartar los cambios y salir.

`afterNavigate`: Analíticas y Limpieza

Se ejecuta después de que la navegación se completa y el DOM ha sido actualizado. Aquí es donde registras vistas de página y gestionas el comportamiento del scroll:

<script lang="ts">
	import { afterNavigate } from '$app/navigation'

	afterNavigate((navigation) => {
		// Track page views with context
		analytics.track('page_view', {
			from: navigation.from?.url.pathname ?? '(entry)',
			to: navigation.to?.url.pathname,
			type: navigation.type,
			duration: performance.now() // Time since page load
		})

		// Custom scroll behavior based on navigation type
		if (navigation.type === 'link' || navigation.type === 'goto') {
			// User intentionally navigated - smooth scroll to top
			window.scrollTo({ top: 0, behavior: 'smooth' })
		}
		// 'popstate' (back/forward) - browser handles scroll restoration
	})
</script>

No le hagas la contra al navegador en el scroll con popstate. Los usuarios esperan que el botón de retroceso/avance los regrese a su posición de scroll anterior. Romper esta expectativa es un error común de UX.

Conclusión

Los patrones de enrutamiento avanzado en SvelteKit revelan la verdadera flexibilidad del framework: la capacidad de romper convenciones cuando es necesario, manteniendo los beneficios del enrutamiento basado en convenciones. Los param matchers proporcionan validación de parámetros con seguridad de tipos en la capa de enrutamiento, los grupos de rutas organizan aplicaciones complejas sin contaminar las URLs, la ruptura de layouts permite páginas independientes cuando la jerarquía no encaja, el shallow routing crea URLs de modales compartibles, y los hooks de navegación proporcionan control del ciclo de vida para guardias, preparación y analíticas.

Dominar estos patrones significa saber cuándo usarlos y cuándo seguir con los valores predeterminados. La mayoría de las aplicaciones prosperan con las convenciones de SvelteKit, pero las aplicaciones en producción inevitablemente se encuentran con casos donde los patrones estándar necesitan ser complementados. Al entender los param matchers para el versionado de rutas de API, los grupos de rutas para secciones autenticadas, el shallow routing para estados de modales, y los hooks de navegación para la integración de analíticas, construyes aplicaciones que manejan la complejidad con elegancia sin luchar contra el framework. Estas no son escotillas de escape—son herramientas poderosas que complementan los fundamentos del enrutamiento.

Puntos Clave

Los param matchers validan parámetros de ruta en la capa de enrutamiento usando archivos src/params/*.js, proporcionando validación de parámetros con seguridad de tipos antes de que los componentes se rendericen
Los grupos de rutas organizan layouts usando paréntesis como (authenticated) para crear jerarquías de layout sin afectar las URLs, ideal para rutas protegidas
La ruptura de layouts con la sintaxis @ permite que las páginas omitan los layouts padre: +page@.svelte se renderiza directamente bajo la raíz, escapando de la jerarquía normal de layouts
El shallow routing actualiza URLs sin navegación usando pushState y replaceState para diálogos modales, filtros o pestañas donde una navegación completa perdería el estado del componente
beforeNavigate habilita guardias de navegación para advertencias de cambios sin guardar, verificaciones de autenticación, o redirecciones condicionales antes de que la navegación se complete
onNavigate prepara los cambios de página - ideal para View Transitions, manejo del scroll, o estados de carga que necesitan iniciarse antes de que la nueva página se renderice
afterNavigate rastrea la navegación completada para analíticas, gestión del foco, u operaciones de limpieza que deben ocurrir después de que la nueva página sea visible
Los param matchers permiten validación personalizada - crea matchers como integer, slug, o uuid para asegurarte de que las rutas solo coincidan con formatos de parámetros válidos

Ver También

Documentación Oficial de SvelteKit - Enrutamiento Avanzado
Param Matchers - Validación personalizada de parámetros
Grupos de Rutas - Patrones de organización de layouts
Hooks de Navegación - beforeNavigate, onNavigate, afterNavigate
Shallow Routing - pushState y replaceState
Ruptura de Layouts - Sintaxis de reset con @
Enrutamiento Experto - Patrones de arquitectura en producción