Next.js desde Cero (App Router)

Routing y layouts en el App Router En el App Router de Next.js, la carpeta app/ es la fuente de verdad de tu navegación: cada carpeta es un segmento de URL y cada archivo page.tsx convierte ese segmento en una ruta accesible. No hay configuración manual de rutas ni un archivo de mapeo central; la estructura de carpetas es el routing. Esto reduce errores y hace que la arquitectura del proyecto se entienda de un vistazo. Las piezas que debes dominar page.tsx: hace pública la ruta. Sin él, la carpe

Server Components vs Client Components En el App Router, todos los componentes son Server Components por defecto. Se renderizan en el servidor, no envían su código JavaScript al navegador y pueden acceder directamente a la base de datos, leer archivos o usar secretos. Solo cuando un componente necesita interactividad del navegador lo conviertes en Client Component añadiendo la directiva "use client" en la primera línea del archivo. La regla práctica Mantén todo como Server Component salvo que ne

Estados de UI: loading, error y not-found Una aplicación real nunca está siempre en su estado "feliz": hay esperas, fallos de red y URLs que no existen. El App Router te da archivos especiales para cubrir cada caso sin tener que cablear manualmente la lógica. Cada uno se coloca dentro de la carpeta de la ruta y Next los conecta automáticamente. Los tres archivos clave loading.tsx: se muestra mientras el Server Component asíncrono está cargando. Por debajo, Next lo envuelve en un <Suspense>

Data fetching: cuándo cachear y cuándo no En el App Router obtienes datos directamente dentro de los Server Components con await fetch() o consultando tu base de datos. La gran decisión no es cómo traer los datos, sino cuánto tiempo reutilizarlos. Elegir bien entre datos estáticos, revalidados o siempre dinámicos define la velocidad y la frescura de tu app. Las tres estrategias EstrategiaCuándo usarlaCómo activarla Estática (cache permanente)Contenido que casi no cambiaPor defecto en muchos fetc

Server Actions: formularios sin API extra Las Server Actions son funciones que se ejecutan en el servidor pero que puedes invocar directamente desde un formulario o un evento del cliente, sin crear endpoints de API a mano. Se marcan con la directiva "use server" y son la forma moderna de mutar datos en el App Router: el formulario envía, la función valida y escribe en la base de datos, y luego refrescas la UI. Anatomía de una Server Action // app/tareas/actions.ts "use server"; import { z } from

Auth basica Protege rutas server y API. Regla: auth en servidor y checks de ownership. Conceptos clave Session en server Middleware (opcional) Ownership checks Ejemplo Si un usuario no es owner, devuelve 403 o 404 segun el caso. Ejercicio Protege una ruta /dashboard. Protege un endpoint /api/resource/:id con ownership. Checklist de mastery No hay datos privados sin auth. Hago ownership checks siempre.

Metadata Buenas pages tienen metadata consistente: title, description, canonical y OG para shares. Conceptos clave Metadata por pagina Canonical para evitar duplicados OG images Ejemplo Ejemplo: alternates.canonical y openGraph.images. Ejercicio Agrega metadata a una pagina de curso. Agrega OG image via /api/og. Checklist de mastery Todas las pages clave tienen canonical. Tengo OG share listo.

Sitemap y robots SEO tecnico minimo: sitemap.xml con URLs importantes y robots.txt que no bloquee accidentalmente. Conceptos clave Sitemap dinamico (revalidate) Robots allow/disallow Noindex para contenido unlisted Ejemplo Incluye /cursos, /carreras, /blog y guias programaticas. Ejercicio Agrega /blog al sitemap. Bloquea /api y rutas privadas en robots. Checklist de mastery Search engines encuentran mis URLs. No indexo contenido privado.

Performance Performance es conversion. Aprende prioridades: reduce JS, optimiza imagenes y evita render bloqueante. Conceptos clave Server components por defecto next/image (cuando aplica) Evitar animaciones pesadas sin reduced-motion Ejemplo Regla: si algo es decorativo, que no sea JS pesado. Ejercicio Revisa 1 pagina y elimina una dependencia client innecesaria. Agrega soporte a prefers-reduced-motion (si hay animaciones). Checklist de mastery Uso server-first. Pienso performance como feature.

Landing Define un hero con promesa clara, social proof y un CTA que resuelva el primer paso. Conceptos clave Promesa clara 1 CTA principal Secciones con prueba Ejercicio Escribe 1 headline + subheadline. Agrega 3 secciones: como funciona, ejemplo, pricing. Checklist de mastery Mi landing tiene un CTA principal. La promesa se entiende en 5 segundos.

Blog Un blog bueno es distribucion y SEO. Hazlo simple: posts, RSS, y buen interlinking a cursos/carreras. Conceptos clave Index + post page RSS Links a recursos del producto Ejercicio Crea 3 posts con CTA a /explore. Agrega RSS y sitemap entries. Checklist de mastery Tengo RSS funcionando. Los posts empujan a acciones reales.

Deploy checklist Antes de lanzar: healthcheck, env vars, logs y que tus rutas criticas respondan 200. Conceptos clave Health endpoint Env vars completas Sentry/logs Ejercicio Verifica /api/health, /cursos, /carreras, /blog. Simula un error y aseguralo en logs/Sentry. Checklist de mastery Tengo healthcheck. Puedo debugear fallos rapido.