Next.js
Explica cómo construir navegación y formularios sobre HTML funcional, añadiendo prefetch, pending, optimismo, scroll y recuperación sin perder intención.
Progressive enhancement parte de una experiencia HTML funcional y añade navegación cliente, pending, optimismo y prefetch sin convertir esas mejoras en requisitos para comprender o recuperar una operación. En Next.js, la UX resiliente aparece cuando URL, forms, streaming y errores conservan intención incluso con JavaScript lento o red inestable.
HTML semantics and server response
↓
client hydration and navigation
↓
pending feedback
↓
optimistic enhancement when safe
↓
confirmed server result or recoveryNo toda feature necesita funcionar sin JavaScript, pero empezar desde primitivas nativas reduce estados frágiles.
<Link href={`/portfolio/${project.slug}`}>
{project.title}
</Link>Antes de hydration, el link sigue siendo un anchor navegable. Después, Next.js intercepta y realiza navegación cliente.
Frente a:
<button onClick={() => router.push(path)}>Abrir</button>El botón depende de JavaScript y pierde abrir en nueva pestaña, copiar enlace y semántica.
<form action={createContactRequest}>
<label htmlFor="email">Correo</label>
<input id="email" name="email" type="email" required />
<button>Enviar</button>
</form>La Action puede procesar FormData en servidor. Un Client Component añade:
useActionState.La lógica autoritativa permanece en servidor.
Link prefetchea rutas cuando entran al viewport según tipo de ruta/configuración. Esto puede descargar loading states, RSC payload y chunks antes del click.
Menor latencia percibida.
Puedes desactivar:
<Link href="/heavy-report" prefetch={false}>
Reporte pesado
</Link>Hazlo para rutas muy costosas o enlaces masivos después de medir. No desactives globalmente por miedo.
"use client";
export function IntentLink({ href, children }: Props) {
const router = useRouter();
return (
<Link
href={href}
prefetch={false}
onMouseEnter={() => router.prefetch(href)}
onFocus={() => router.prefetch(href)}
>
{children}
</Link>
);
}Hover y focus indican intención. Incluye focus para teclado.
No prefetches en cada mousemove ni rutas con datos privados que no deberían adelantarse sin necesidad.
loading.tsx permite mostrar una respuesta inmediata mientras llega la page:
click
→ prefetched loading shell appears
→ dynamic content streamsLa UI debe conservar navegación y heading. Un spinner de pantalla completa puede sentirse más lento que mantener la página anterior.
Next router integra transitions, pero para un link individual puedes usar useLinkStatus bajo APIs actuales o un wrapper que lea pending según la versión. Antes de depender de APIs recientes, confirma estabilidad.
Patrón genérico:
aria-current para ruta actual.No muestres “Cargando” en todos los links por prefetch.
Flow robusto:
input draft local
→ submit form / update URL
→ server validates searchParams
→ loading/stale results
→ new resultsFormulario GET:
<form action="/products" method="get">
<label htmlFor="query">Buscar</label>
<input id="query" name="query" defaultValue={query} />
<button>Buscar</button>
</form>Funciona sin JS y genera URL compartible. Un Client Component puede aplicar debounce y router.replace, pero conserva submit explícito para accesibilidad/resiliencia cuando sea útil.
Por defecto, Next.js gestiona scroll en navegación. scroll={false} conserva posición:
<Link href={nextFilterUrl} scroll={false}>
Aplicar filtro
</Link>Úsalo cuando actualizas una región de la misma pantalla. En una nueva page, llevar al inicio o al contenido principal suele ser esperado.
No uses scroll={false} globalmente; puede dejar al usuario en mitad de una pantalla nueva.
Después de navegación:
No fuerces focus() al h1 en cada search param; diferencia página nueva de actualización local.
Patrón Post/Redirect/Get conceptual:
POST Action
→ commit
→ invalidate
→ redirect GET detailEvita reenvío al refresh y produce URL canónica.
Para edición inline, devolver state puede ser mejor que navegar.
El historial forma parte del producto:
No bloquees back con hacks de history. Usa rutas y state bien modelados.
Browser beforeunload es limitado y muestra texto controlado por el navegador. Úsalo solo cuando perder datos es posible.
Para navegación cliente, un patrón de confirmación requiere integración cuidadosa; no existe una API universal estable que intercepte toda transición del App Router como en routers clásicos.
Mejoras:
No muestres confirmación por cualquier cambio cosmético.
function SubmitButton() {
const { pending } = useFormStatus();
return (
<button disabled={pending}>
{pending ? "Enviando…" : "Enviar"}
</button>
);
}aria-busy en la región.Pending no significa éxito.
Aporta para operaciones reversibles. Muestra estado sending, no “enviado” hasta confirmación.
Preserva IDs temporales, rollback y conflictos. No optimices pagos o permisos como éxito definitivo.
Puede usar shell cacheada, browser HTTP cache o service worker si existe.
Si no se confirmó:
No limpies el formulario solo porque se pulsó submit.
Un service worker añade complejidad de versiones y no forma parte automática de Next.js.
Si una región tarda, un skeleton infinito no explica nada. Después de un umbral puedes mostrar:
“Aún estamos cargando el reporte. Puedes seguir usando otras secciones.”El timeout técnico servidor y el mensaje UX pueden tener umbrales distintos.
Un error debe conservar intención:
Ofrece retry cuando la operación es segura. Para una mutation incierta, consulta el estado antes de repetir.
No deshabilites un botón solo porque el form está inválido sin explicar por qué; puede ser difícil descubrir requisitos. Permitir submit y mostrar errores suele ser más accesible.
Si disabled:
Guía aproximada, no regla rígida:
<100ms → inmediato
100–1000ms → pending sutil
>1s → feedback explícito
>varios segundos → progreso/contexto/cancelaciónNo muestres spinner por operaciones instantáneas si causa flicker. Puedes retrasar su aparición, pero no ocultar una espera larga.
Búsquedas pueden abortarse o la navegación descartar el resultado. Jobs/reportes necesitan botón cancel si consumen recursos y la backend lo soporta.
Cerrar un modal cliente no necesariamente cancela una Server Action ya enviada. Diseña la operación servidor para completar/idempotencia.
Next.js/React pueden ofrecer integraciones experimentales o recientes con View Transitions según versión. No dependas de una API experimental como requisito de navegación. CSS/Framer Motion pueden animar regiones, pero:
Registra navegación confirmada, no prefetch. Para funnels:
intent click
navigation complete
form submitted
server confirmedSon eventos distintos. No marques conversión al iniciar optimismo.
Depende de JS y no es navegable.
Borra contexto.
Desperdicia red.
Pierde datos ante error.
Engaña.
Nueva page inicia en posición absurda.
Rompe expectativas.
Fatiga al usuario.
Bundle analysis y optimización de dependencias mide qué código, CSS y terceros pagan estas experiencias antes de aplicar microoptimizaciones.