El curso es de NextGS desde cero, no de programación desde cero, ni de React desde cero, iré explicando, tampoco te puedo enseñar JavaScript desde cero, no puedo hacer siempre curso desde cero de toda la programación, ¿vale? Pero sí que es NextGS como si no lo supieras, ¿vale? O sea, vamos a dar por sentado que no sabes NextGS y eso es lo importante.
Lo que es desde cero es lo de NextGS y vamos a seguir justamente el patrón, bueno, la cursa, la guía que tiene la gente de Vercell que han sacado, que tiene muy buena pinta y que así a las malas, pues tú podrás seguir. Es este de aquí. Start building with NextGS. Está en inglés, pero yo te lo voy a comentar en español, ¿vale? En castellano. En español es español para que lo puedas seguir.
Si por lo que sea queréis una guía de React desde cero, que sepáis que tenéis este Learn React Foundations o, mejor todavía, aprendiendo, no, aprende, aprende React, ¿no? Aprende React. Tienes este curso para aprender React desde cero y aquí tienes 13 proyectos prácticos para aprender React desde cero hasta, es que hicimos todos estos proyectos, 14 proyectos hicimos, 14 proyectos.
Ahí sí que aprende React desde cero. Y hoy vamos a aprender NextGS, que es un framework, pero claro, no voy a poder explicarte qué es un estado o qué es no sé qué, porque si no estaríamos en una bola constante.
Así que, si quieres aprender React, si hoy hay alguna cosa que quieres practicar React que es que no te queda clara, aquí tienes un montón de vídeos con proyectos, con código abierto, o sea, lo tienes todo aquí, ¿ok?
Y ahora, hoy lo que vamos a hacer es el curso de NextGS 14 siguiendo el curso que tiene la gente de esta, ¿eh? Que si no luego la gente me viene al YouTube, te lo has copiado, esto te lo has copiado de la página de Vercell,
que me voy a copiar si os estoy diciendo que lo vamos a seguir, porque me parece súper interesante, la verdad, que lo sigamos ahí.
Y además, es muy curioso, es un curso totalmente distinto a lo que estamos acostumbrados, porque vienen cosas ya preparadas y lo único que tienes que hacer es como ir uniendo los puntos utilizando cosas de NextGS.
Y así entiendes para qué sirve NextGS y qué cosas te puede ofrecer NextGS, incluso algunas de Vercell, lo cual está súper, súper bien, ¿eh?
Bueno, amigos, empezamos con el curso de NextGS, el curso de NextGS 14 desde cero. La semana pasada, resulta que la semana pasada anunciaron NextGS 14.
Lo bueno de NextGS 14, aunque haya subido una versión mayor, hay que tener en cuenta que no ha traído muchas cosas nuevas más allá de hacer estable cosas que antes no lo estaban.
Pero, como ya hemos dicho, esto va a ser un curso desde cero. No voy a dar, por supuesto, que sabes ya NextGS.
Así que si no sabes NextGS, o si ya sabes y quieres repasar, voy a dar por sentado que no tienes ni idea de qué es NextGS, ¿vale?
Y por eso lo vamos a utilizar.
Entonces, ¿qué es NextGS? Es el framework de React más popular ahora mismo que existe en Internet, sin ningún tipo de duda, ¿vale?
¿Por qué? Porque si tú necesitas hacer con React una página con cara y ojos, que se renderice en el servidor, que tenga buen SEO, que tengas optimizaciones,
que puedas hacer rutas de APIs, un montón de cosas, vas a utilizar NextGS, ¿vale?
Porque es que NextGS te da un montón de características que muy fácilmente puedes construir una aplicación.
Y puedes tener rutas, puedes tener fetching de datos, optimizaciones muy chulas como React Server Components, un montón de cosas, ¿vale?
¿Hay alternativas a NextGS? Sí que las hay.
Tenemos, por ejemplo, Remix, bueno, Remix Build, claro, yo pensando que Remix solo para desarrollo, pero Remix es para cualquier cosa.
Entonces, tendríamos Remix, una alternativa bastante interesante que está ganando popularidad, pero todavía no está al nivel, ni mucho menos, de NextGS.
Y también tendríamos Astro Build, otra alternativa, aunque Astro Build no es solo de React, sino que lo podéis utilizar con React, con Vue, con Svelte, incluso con nada.
Así que sería un framework que es una alternativa, pero que en realidad puedes utilizarlo con más bibliotecas, no solo con React.
Pero hoy nos enfocamos en NextGS.
NextGS tiene un montón, como os decía, un montón de cosas interesantes, como los React Server Components, que los veremos, los comentaremos.
Tienes soporte a CSS Modules, tienes renderizado tanto en el cliente como en el servidor, streaming del HTML, que también lo vamos a ver,
optimizaciones de imágenes, de fuentes, que también lo vamos a ver, una forma fácil de hacer data fetching desde el servidor,
creación de rutas de APIs súper fácil en la misma aplicación, sin necesidad de tener que desplegarlas aparte.
Tiene un montón, pero un montón de cosas, ¿vale?
Y NextGS la está utilizando, y cada vez más, empresas muy top.
De hecho, hay mucho, pero mucho trabajo que utiliza NextGS.
Y es que es normal, se ha monopolizado las cosas como son.
NextGS se está utilizando cada vez en más aplicaciones y páginas web.
Nike utiliza NextGS, AWS, GitHub, Netflix Jobs, TikTok, Twitch, Notion.
Es que da igual donde mires, no importa donde mires, que es que está utilizando NextGS de una forma o completa, o a trozos, o lo que sea.
Porque es que la verdad es que te facilita muchísimo, muchísimo el desarrollo.
¿Cómo se inicializaría un proyecto de NextGS?
Si tuviésemos NPM, que es el caso más típico, si ya tienes instalado Node, sería npx create next app arroba latest.
Y sería así, ¿vale?
npx create next app arroba latest.
Esto es para asegurarnos que utilizamos la última versión y que no utilizamos una versión antigua que tenemos nosotros ahí guardada.
npx, esto viene, es un comando para instalar e ejecutar directamente, ¿vale?
No instalar en nuestra máquina, sino instalarlo, borrarlo y ejecutar un proceso donde nos va a crear una aplicación de NextGS desde cero.
Y esto cuando lo ejecutamos, además, ya nos va a hacer unas cuantas preguntas de cómo se llama el proyecto que queremos hacer, ¿vale?
Pues aquí vamos a poner ejemplo.
Por ejemplo, si queremos utilizar TypeScript o no, le vamos a decir que sí.
Si queremos utilizar el linter, si queremos utilizar Tailwind, si queremos utilizar un directorio source donde vamos a poner todo nuestro código fuente.
Si vamos a utilizar el app router, que es una de las características más importantes que a día de hoy tiene NextGS,
que es cómo vamos a separar las rutas de nuestra página o nuestra aplicación para que funcione, por defecto le vamos a poner que sí,
y un alias de los imports para no tener que poner la ruta relativa y simplemente poner arroba slash y ya poner una ruta que va desde la raíz.
Luego lo vamos a ver más claro para que no tengas ningún problema.
Y fíjate, ya te instalan las dependencias y ya lo tendrías.
Pero al final una cosa muy importante de NextGS que tienes que tener en cuenta es que la base es que es un framework de React.
Por lo tanto, todo lo que ya sabes de React te va a servir también con NextGS.
Podríamos hacer lo mismo de siempre que al final hacemos en todos y cada uno de los cursos,
que es empezar desde lo cero un proyecto en blanco, crear los componentes y tal.
Pero la gente de NextGS ha creado un curso que a mí me ha parecido que está muy interesante,
que te permite, pues con unos componentes ya creados, ir siguiendo unos pasos para entender cómo funciona y qué ventajas te da NextGS.
Me lo voy a poner por aquí para irlo siguiendo.
Son 16 capítulos, va desde el principio y paso a paso se van haciendo diferentes cosas.
Optimizaciones, fetching de datos, conectar a una base de datos, un montón de cosas que las vamos a ir viendo.
Así que yo te lo voy a ir explicando en español, pero es el que vamos a seguir.
Así que si en algún momento tienes que revisar, mirar si el código está, si lo has entendido bien y tal,
pues que sepas que puedes ir aquí a nextGS.org barra learn y ahí vas a tener la posibilidad de revisarlo.
Así que le damos a Start Learning para empezar y ahora esto es lo que nos dicen que vamos a crear.
Vamos a crear un dashboard y fijaos que vamos a tener incluso la posibilidad de tener rutas privadas.
Vamos a ver cómo en el dashboard se va a cargar cada una de las secciones, cómo funcionan las rutas anidadas,
cosas que son más o menos avanzadas, pero que con NextGS es muy, muy sencillo de lograr.
Y esto es lo que tendría que aparecer al final en nuestra página.
Mira, fíjate, tiene búsqueda, paginación, creación, tienes también tablas, tienes diferentes rutas, tienes login.
Hay un montón de cosas, ¿vale? Y las vamos a ir viendo.
Vamos a ver cómo se empieza un poquito esto. Bueno, esto es un poco lo que os he ido comentando.
De nuevo, requerimientos, ¿vale? Requerimientos. Tienes que saber JavaScript, estaría bien que sepas React.
Si hay cosas de React que, o si sabes React pero no del todo, yo creo que no pasa nada,
porque hay cosas que a lo mejor pues con el contexto lo entiendes y tal,
pero bueno, vas a ver que lo que se utiliza de React es bastante básico,
con monetización, props, algún estado, pero tampoco muchas cosas más, ¿vale?
Otro requerimiento, que tengas Node.js 18 como mínimo instalado en tu máquina.
Y finalmente, pues nada, cualquier sistema operativo debería funcionar.
Además, vendría bien que tuvieses una cuenta de GitHub y una cuenta de Vercell,
porque llega un momento que para crear la base de datos lo hacemos en Vercell,
es totalmente gratuita, en este caso no deberías pagar absolutamente nada para tener esa base de datos
y te va a venir bien porque así vas a poderlo seguir sin ningún problema.
Y eso sería todo, aparte del editor y todas las cosas obvias que normalmente vamos a tener.
Entonces, vamos a empezar capítulo 1 y aquí ya nos dice que creemos un proyecto.
Sí, las server actions también las veremos, evidentemente, pero van más adelante cuando se crean los recursos.
Vamos a ver si nos da tiempo, ¿vale?
Vale, ya nos dice de cómo crear un proyecto.
Crear un proyecto, como hemos visto, es npx create next app arroba latest, como os he comentado antes.
Le puedes pasar directamente el nombre, pero fíjate que aquí hay dos cosas que se están añadiendo, dos parámetros.
Uno, este sería para asegurarse que estamos utilizando npm.
Esto, dependiendo del administrador de paquetes que utilices, igual quieres utilizar ban, yarn, lo que sea.
Y otro parámetro que es example.
Y esto es muy interesante, que te puede resultar curioso.
Y es que puedes inicializar un proyecto de Next.js y en lugar de empezarlo desde cero o desde el playground típico que te creas,
lo puedes crear a través de un repositorio y eso está súper chulo porque al final hay repositorios que a lo mejor te dejan la base
para crearte un dashboard, para crearte una página como Netflix, para crearte un proyecto de inteligencia artificial
y así no empiezas desde cero y empiezas desde una base, ¿vale?
Y aquí justamente lo que estamos haciendo es utilizar como el template del dashboard,
como un starter que ya va a tener una plantilla preestablecida con componentes, archivos,
para no tener que empezar desde cero.
Pues venga, lo vamos a utilizar, copiamos este comando, nos vamos a nuestra terminal,
lo pegamos aquí, le damos al enter y va a hacer exactamente lo mismo que antes,
pero nos va a hacer unas cuantas menos preguntas porque total, ya ha visto que hemos pasado parámetros
y dice, ah, bueno, pues ya sé más o menos lo que tengo que hacer.
Nos lo ha debido crear a Next.js Dashboard.
Next.js Dashboard.
Aquí ya tenemos todo nuestro proyecto, lo vamos a abrir en el editor
y ahora te explico los archivos que ha creado, cómo funciona esto, qué es lo que tiene de especial
y también voy a aprovechar a hacer un npm run para que veamos los scripts, ¿vale?
Siempre en cada proyecto que iniciemos siempre miramos los scripts porque así vamos a saber
cómo levantar el proyecto, cómo se tienen que testear, cómo hacer cualquier cosa.
Tenemos un start, que esto sería el más el de producción que no el de desarrollo.
Tenemos la build, que sería para crear, empaquetar nuestra aplicación, muy típico,
y el dev, que sería el de desarrollo, y ese es el que nos interesa.
Así que hacemos npm run dev para ejecutar el modo desarrollo
y ya nos lo está dejando en el puerto 3000 y, ojo, nos dice que estamos utilizando
la versión 14.0.0.
Solo para que lo sepas, que todavía no es 100% estable, pero igual te interesa,
existe una forma para hacer que vayan todavía más rápidas las builds
que es utilizando el modo turbo.
Y fíjate que habrá tardado solo 740 milisegundos, dos segundos menos.
Esto es lo que está haciendo es utilizar, por defecto, está utilizando Webpack,
pero Vercell Next.js está transicionando a una nueva versión de una especie de Webpack
que está chata con Rust, que se llama Turbo Pack.
Así que, si por lo que sea, pues quieres probar que vaya más rápido, lo que sea,
pues pones el turbo, pero no es 100% estable, ¿ok?
Lo digo por si lo encuentras.
Igual cuando veas este vídeo o si lo ves en el futuro, pues ya es estable
y ya lo puedes utilizar, pero a día de hoy no lo es, ten cuidadito.
Muy bien, vamos a dejar el turbo, a ver si no funciona y no nos da ningún problema
y vamos al localhost 3000 a ver qué es lo que nos ha cargado.
Bueno, nos ha cargado esta página, que no es que sea la más bonita del mundo,
simplemente es una página en blanco que tiene aquí un título que nos da la bienvenida,
nos dice que es un ejemplo, que nos lo ha traído Vercell y tenemos aquí un login.
Bueno, por ahora, pues no tiene mucha historia.
Vamos a ver un poquito el código, a ver si tiene alguna cosa interesante realmente.
Vemos unos cuantos archivos de configuración, está utilizando por defecto TypeScript,
nosotros vamos a seguir utilizando TypeScript, aunque no es muy difícil
ni hay ninguna complicación.
Si no sabes TypeScript, no te preocupes, lo vas a poder seguir sin problemas.
También tiene ya toda la configuración de Tailwind por defecto.
Tailwind es un framework CSS que cada vez se utiliza más y sería bastante interesante
que lo sepas utilizar, más configuraciones que yo las tengo agrupadas aquí en el Package JSON.
¿Vale? Por eso me sale así, porque no me gusta ver tantos archivos de configuración
y con Visual Studio Code puedes agrupar en un archivo otros archivos.
Y yo tengo todos los de configuración y los tengo agrupados aquí.
Tenemos aquí el de PodCSS, que esto lo necesita Tailwind para funcionar.
El PackageLock, porque esto cuando utilizamos MPM para instalar,
tenemos las dependencias aquí fijadas, que nos funciona bastante bien para Continuous Integration,
para que vaya más rápido a la instalación.
La configuración de Next.js, que está totalmente, está pelada, ¿vale?
No hay ninguna historia, no hay ninguna configuración especial, está vacía.
El Gitignore, con todos los archivos que queremos ignorar en nuestro repositorio de GitHub,
o bueno, de Git o de GitHub en este caso, porque lo haremos en GitHub.
Las reglas de Slim, fíjate que ya Next.js te viene con reglas de Slim,
que son las de la Core Web Vitals.
Ya te viene con unas reglas que se va a asegurar, luego lo veremos.
Se va a asegurar que tu aplicación es rápida por defecto, ¿no?
Y cuando vas a utilizar alguna cosa que dice, uy, esto te va a dar problemas, ya te va a avisar.
Y el Package.json, que tendríamos todas las dependencias que necesitamos.
En este caso, hay más dependencias de lo normal, porque ya hay algunos archivos creados, ¿no?
Y tenemos, por ejemplo, iconos, tenemos, por ejemplo, CLSX, tenemos Zot.
Hay algunas dependencias aquí que no vienen por defecto normalmente,
pero como ya es una plantilla, ya vienen creadas, ¿vale?
Tenemos nvm-rc, y esto es un archivo que va a intentar detectar qué versión de Node es la que tiene que utilizar.
Por eso la he puesto la 18.
Vamos ahora con las carpetas.
Tenemos scripts.
Scripts, esto lo ha creado la plantilla.
Y tenemos un archivo sit, porque esto lo que va a hacer este archivo,
es básicamente cuando lo ejecutemos, nos va a inicializar toda una base de datos.
No es importante que se pase SQL, pero esto es una cosa muy típica.
A veces tenemos proyectos y para no tener que hacer un JSON a mano o si queremos utilizar una base de datos,
tenemos un archivo que se le llama como semilla, que al ejecutarlo te crea toda la estructura de la base de datos.
Entonces, no es importante que sepas lo que hace, o sea, cómo lo hace, sino que sepas lo que hace en general, ¿vale?
Luego tendríamos la carpeta public.
Aquí es donde vamos a tener todos los archivos estáticos que queremos que se sirvan como imágenes, vídeos, audios y cosas así.
En este caso tenemos imágenes que vamos a utilizar en nuestra página y que vamos a querer servir desde nuestra web.
Vamos a poder cargar estas imágenes y las tenemos en public.
Y finalmente tenemos la carpeta más importante de Next.js, que es la carpeta app.
En la carpeta app, lo más básico que vamos a tener es el archivo page.tsx.
Cada vez que nosotros queramos crear una ruta en nuestra página, vamos a crear un archivo page.tsx, en el caso de TypeScript,
o page.jsx, en el caso que utilicéis JSX con JavaScript y ya está.
¿Y qué es lo que hace esto? Esto lo que hace es crearnos una ruta.
Y dependiendo de la anidación de las carpetas, que esto lo vamos a ver en el curso, no te preocupes,
vamos a crear diferentes enrutamientos para nuestra aplicación.
Y por lo tanto, nuestra aplicación, lo más básico que tiene una web, es entrar a la página, ¿no?
A la página que tendríamos aquí, nada más entrar, que digamos que sería la ruta, por defecto sería esta, la barra.
Entonces, nada más entrar en la carpeta app, tendríamos el page.tsx.
Y todo lo que vemos aquí, ¿ves? Este welcome to acme, o bienvenido al curso, ¿vale?
Si lo cambiamos, vas a ver que es justamente lo que se está cargando aquí.
Así que, este componente sería el componente que se está cargando en esa ruta.
El contenido que estáis viendo aquí, sería el contenido que tenemos acá.
¿Qué más tenemos? Tenemos más cositas.
Tenemos un layout.tsx, que esto lo que va a hacer es envolver esa página.
En este caso, imagínate, este children sería este page.tsx, ¿vale?
Pero, ¿qué podemos hacer en este body? Pues imagínate que queremos que todas las rutas que estén por debajo de la página principal tengan este título.
Si ahora guardamos, vamos a ver que aquí tenemos este título.
Y esta sería la parte de la página. O sea, esto sería el layout, que sería lo que envuelve.
O mira, también lo podemos hacer así, para que lo vean más claro.
Vamos a hacer esto así, esto así, esto así.
Y vamos a poner que esto tenga un borde negro, ¿vale?
Y, ¡ay! No se puede hacer así. En React se tiene que hacer así, ¿vale?
¿Vale? Fíjate, lo que tenemos fuera del borde sería el layout, sería lo que envuelve el children.
¿Y qué es el children? El children es el page.tsx.
¿Y por qué es importante tener la separación de layout y page?
Pues es muy interesante porque el layout al final va a envolver nuestra aplicación y nuestras rutas.
Pero las rutas puede ser que cambie. O sea, no es lo mismo cuando estemos en la página principal que cuando estamos en la página about.
Pero a lo mejor queremos que el layout, lo que sería lo que envuelve nuestra página, sea el mismo y que no recargue.
Y luego lo vas a ver mucho más claro con los ejemplos que vamos a hacer, ¿vale?
Así que ya tendríamos un poco esto y nos quedarían dos carpetas aquí que tenemos que nos han creado, ¿no?
Tendríamos UI, que estos son simplemente componentes ya creados.
Son componentes, todos son componentes para que nosotros no los tengamos que crear.
Son componentes y ya está. Aquí es donde ha puesto todos los componentes para que nosotros los utilicemos,
aparte de un CSS que es el que vamos a tener que cargar.
Y luego tendríamos una carpeta lib.
¿Y la carpeta lib normalmente qué es lo que hace?
En la carpeta lib lo que solemos tener son las herramientas para hacer fetching de datos,
tenemos utilidades, tenemos definiciones y aquí tenemos, por ejemplo, las definiciones.
Estos son todos los tipos para TypeScript que vamos a utilizar en nuestra aplicación.
Como podéis ver, es un dashboard sobre facturas, clientes y cosas así, ¿ok?
Y luego tendríamos data, que data es para hacer el fetching de datos.
Hay cosas que están comentadas, que iremos comentando.
Y esto lo que hace es conectarse directamente con una base de datos Postgre,
que esto lo haremos después, pero por ahora no lo vamos a necesitar.
Luego tendríamos aquí Playholder Data, que esto sería en el caso de que no queramos hacer el fetching de datos con SQL,
lo podríamos hacer con Playholder, pero no lo vamos a saltar y iremos con la base de datos directamente.
Y luego tendríamos aquí diferentes utilidades, pues para formatear la moneda, para formatear la fecha,
para generar un eje en I para las gráficas, para generar una paginación, lo iremos viendo.
¿Vale? Muy bien. Entonces, con esto ya tendríamos toda la estructura interesante de lo que nos ha creado.
Vamos a hacer algo. Vamos a empezar ya, porque esto nos ha quedado así un poco feo, ¿no?
Lo primero que querríamos hacer con un proyecto de Next.js es cómo podemos cargar los estilos para que no se vean así.
Normalmente, si inicias un proyecto ya con Tailwind, como hemos visto antes, de seguir paso a paso,
cómo tiene que ser, normalmente lo que vas a tener es que vas a encontrarte la configuración ya hecha y ya está.
Pero ya sea con Tailwind o ya sea una configuración que tú quieras hacer, normalmente vas a querer tener unos estilos globales.
¿Vale? ¿Cómo se cargarían unos estilos globales en Next.js y dónde tendría sentido?
En este caso hemos dicho que en la app tendríamos el layout que sería para toda la página.
Porque fíjate que el layout, como es lo que envuelve toda la aplicación, tenemos el HTML, el body.
O sea, esto es lo que está envolviendo toda nuestra aplicación.
Así que los estilos, como queremos, los estilos globales, queremos que sean para toda la aplicación,
aquí vamos a importar los estilos.
Y podríamos hacer punto, punto, barra.
Podríamos ir a app.
Ah, no.
Teníamos que hacer punto, barra, UI y aquí buscar global.css para cargar los estilos globales de nuestra aplicación.
¿Vale?
Si guardamos y volvemos aquí, vemos que ahora nuestra aplicación tiene estilos.
¿Y qué ha pasado? ¿Y cómo? ¿De dónde han salido estos estilos? ¿Y cómo que funciona y todo esto?
A ver, estos estilos es porque aquí ya tenemos unos estilos y además está cargando Tailwind.
Pero sin nosotros cargar los estilos no va a ocurrir nada.
Ahora, en este global.css podríais hacer diferentes cosas.
Por ejemplo, le podríais cambiar al body, le podríais cambiar el color de fondo,
le podríais poner un colorcito que no sea tan blanco, una cosa un poquito más gris.
¿Ves? Ahora está un poquito más gris.
Le podéis poner uno que sea bastante más negro, lo que queráis.
Lo vamos a quitar, pero así es como funcionaría.
Y así es como podríais cargar todos los estilos que queráis.
Así que, estilos globales los haríamos así.
Ahora bien, no solo vamos a querer trabajar con estilos globales.
En este caso estamos trabajando con estilos de...
Mira, voy a quitar estos estilos que había por defecto, que hemos puesto en el layout, ¿vale?
Para que lo viésemos, lo quitamos y así se queda limpio.
Nosotros estamos utilizando Tailwind.
O sea, podemos ver aquí que estamos utilizando clases con Tailwind
y así como se va a estilar toda nuestra aplicación.
Pero hay otra forma también de cargar estilos.
Teníamos los estilos globales con CSS.
Aquí podríamos poner estilos globales tirando directamente de class names y tal.
Tenemos Tailwind y tendríamos una tercera forma, ¿vale?
La tercera forma serían los CSS modules.
Por ejemplo, mira, vamos a crear aquí un archivo CSS que le vamos a llamar home.module.css.
Y esto sin instalar ningún tipo de dependencia.
Vamos a poner aquí el shape, le ponemos una altura de 0, una anchura de 0 y vamos a hacer un triángulo, ¿vale?
Hacemos el triángulo así, así y border bottom 50 pixels solid transparent.
Ah, no, este sería el black, ¿vale?
Esto es un truco bastante chungo, bueno, chungo no, pero interesante de cómo hacer triángulos con solo CSS, ¿no?
Haciendo el border bottom de 50 píxeles, aquí lo que estás consiguiendo al poner izquierda, derecha, que sean transparentes,
es que va a hacer una forma de un triángulo.
Ahora lo vas a ver.
Pero fíjate que hemos creado home.module.css.
El .module es importantísimo porque esto es lo que va a detectar que queremos utilizar CSS modules.
Y ahora podemos ir a nuestra página, por ejemplo, al page y vamos a cargar, vamos a cargar aquí los styles from y vamos a cargar de .ui barra y traemos home.module.css.
Estos estilos ahora los podemos utilizar donde queramos.
Por ejemplo, ya que aquí no hay nada y está vacío, podríamos poner aquí el div, class name.
Y aquí los CSS modules, una cosa interesante que tiene, es que no te tienes que preocupar de que realmente hay algún tipo de colisión,
porque aquí utilizamos styles.shape, ¿vale?
Nos referimos a los estilos que estamos cargando aquí y utilizamos el class name, que en este caso sería shape.
Ahora cerramos aquí el div, guardamos y si volvemos a nuestra página, vemos que tenemos aquí nuestro triángulo, ¿vale?
Bueno, no es el triángulo, el triángulo lo he hecho un poco regulinchis, pero lo podemos arreglar, ¿eh?
Podemos poner 20, 20 y la mitad, o sea, vamos, la mitad de uno para que sea más cuadrado.
Y ahí lo tendríamos.
Y esto, lo interesante es que si miráis el class name, vais a ver que tiene directamente un hash, ¿vale?
Así que ya no os tenéis que preocupar, ¿veis? Aquí un hash.
Esto lo que hace es crear un identificador único para esa clase y así ya no tenéis ningún problema.
Así que ya hemos visto tres formas, global, tailwind y CSS modules.
¿Cuándo utilizar cada uno? Pues depende bastante de ti.
Sí, algunos tienen ventajas, otros desventajas.
Así que depende un poco de ti, el que tú quieras utilizar, cualquiera de esos está bastante bien.
Que sepas que además de esto también puedes utilizar SAS, podéis utilizar SAS, podéis utilizar CSS en JS,
pero de forma nativa, Next.js son CSS global, CSS modules y Tailwind no es nativo,
pero cuando instala Next.js ya te lo pregunta.
En cambio, todos los demás, pues está el JSX, está el components, vas a necesitar instalar las dependencias, ¿vale?
No te lo va a preguntar ni viene ya por defecto, ¿ok?
Muy bien, ya tenemos aquí el page, el layout y ya nuestra página empieza a pintar un poquito mejor.
¿Qué prefieres utilizar CSS puro o modules?
Yo creo que si podéis utilizar modules, yo recomiendo que utilicéis modules porque os va a evitar un montón de problemas, ¿vale?
Para cada componente habría que crear un module.css, para cada componente no, porque en este caso nosotros hemos creado home
y aquí tú puedes exportar los que quieras.
O sea, no que tienes que crear un componente para, o sea, un module.css para cada componente,
porque al final piensa que esto lo puedes importar tantas veces como quieras.
Tú puedes utilizar un module e importarlo en ocho componentes distintos.
A veces puede ser buena idea, pues que sí, un componente tenga sus estilos,
pero no tienes por qué hacerlo así siempre.
¿Qué recomiendas más, modules?
Da igual, el que más os guste está perfecto.
Ya sea CSS modules, style components, el que más os guste, ese es el que os recomiendo, el que más os guste.
¿Qué más nos trae Next.js?
Como os decía, Next.js una cosa que tiene es que trae un montón de optimizaciones que te van a facilitar muchísimo la vida.
¿Y una de ellas cuál es?
Pues una de ellas es la carga de fuentes.
Cargar fuentes normalmente en proyectos y tal es un poco rollo.
Así que, ¿qué puedes hacer con Next.js?
Entonces, Next.js te trae una utilidad que lo que te permite es que, sin preocuparte, puedas cargar la fuente que tú quieras.
¿Qué hacemos?
Pues nos vamos a UI y vamos a crear aquí una carpeta o una fuente, hay una fuente, un archivo, que le llamamos fonts.ts.
Y utilizamos aquí, from, next, barra, font, barra, y aquí fíjate que tienes Google.
¿Qué es lo que hace esto?
Esto es una biblioteca interna que tiene Next.js que te permite importar cualquier fuente de Google Fonts.
Así que puedes darle a control, espacio, y aquí tienes todas y cada una de las fuentes de Google Fonts.
Una de las más famosas sería Inter. Inter es la que suele utilizar Vercel.
Vamos a utilizar otra diferente, Montserrat, por ejemplo.
Y ahora lo que tenemos que hacer es decir, quiero exportar en la constante Montserrat, cargar la fuente Montserrat y le vamos a indicar diferente información.
Le vamos a decir cuáles son los carácteres que queremos utilizar.
Le vamos a decir que simplemente en latín, aunque dependiendo del idioma vamos a querer que tenga más símbolos y carácteres.
Y le podríamos decir también, por ejemplo, los pesos.
Le podríamos decir, oye, quiero que me cargues de 400, 500, 600.
Bueno, en este caso tienen que ser cadenas de texto, pero bueno, no pasa nada.
Le podemos poner 400, ¿vale?
La que queremos cargar, la de 400, o la de 700, o la de 900, la que queráis.
Pero le podéis poner qué grosor es el que queréis poner para optimizar cuáles son las que tiene que cargar.
En este caso le vamos a decir que nos cargue estas y ya está.
Ahora, en Montserrat, ¿cómo hacemos y utilizamos esto?
Pues de nuevo nos vamos a ir al layout, que al final es el componente que envuelve toda nuestra página.
Y aquí le vamos a añadir un classname.
En el classname este vamos a decir, oye, quiero utilizar la fuente esta de Montserrat, punto.
Y aquí, bueno, no sé por qué, Montserrat, punto.
Y aquí podéis aplicar la fuente de dos formas, a través del classname o a través de un estilo en línea.
Vamos a utilizar el classname, porque ya hemos empezado con el classname.
Y vamos a poner aquí anti-alias.
Esto mejora un poquito cómo se renderiza la fuente en algunos navegadores y monitores, ¿vale?
Y esto es lo que aplica en CSS, anti-alias y font-smoothing-grayscale.
Esto a veces se ve un poquito mejor, especialmente en esos monitores que no son muy buenos.
Así que le podéis echar un vistazo, ¿vale?
Y con esto, si volvemos a nuestra página, localhost3000, que no sé por qué, ¿vale?
Podemos ver que ahora la fuente ha cambiado.
Fijaos que ahora tenemos aquí la fuente de Montserrat.
Si le quitamos esto y lo ponemos por aquí, pues aquí lo tendríamos.
Mira, aquí tiene la diferencia.
Con la fuente y sin la fuente.
¿Qué es lo que está haciendo esto además?
Una cosa interesante que está haciendo esto es que no está cargando directamente la fuente desde Google Fonts.
Lo que está haciendo es descargarse la fuente, optimizar la fuente y servirla desde tu servidor.
Porque, amigos, una cosa bastante importante, un error bastante común hoy en día,
es que ya no tiene sentido utilizar el CDN de Google Fonts.
En temas de rendimiento es muchísimo peor.
Además, es mucho más barato el hecho de los CDNs hoy en día nuestros.
O sea, tener un servidor, un archivo estático es muy barato.
Y en este caso va a ser mucho más rápido.
Así que te recomiendo que utilices este sistema si utiliza NextGS en lugar de utilizar cualquier otra cosa.
¿Vale?
Ahora, los nombres de las fuentes, ¿cómo importarlas?
Los nombres están...
Mira, da igual que esté documentado porque, por suerte, tienes aquí esto.
¿Ves?
Tienes ya aquí el autocomplete.
Entonces, pones la que quieras y ya la tienes.
Entonces, no está documentado, pero son todas las que tienes disponibles en Google Fonts.
Y igualmente, con un autocomplete, pues, ¿qué más te da?
Bueno, otra cosa interesante es que también tenéis carga directamente un fallback.
O sea, está muy chulo cómo carga las fuentes.
Fijaos, si nos vamos a Nickware y nos vamos a Font, ¿vale?
Fijaos que está cargando aquí la fuente.
La está cargando ya con el formato más óptimo para este caso.
Si fuese otro navegador, pues, sería con otro diferente.
Y, además, ya te está aplicando el CSS correcto, ¿ves?
Te pone Font Family, Montserrat.
Y también te está poniendo aquí un fallback automáticamente.
Que tampoco te tienes que preocupar en el caso de que tarde mucho de cargar.
Sino que ya está haciendo un fallback sin que tú te tengas que preocupar.
Esto sería uno de los casos para el tema de las fuentes.
También tendríamos otra fuente.
Podríamos tener más de una fuente, ¿eh?
Que esto es otra cosa que muchas veces la gente dice,
Ah, pero ¿cómo puedes tener más de una fuente?
No hay ningún problema.
Puedes tener Montserrat.
Y podemos tener aquí otra fuente, por ejemplo, Lusitana.
Vamos a poner Lusitana.
Fíjate que si la pones aquí directamente,
ya me la detecta que se puede importar.
¿Ok?
Y le podemos decir, vale, pues, quiero que me cargues la de 400 y la de 700.
Y, además, solo los caracteres en latín.
¿Vale?
Para que esté bastante optimizada.
Y esto de Lusitana, podemos ir ahora a nuestra página.
Y en algún sitio en concreto, aquí, en esta P, ¿vale?
Esta P, la de bienvenido al curso.
Esta parte de aquí.
Podemos aplicar aquí la fuente de Lusitana.
Lusitana.classname.
Guardamos, ¿vale?
Y fíjate que ha cambiado.
Toda nuestra página ahora utiliza Montserrat,
pero solo ese elemento en concreto utiliza Lusitana.
¿Ok?
Así que ya tenemos aquí dos fuentes cargadas totalmente diferentes,
totalmente optimizadas y sin ningún problema.
Otra cosa que se puede optimizar y que también te viene un componente ya en Next.js.
Es el tema de las imágenes.
Mira, si vamos por aquí abajo, ves que pone aquí Add Hero Images Here.
¿Vale?
Vamos a añadir una imagen.
Vamos a añadir la imagen porque si vamos aquí al Public,
fíjate que aquí en Public tenemos imágenes.
Hero Desktop, Hero Mobile.
Ok, vamos a cargarlas.
Vamos a poner aquí un image, image source barra girodestop.png, creo que era, ¿no?
Y vamos a poner un alt que es Screenshots of the Dashboard.
¿Vale?
Guardamos esto y fíjate que aparece aquí.
Aparece ahí, no aparece muy bonita, pero aparece ahí la imagen, ¿no?
Vale, aquí tenemos este tema que se ha puesto en amarillo.
¿Por qué es tan amarillo esto?
Porque nos está avisando el linter que antes hemos explicado, nos está diciendo,
oye, utilizar el elemento HTML de imagen puede venir en un problema de rendimiento
que puedes tener un Largest Contentful Paint más malo y además consumir más ancho de banda.
Considera utilizar el componente image.
Pues vamos a verlo, ¿vale?
Para ver la diferencia voy a comentar este.
Voy a copiar, voy a comentar este.
Vamos a dejar este aquí, ¿vale?
Y vamos a ver la diferencia entre una y otra.
Voy a cerrar este editor.
Vamos a dejar este por aquí.
Este lo vamos a poner más o menos por acá.
Vamos a ver la diferencia entre una y otra.
A ver, la diferencia entre una y otra es que vamos a traernos el componente image from...
Ah, mira, ya me lo está diciendo.
Image, nextImage.
Lo utilizamos y lo vamos a utilizar aquí, ¿vale?
En lugar del que teníamos antes.
Entonces, guardamos los cambios y a ver, ya se nos va a quejar, ¿no?
Porque nos dice que requiere que tenga un width, una propiedad width, un ancho.
¿Por qué?
Para asegurarnos que es óptimo cómo está cargando la imagen y le deja el hueco que necesita,
necesitamos especificarle justamente su ancho y su alto, ¿vale?
De esta forma, ese espacio que ocupa la imagen siempre va a estar ahí
y no va a hacer lo que se le llama un layout shift o un salto de renderizado, ¿vale?
Así que vamos a evitar justamente esto utilizando el width y el alto.
El width vamos a poner que es de 1000.
Tenemos que ponerle la relación de aspecto correcta.
En este caso, yo ya me la sé, ¿no?
Que es esta y 760.
Esto dependiendo de cada imagen tendrá una diferente.
Vamos a ponerle class name y vamos a decir, por ahora, que sea hidden por defecto para móvil,
pero a partir de...
Tenemos una media query, ¿vale?
Que vamos a hacer que a partir de 768 píxeles, entonces sí que la muestre.
Breakpoint, joder, no me salía.
Breakpoint, gracias, breakpoint.
A partir de este breakpoint vamos a hacer que aparezca.
Entonces, así lo que vamos a lograr es que en móvil no se vea y en desktop sí.
¿Por qué?
Porque en móvil vamos a cargar otra.
Pero bueno, la imagen parece igual, ¿verdad?
O sea, hemos hecho esto, parece la imagen igual.
Vamos a ver.
Yo cargo, parece todo igual.
Vamos a ver la diferencia.
Vamos a ver cuál es la diferencia entre lo de antes y lo de ahora con este nuevo componente.
Vale.
Si te pones así, bueno, parece que no hay ningún problema.
Vamos a ver.
Vamos a abrir las herramientas de desarrollo, ¿vale?
Vamos al network.
Nos vamos a las imágenes.
Tenemos el giro desktop y ocupa 500K.
Y además el formato es PNG.
Tiene sentido porque aquí ves PNG, ¿vale?
Y bueno, son 500K, que es medio mega.
¿Qué le vamos a hacer?
Bueno, esto es el caso normal.
¿Qué pasa con el caso del componente de image?
Pues lo que vamos a ver es que ahora refrescamos y fíjate lo que ha ocurrido aquí.
Que automáticamente ha optimizado la imagen y no solo le ha bajado un montón el tamaño,
sino que le ha cambiado incluso el formato.
Ha detectado cuál es el formato idóneo para este navegador y ha dicho, vale, pues voy a optimizar la imagen.
Va a ocupar como tres veces menos y además le vamos a poner el formato correcto o idóneo o más óptimo para este navegador que es WebP.
¿Qué no soporta el navegador WebP?
Pues entonces le pondría el PNG a lo mejor.
Lo que va a intentar es decir, bueno, cuando pueda, pues voy a utilizar uno u otro.
Bueno, ahora, otra cosa muy interesante de utilizar este componente imagen es que además, fijaos que aquí teníamos cargando el de desktop todo el rato.
Una cosa interesante del image es que por defecto es lazy load.
¿Esto qué quiere decir?
Que por defecto, si la imagen no aparece, no la carga.
Así que lo que hacemos aquí es decir, vale, pues ahora vamos a cargar también la de mobile.
Y la de mobile, obviamente, la vamos a poner en block, pero cuando sea MD, vamos a poner que sea hidden.
O sea, porque vamos a mostrar una u otra, dependiendo de si es mobile o no es mobile, lo que vamos a hacer es cargar una u otra.
Le cambiamos también su tamaño, porque su tamaño es distinto.
¿Ok?
¿Y qué hace esto?
Pues fijaos en una cosa.
Cargamos aquí, lo hacemos pequeño y ahora aparece la otra imagen.
¿Vale?
Tenemos dos imágenes distintas.
Una cosa que muchas veces aquí hay gente que dice, ostras, esto está mal porque entonces carga las dos imágenes y no sé qué.
No es así.
Por defecto, como tiene el lazy load, esto está muy chulo porque de una forma muy sencilla, declarativa y sin tener que preocuparte, simplemente utilizando las media queries, fíjate lo que ocurre aquí.
Si yo abro las herramientas de desarrollo, vas a ver aquí en la network, en imágenes, ¿vale?
Solo está cargando la de desktop.
Cuando haces que la ventana sea pequeña y tenga que cargar la de móvil, ¿vale?
Vamos a ver que entonces, en este punto, sí que ha cargado la de móvil.
O al revés, si empezamos en móvil, solo carga la de móvil y conforme vas haciendo más grande y entonces tienes que cargar la otra, entonces sí que carga la otra imagen.
¿Vale?
O sea, que no te tienes que preocupar en este caso de decir, no, es que entonces se está cargando las dos.
No, ya está optimizado sin ningún tipo de problema, ¿vale?
Así que ahí tendríamos las optimizaciones de imágenes y de fuentes que nos ofrece Nexies.
Un tema importante de esto, tema importante de esto, es que la optimización de imágenes tiene un coste.
O sea, tienes unas cuantas gratuitas, pero no es ilimitado.
Entonces, ten cuidado y aquí pon solo imágenes que sean fijas.
Por ejemplo, un avatar de un usuario no tendría tanto sentido porque si tienes un millón de usuarios, serían un millón de transformaciones y en ese caso ahí tendrías bastantes problemas.
Esto lo hace Service Site y consume recursos.
Obviamente, a ver, consume recursos, pero ojo, esto se hace una vez, ¿vale?
Esto no se hace en cada request, que la gente...
Esto se hace solo una vez.
Cuando entra el usuario, el primer usuario, se hace la optimización de la imagen y esta imagen se guarda ya optimizada, ¿no?
Para cuando no la tenga que volver a hacer.
Solo en aquellos momentos en el que tenga que generar una nueva, la tendrá que hacer.
Pero no lo hace para todos los usuarios, solo para que lo sepáis, ¿eh?
¿Qué te refieres que no es ilimitado?
Me refiero a que esto, si lo ponéis, por ejemplo, en Vercel, esto tiene un precio, ¿vale?
Por ejemplo, vamos a Images, ¿ves?
Image Optimization.
De forma totalmente gratuita, podéis optimizar hasta mil imágenes.
Esto en Vercel, pero bueno, esto lo podéis hacer en un desplegar en cualquier sitio y tendrá un coste de ese sitio.
Esto en este caso es porque Vercel lo hace automáticamente.
Y lo que se hace es, muchas veces, se guarda en caché, en memoria y ya lo tendíais, ¿vale?
Y vamos ahora con el tema del layout y las páginas, porque es la clave.
El sistema de enrutados por archivos.
Esto es una de las cosas claves de Next.js, del framework de Next.js.
Mira, aquí tenemos un ejemplo, por ejemplo, de cómo serían las rutas.
Imagínate que tenemos aquí nuestra página, pues, midu.dev o acme.com, barra.
La primera barra, como hemos visto, sería el primer page.jsx.
Y a partir de cada barra que hacemos y que queremos que sea un segmento, tendríamos que crear una nueva carpeta.
Y cada carpeta tendría que tener un nuevo page.jsx.
Ahora lo vamos a ver, no te preocupes, y lo vas a ver mucho más claro, ¿vale?
Aquí tendríamos este ejemplo.
Si quieres crear el barra login, por ejemplo, tendríamos que crear la carpeta login y dentro tener un archivo page.tsx o jsx.
Ahora lo que vamos a hacer es crear, por ejemplo, una carpeta dashboard, o sea, una ruta dashboard.
Vamos a querer que vayamos aquí a nuestra página, hagamos barra dashboard y ahora, ¿ves?
Da un 404.
Pues esto lo vamos a arreglar.
¿Qué vamos a hacer?
Pues nada, nos vamos aquí, vamos aquí a nuestra app, vamos a crear la carpeta dashboard.
Y creamos dentro un page.tsx.
Y hacemos export, default, function, page.
Y aquí devolvemos, return, dashboard, dashboard page, ¿vale?
Y solo con esto, simplemente con esto, acabamos de crear una nueva ruta.
Y esto es lo que se le llama file system routing, un enrutado basado en el sistema de archivos.
Aquí dentro de app hemos creado una carpeta y en la carpeta hemos creado un page,
por lo tanto hemos habilitado que nuestra página web tenga un barra dashboard.
Si ahora volvemos a nuestra página, pues fíjate que ya nos ha cargado el dashboard page.
En este caso, como el layout no está renderizando nada, pues está vacío.
Pero de nuevo, ¿te acuerdas que hemos dicho que el layout envuelve toda nuestra aplicación?
Claro, si aquí pongo esto es parte del layout y lo guardo, fíjate que si vuelvo, ¿veis?
Está, esto es parte del layout.
Si vuelvo a la raíz, esto es parte del layout.
Porque ese layout está envolviendo toda mi aplicación independientemente de qué ruta esté.
Y eso puede ser muy interesante, por ejemplo, para un sidebar, para el header, para el footer.
Tener un footer abajo, ¿no?
Por ejemplo, mira, vamos a hacer el footer para lo que tengamos claro.
Hecho con amor por la gente de Bersel.
Hecho con amor por la gente de Bersel.
Ahora, todas las páginas vamos a ver ahí abajo.
Bueno, se ve muy poquito.
Vamos a ponerle un poquito de estilos, simplemente para que se vea mejor.
Flex, Justify, Center, Item, Center.
Y ahora, pues lo tenemos aquí.
Hecho con amor por la gente de Bersel, ¿vale?
Ahora, ese footer, independientemente de la página a la que vayamos, ¿ves?
Va a estar siempre ahí disponible.
Pues por ahora vamos a dejar esa parte que sí que tiene sentido.
Así que ya hemos creado una nueva ruta utilizando el page.
Perfecto.
Ahora bien, ¿cómo podríamos seguir creando?
Porque vamos a querer tener más rutas anidadas.
Bueno, puedes crear una ruta dentro de otra ruta.
Por ejemplo, imagínate que ahora vamos a querer tener dashboard barra customers.
Vale, 404.
¿Qué tenemos que hacer?
Pues dentro de dashboard, creamos.
Y mira, te voy a enseñar una forma muy chula, por si no lo conocías.
Te voy a enseñar, trucazo, trucazo.
Te voy a enseñar cómo puedes crear un archivo y una carpeta a la vez.
Si le das aquí a nuevo archivo, vamos a crear primero la carpeta, que sería customers barra page.tsx.
Page, que es lo que necesitamos justamente para crear una nueva ruta.
Ahora esté en el page, me voy a copiar el componente que teníamos antes y le vamos a cambiar aquí para que sea customers.
Importante, las rutas, fíjate que lo que tiene que devolver es una función por defecto, el export default.
No tienes que hacer export function, tiene que ser export default.
Y el nombre no importa, porque lo va a ignorar.
Es importante que le pongas un nombre descriptivo, porque así, si hay algún error, si te sale en consola o lo que sea, te puede ayudar.
Y en el caso de que algún componente que ocupemos en el layout quisiera que reciba props,
por ejemplo, que en una page el footer tenga un background rojo y en otra page azul, ¿cómo lo harías?
En el caso del layout, tendrías que mirar la ruta en la que estás y cambiar el footer a lo que sea.
Lo malo es que no me acuerdo qué campos son los que le llegan al root layout,
pero creo que le llega alguna cosa que puedas ver la URL y a partir de la URL cambiar.
Pero más allá de eso, no le puedes pasar lo que sea, ¿sabes? Lo que quieras.
Sino que simplemente creo que aquí le llega algún tipo de información que te permite hacer eso, creo.
No me acuerdo si es con el root params o alguna cosa de estas, pero poder se puede llegar a hacer porque...
Aunque no sé si se puede. Esto es que estoy pensando.
Es que a lo mejor, ¿sabes qué pasa? Que entonces no querrías esto aquí, sino que lo querrías en el layout de cada página.
Que esto al final lo puedes tener, cada página también puede tener su layout, que eso también lo vamos a ver ahora.
Y ahora verás cómo lo podríamos hacer.
Entonces, ya hemos creído aquí el de customers.
Vamos a crear uno más porque aparte de customers vamos a tener una tercera página que sea la de invoices.
Y entonces repetiríamos otra vez lo mismo.
Invoices barra page.tsx.
Y fíjate, con eso creamos a la vez tanto carpeta como fichero.
Así que ahora aquí vamos a poner aquí invoices page, invoices page.
¿Vale?
Lo importante, pues mira, ya tenemos la página customers y la página invoices.
Y fíjate en la ruta.
La ruta es barra dashboard, barra invoices, porque es lo que está replicando a las rutas, al enrutado que tenemos dentro de app.
Tenemos aquí invoices, o sea, dashboard.
Dentro de dashboard está invoices y tenemos el page.tsx.
¿Vale?
Así que ya tendríamos aquí todas las rutas.
Mira, aquí tienen un dibujito que está muy chulo, que te lo explica bastante bien.
Aquí en la app tienes el page.tsx, esto sería la barra.
Dentro de dashboard tienes el page.tsx, sería barra dashboard.
Dentro de dashboard tienes el customers, entonces es dashboard barra customers, gracias al page.tsx.
O sea que ya vas viendo un poco cómo sería el tema de hacer rutas anidadas.
¿Vale?
Ahora vamos a crear un poquito el layout para que lo veamos.
Porque el tema es que hasta ahora hemos visto este archivo, ¿no?
Este archivo te he dicho que es el layout, pero es el layout de toda nuestra página.
Lo interesante de los layouts es que no solo podemos hacer un layout que envuelva toda nuestra aplicación,
es que podemos tener layouts que envuelvan solo partes de nuestras rutas, o sea, una parte de las rutas.
Imagínate que queremos tener un componente que envuelva solo aquellas páginas que estén dentro de dashboard.
Es súper típico, porque a lo mejor tienes un barra dashboard o un barra search y dentro del barra search ahí tienes un sidebar que no quieres que...
O sea, quieres que siempre sea el mismo independientemente de qué subruta entres.
Pues igual que hemos puesto aquí un page, podemos poner aquí un barra layout.tsx.
Y esto, ahora podemos crear export default function layout.
Esto siempre recibe el children, que es lo que va a estar envolviendo.
Y podemos poner aquí, por ahora vamos a poner, por ejemplo, section, children.
Esto es el layout del dashboard.
Vamos a tipar esto para que no se nos queje.
Muy bien, con React Note.
Perfecto.
Y ya está.
Hostia, esto lo he dejado aquí.
Vale.
Muy bien.
Pues ya lo tendríamos así.
Entonces, este layout, vamos a ver que solo se aplica.
¿Ves?
Esto es el layout del dashboard.
Si voy a customers, eso es el layout del dashboard.
Si voy a dashboard, también.
Esto es el layout del dashboard.
Pero si voy a la raíz, vamos a ver que no tenemos el layout del dashboard.
Porque eso no está envolviendo a nuestras rutas.
Este layout que hemos puesto en el nivel de dashboard solo va a aplicar hacia abajo.
A esa misma ruta y hacia abajo.
¿Vale?
¿Y para qué son importantes los layouts?
Ahora lo vas a ver clarísimo.
Porque lo que vamos a querer hacer en este layout, en el dashboard, vamos a crear, vamos a pegarle esto.
¿Vale?
Estos estilos de aquí y este sign up.
Y vamos a agregar la importación.
Muy bien.
Y tenemos estos estilos.
Un div que lo que va a poner es poner una barra por ahí.
Y en la barra del otro lado va a poner el children, que sería el contenido.
O sea, que ahora el layout va a cambiar totalmente.
Vamos a ver cómo queda.
Si vamos al barra de dashboard, ¿vale?
Lo que ha ocurrido es que esta barra de aquí sería esta parte de aquí, donde tenemos el siteNap, un componente que ya tiene una navegación.
Y aquí a la derecha está el contenido de cada una de las páginas.
O sea, en el dashboard, dashboard page, este que hemos puesto aquí, esta página, es el contenido del dashboard.
Si guardamos, lo vemos aquí.
O sea, que ya tenemos el layout que solo a las páginas que sean el dashboard, invoices y customers, le va a afectar.
Y podemos reutilizar que todo tenga esto.
Ahora, ¿por qué esto sería interesante?
Esto es interesante y es muy importante que lo tengas en cuenta porque vas a querer poner en el layout aquellas partes que no quieres que cambien mientras navegas.
Por ejemplo, tú cuando vayas de home a invoices, no quieres que se refresque el layout del sidebar.
¿Para qué ibas a querer que se refrescase?
No tenía ningún tipo de sentido que el layout se vuelva a renderizar, ¿verdad?
¿Para qué quieres que se renderice otra vez si es el mismo sidebar para todas las páginas?
Por eso lo estamos moviendo al nivel del layout.
Para que de esa forma, cuando podamos hacer bien la navegación, solo cambiemos este contenido de aquí porque todo lo demás se queda fijo.
Por eso lo dejamos justamente en el layout, ¿vale?
Esto serían layouts y páginas y ahora vamos a ver el tema de las navegaciones.
Pero el footer, el root layout se sigue viendo allí.
Efectivamente, porque el footer, el root layout, al final lo hemos puesto en el root, en la raíz.
¿Y qué hemos dicho de los layouts?
Que afectan de ese nivel hacia abajo.
Entonces es normal.
Si lo hemos puesto a la raíz de que están volviendo toda nuestra aplicación, va a afectar a todas las rutas que tenemos dentro de nuestra aplicación.
Si ponemos un layout en una ruta que está a partir de dashboard, pues va a ser de dashboard hacia abajo.
O sea que tiene sentido, ¿no?
¿Mido, en caso de no quieras usar una página en layout raíz, se puede omitir?
No sé si se puede omitir, pero normalmente va a ser mala idea que lo emitas porque siempre vas a querer tener algún tipo de cosa en el layout básico.
Así que igualmente, por ejemplo, el body, el HTML y todo esto, que no sé si por defecto lo hará así, pero siempre vas a querer a lo mejor tener algún tema de metadatos o lo que sea.
Tened en cuenta que en el layout este, en el root layout, este sería el layout del dashboard y el root layout, que sería este.
Aquí también podéis poner, por ejemplo, yo que sé, lo que sea, ¿vale?
Podrías poner esto en el tema de Next.js, luego lo veremos, que hay otra forma, pero podéis poner cualquier cosa dentro del HTML.
O sea, podéis poner, por ejemplo, footers, incluso temas de scripts, que también hay otra forma.
Y para el inicio de sesión, que generalmente cambia el header y aparecen nuevas opciones, es que entonces, en ese caso, lo que podéis hacer es poner el layout en otro punto, no ponerlo aquí.
Pero igualmente también lo podríais cambiar sin ningún tipo de problema.
¿De dónde sacaste el sitenap? Como hemos hecho al principio, lo que estamos utilizando aquí es una plantilla.
Y la plantilla ya viene con un montón de componentes que ya están hechos.
Entonces, para que nosotros no tengamos que hacer y nos podamos enfocar en lo realmente importante.
Ahora, vamos con lo importante también, que es el tema de la navegación.
Ya tenemos aquí el sidebar, parece que tiene buena pinta, pero tenemos un problema, amigos.
Y esto es muy básico. Y es que, fíjate que voy a la home y recarga toda la página.
Si ponemos aquí, pues recarga toda la página.
Si, mira, voy a quitar todos los recursos. Si voy a invoices, está recargando todo esto.
Si voy a customers, ¿vale? Customers, está cargando todo esto.
¿Qué es lo que está pasando? Lo que está pasando es que estamos recargando toda la página conforme vamos navegando.
Cada vez que navegas, se recarga toda la página. Y esto tiene diferentes cosas negativas.
La primera, obviamente, es un impacto negativo en el rendimiento que percibe el usuario.
Y además que es innecesario, porque ese JavaScript, casi todo, ya lo hemos cargado.
¿Para qué lo vamos a tener que recargar? Aunque venga de caché, es innecesario.
Además, una tercera cosa, perdemos el estado.
En el caso que tuviésemos un estado de alguna cosa que estuviese a medias o lo que sea,
al recargar toda la página, lo machacaríamos, a no ser que lo saquemos otra vez de local storage.
El tema es que vamos a querer intentar reaprovechar al máximo posible.
¿Qué vamos a hacer con esto?
Vamos a hacer, si puedo quitar el disable caché, entonces vais a ver que todavía va más lento.
Si quito el disable caché.
Para saber cuándo está recargando una página entera, una forma que podéis hacer es mirar que el favicon cambia.
Fijaos este favicon que cuando le doy un clic, ¿vale?
Veis que hace como un parpadeo. Eso es que se está recargando toda la página.
Entonces, cada vez se está recargando y descargar todos los recursos.
¿Cómo podemos hacer que haya una navegación fluida entre páginas como si fuese una single page application?
O sea, que reutilice todos los recursos posibles, que re-renderice solo aquello que cambia
y que lo que hacemos es actualizar la URL sin necesidad de recargar toda la página.
Bueno, para hacer navegaciones por parte del cliente,
tenemos la posibilidad de utilizar un componente que viene en Next.js que se llama link.
Así que vamos a ir al componente nav links, que es donde tenemos los enlaces de la home, invoices y customers.
Estos enlaces que vemos aquí.
Y vamos a buscar aquí que tenemos el anchor, que es el elemento HTML normal y corriente.
Pero como queremos que las navegaciones se sientan mucho más rápidas y que no haga una recarga completa,
lo que vamos a hacer es utilizar este componente link.
Fíjate que por lo demás funciona todo igual.
Tiene un href, puedes ponerle un class name, puedes envolver el título con su icono, exactamente igual.
Lo único que hemos hecho es cambiar esto.
Vamos a guardar los cambios y vamos a ver aquí qué es lo que pasa con esto.
Estamos en home.
Fíjate, ojo, ¿qué ha pasado?
Ahora voy a invoices.
Fíjate que cambia el contenido, cambia la URL, cambia el título y solo carga lo que necesita.
O sea, no está cargando absolutamente nada.
Obviamente ahora se nota mucho, pero mucho más rápida.
Lo único que está haciendo es cargar lo mínimo necesario, indispensable.
Esta es la clave por la que muchas veces, si habéis probado una aplicación de Next.js,
realmente marca la diferencia de decir, ostras, qué bien va, cómo funciona tan rápido, ¿no?
Lo que está pasando es esto, ¿no?
Lo que está ocurriendo aquí es que lo que queremos es, vale, mira, voy a entrar directamente a...
Mira, voy a recargar, voy a recargar, vas a ver que se carga todo.
Y ahora que estoy aquí en Customers, me voy a ir a Invoices.
¿Qué es lo que pasa?
Que lo que vamos a poner aquí es decir, bueno, como ya he cargado todos los recursos,
React, Next.js, las bibliotecas y tal,
solo voy a cargar aquello que necesito para realmente mostrar la única parte que cambia.
Y la única parte que cambia es esta parte de aquí.
Entonces, si voy a Invoices, solo carga esta parte de Invoices Page.
De hecho, podríamos ver aquí, si vamos entrando estas dos partes de aquí,
podemos ver justamente que es lo que ha contestado.
Podríamos ver aquí Development, no sé qué, no sé cuánto.
Y podemos ver que las únicas partes que cambian son realmente las que ha descargado.
Todo lo demás lo ha dejado quieto parado, no ha hecho ningún tipo de problema.
Y aquí está la clave del layout, porque el layout tampoco ha tenido que re-renderizarlo.
Realmente lo que ha hecho es simplemente dejarlo ahí fijo y solo cambiar esta parte de aquí.
Esto también lo podéis ver con los componentes estos así de React.
Podemos buscar esto de aquí.
Si conocéis, estas son las Developer Tools.
Y vamos a ver si soy capaz de encontrar el básico...
Otter layout, vale.
Creo que está por aquí.
Creo que por aquí, por aquí, por aquí.
Si le damos aquí Invoices, Home, vas a ver que lo único que cambia está aquí.
Lo único que cambia todo lo demás se queda exactamente igual.
Lo único que cambia es esto y lo que renderiza a partir de ese punto.
Todo lo demás lo está dejando exactamente igual.
Vale, también lo podríamos...
Ah, no, esto no lo tenemos...
Ah, ¿sí?
Espérate.
A ver si lo podemos ver.
No, creo que...
Ah, sí.
Bueno, con esto podríais ver cuáles son los únicos componentes que cambian mientras estáis navegando.
Es una herramienta muy interesante, pero ya sé, eso se sale un poco del scope.
Bueno, ya tendríamos la navegación.
Ahora bien, hay un problema que no sé de tú, pero a mí me molesta un poco.
Y es el hecho de que si estás en Home, no aparece que estás en Home.
No sabes que estás en la Home, si estás en Invoices, aunque cambian las rutas,
aquí no le estamos indicando al usuario si estamos en un sitio u otro.
Vamos a mejorar un poco esta experiencia y lo que vamos a hacer es,
independiendo de la ruta en la que estamos, vamos a cambiarle los estilos
para que se vea cuál es el que está activo.
Para conseguir eso, Next.js tiene un montón de hooks que te permite,
de un montón de formas, acceder a información de las rutas, de los paths, del router,
para que tú lo actualices, para que lo cambies...
Tienes un montón.
En este caso, el que necesitamos sería Use Path Name para leer el path name
en el que estamos en ese momento.
El Use Path Name lo tenemos que importar de Next barra Navigation.
Y aquí ahora lo que tenemos es la posibilidad de leer el path name.
¿El path name qué es?
El path name sería barra Dashboard barra Customers.
Eso es lo que se le llama path name.
Ahora que tendríamos el path name, pues lo único que tenemos que hacer es decir,
bueno, pues en el caso de que aquí, este enlace, vamos a cambiar el class name,
vamos a poner un template string, ¿vale?
Porque vamos a hacer ahí una evaluación.
Cambiamos esto por aquí.
Y vamos a ponerle aquí un estilo.
Vamos a decirle que si el path name es igual al enlace del link,
vamos a hacer que cambie y que tenga otros estilos.
Que el fondo cambie a otro color y que el texto cambie a otro color.
Y ya está.
Si el path name que tenemos en ese componente en ese momento es igual al enlace del link,
vamos a cambiarle los estilos.
Y si no, lo dejamos como estaba.
Si guardamos los cambios, vamos a tener un error.
Y esto va a ser algo que nos va a molestar.
Bueno, tenemos un error.
Y nos dice, ojo, Use Path Name solo funciona en Client Components.
Add the Use Client Directive at the top of the file.
O sea, añade la directiva Use Client encima del archivo, arriba del todo,
para poder utilizarlo.
Lo que está pasando en este caso es que por defecto,
todos los componentes que estamos utilizando hasta ahora,
funcionan en el servidor.
Lo que está haciendo es que se renderizan en el servidor
y devuelve el output al cliente.
O sea, estos componentes que nosotros estamos viendo,
realmente no se están ejecutando en el cliente.
Y es que tienes que entender, y esto es una cosa más de React,
no es de Next.js, pero con Next.js cobra más importancia,
que los componentes de React se pueden ejecutar en dos sitios,
en el servidor y en el cliente.
Tú cuando renderizas un componente de React en el servidor,
puedes recuperar el HTML y ese HTML devolverlo desde el servidor
para mostrárselo al cliente.
Pero ¿qué pasa?
Que en el cliente también se tienen que renderizar para que cobren vida.
Cuando haces un clic, cuando tienes un evento,
cuando tienes un efecto, este tipo de cosas,
solo tienen sentido que funcionen en el cliente.
Por lo tanto, tienes que entender que tenemos como dos entornos
en los que nuestros componentes se pueden renderizar,
servidor y cliente.
¿Y por qué nos está diciendo este componente que necesita un useClient?
¿Qué sentido tendría esto?
Bueno, el tema es que el pathname es un concepto que solo existe en el cliente.
En el servidor no tiene sentido que hablemos de pathname porque no tenemos un pathname.
Todavía no hemos llegado a ese punto.
No sabemos antes de que llegue y se renderice y vaya al usuario
cuál es el pathname al que estamos accediendo.
Entonces, el pathname es algo que estamos y solo podemos recuperar en el cliente.
Por lo tanto, para poder utilizarlo en este caso,
como los componentes por defecto solo se renderizan en el servidor
y necesitamos que este componente ahora,
como queremos acceder a una cosa que solo está en el cliente,
tenemos que utilizar la directiva que nos está diciendo el error.
Tenemos que decirle, no,
este componente queremos que también funcione en el cliente.
Así que ponemos el useClient,
hace que este componente también se renderice en el cliente
y ahora sí parece que funciona correctamente.
Fíjate que además ya me estamos mezclando aquí el customers,
si vamos a invoices y si vamos a home.
Ya está cambiando cada uno y además me lo está dejando fijado.
Estamos leyendo la URL y gracias a la URL le estamos cambiando los estilos.
Así que con esto ya podríamos tener la posibilidad de saber
qué enlace es el que tenemos activado.
Cosas muy interesantes del link, del enlace y de esto que hemos hecho aquí
con este link, que a lo mejor no quedan muy claras
y que a veces son bastante chulas, ¿vale?
Si vamos aquí a Nickwork, una cosa que tiene muy chula,
muchas veces, claro, es que ahora a lo mejor así no lo vemos,
pero a ver, así, vale, y ahora hago scroll,
no, si hago scroll y bajo, vale, vale,
ahora no lo vamos a ver porque lo está cargando igualmente.
Pero una cosa que tiene muy chula el componente link es que lo que hace
es hacer un code splitting automático.
¿Qué quiere decir esto?
Esto quiere decir que cuando tú entras a la página dashboard,
no está cargando la página invoices porque todavía no la necesita.
O sea, ya está optimizando como lo que le estamos enviando al usuario.
Solo cuando vamos a invoices vas a ver que entonces sí está cargando
lo que realmente necesita, ¿no?
Y esto pasaría también si estamos aquí en dashboard, o sea, aquí en la home
y vamos a dashboard desde un componente link, no entrando directamente,
solo cargaría lo que necesita de diferencia.
Pero, ¿qué hay también de interesante?
Pues una cosa que es muy interesante es que también Next.js lo que hace es detectar
dónde están estos componentes link.
Y cuando se ven y están visibles en el viewport, automáticamente Next.js precarga esa página
porque dice, ostras, si este enlace está visible para el usuario,
voy a precargar ese destino para que automáticamente lo cargue mucho más rápido
cuando le dé clic.
Y así la transición sea casi instantánea.
Entonces, muchas veces podrás ver que quizás dices, oye, ¿por qué la network,
si no le he dado clic, empieza a cargar algún componente?
Pues es por eso, porque el enlace está ahí disponible y lo que está haciendo
es hacer una precarga de ese recurso, ¿vale?
¿Qué es el code splitting?
Que alguien me estaba preguntando otra vez.
Code splitting básicamente es, imagínate que tú entras a esta página de Next.js.
Si tú entrases a esta página de Next.js y no hicieses code splitting,
nada más entrar a la página, tendrías que cargar todos los componentes de la página.
Todos, todos los componentes que hay en la página os tendrías que cargar
porque os tendrías que tener ya de primeras, aunque no los vayas a utilizar.
Con el code splitting, ¿qué es lo que haces?
Básicamente lo que haces es dividir el código y lo que haces es simplemente
que en lugar de tener un paquete enorme, lo que haces es separarlo como en chunks,
en trozos, que los vas sirviendo conforme el usuario lo necesita.
Eso es hacer code splitting.
Y lo que se puede hacer justamente es llevarlo al extremo.
Eso lo puedes hacer a nivel de una modal.
Imagínate que tienes en una modal una biblioteca muy grande que no se quede,
no sé cuánto.
Podrías hacer que esa modal solo se cargue cuando haces clic,
no nada más entrar a la página.
Esto es un error muy común que se comete en el rendimiento de muchas páginas
de que se carga todo aunque no se utilice.
Y para ver este tipo de problemas, lo que puedes hacer, por ejemplo,
si vamos a la página del periódico.com, por poner un ejemplo, ¿ok?
Fíjate, lo que puedes hacer aquí es te vas a una herramienta para saber si necesitas
code splitting, que sea code coverage o show coverage, ¿vale?
El coverage lo que te va a decir es qué cantidad de JavaScript estás utilizando
en este sitio y de CSS, lo cual está bastante bien.
¿Ves?
Aquí tendrías los bytes no utilizados.
No utilizados.
Entonces, aquí puedes ver que, por ejemplo, este archivo de aquí,
este archivo JS, no sé qué, no sé cuánto, este de aquí,
solo se utiliza un 33%.
No se utiliza un 66% de los archivos.
Si le das un clic, le das dos veces, esto es lo que debería hacer.
Ah, no, ahora.
Lo que hace es meterte aquí y podemos ver que hay un montón de código.
Si seguimos bajando, vale, debería aparecer en azul.
¿Ves?
En azul aparece lo que sí que se utiliza y en rojo debería aparecer lo que no se utiliza.
No sé dónde estará, igual es una línea por ahí tirada.
Pero el tema es que puedes detectar qué es lo que no estás utilizando.
Y no tiene sentido cargar todo pese a que no lo vas a utilizar.
Porque lo que estás haciendo es que la primera carga del usuario sea mucho,
mucho, mucho más lenta.
Y esto automáticamente te lo está haciendo NextGS,
sin tener que preocuparte y hacerlo tú manualmente.
Lo está haciendo automáticamente por ti.
Vamos con el tema de la base de datos, ¿ok?
Porque, Midu, hay algo que no me queda claro con Next.
Siendo que hace peticiones directamente desde el componente,
¿cómo funciona el hecho de no volver a fechar la data
siendo que no tienes un array de dependencias como el useEffect?
Si necesitas manipular la data fachead, ¿no necesitas tener la data en un estado?
No necesitas tener la data en un estado sin ningún tipo de problema, ¿eh?
O sea, ¿por qué?
Si directamente lo que puedes hacer, y ahora lo vas a ver, lo vas a ver ahora,
es que el componente puede hacer una wait.
O sea, el componente puede ser asíncrono, lo cual es súper brutal.
Y entonces, a ser asíncrono puede esperar justamente tener los datos.
Vale, vamos a hacer una cosa.
Tengo aquí, vamos a conectarle una base de datos.
Yo ya tengo una base de datos y voy a utilizar esa para no tener que estar
creándome un proyecto y todo esto.
Aquí en Storage, o mira, lo voy a crear desde cero.
Porque yo tengo una base de datos, la iba a utilizar, pero voy a crearla desde cero
para enseñaros.
Entonces, tengo que eliminar esta, porque si no, no me deja.
¿Vale?
Delete Store.
I Connected Projects.
O sea, tengo que eliminar el proyecto.
¿Vale?
Projects.
Tengo que eliminar o tengo que desconectar.
Remove Project Connection.
Si no, no me deja eliminarlo.
¿Vale?
Settings.
Delete Database.
Me dice que le ponga.
Vale.
Elimino esto.
Delete.
Qué fuerte esto, ¿eh?
De tener que poner exactamente esa frase, porque si no, no sé qué.
Yo voy a utilizar esto, pero esto lo podéis hacer con cualquier base de datos,
con cualquier conexión.
Lo podéis hacer con fetching.
Lo podéis hacer un montón de formas.
Pero me parece interesante que vemos lo de SQL.
Uno, porque ha habido muchos memes.
Y segundo, porque así entendéis cómo podéis conectar una base de datos
y qué ventajas tenemos con esto.
Vamos a utilizar Vercel Storage, que al final, pues por fortuna,
tiene un plan gratuito, que no está mal, no es el mejor del mundo,
pero lo tiene, ¿vale?
Al crear, cuando vais a Vercel, fijaos que tenéis aquí diferentes pestañas
y tenéis una que se llama Storage.
Y aquí tenéis la posibilidad de crear diferentes bases de datos.
Un Edge Config, un Key Value, un Postgres y Blob, que esto sería para subir archivos.
Nosotros, en este caso, vamos a utilizar el tema de Postgres, ¿vale?
Una base de datos basada en SQL, como es MySQL,
aunque es un poquito diferente.
Nos dice términos y condiciones, le decimos que sí,
le vamos a decir que esto va a ser Customer Invoices.
Es que no sé exactamente qué es lo que tiene.
Y la región, aquí lo importante es poner una región que esté cerca
de vuestro proyecto, ¿vale?
Yo, en este caso, voy a poner Frankfurt, porque yo estoy en España
y me queda cerca, pero a lo mejor vosotros queréis poner, no sé si...
La verdad es que no tiene muchas regiones, ¿vale?
Tiene que trabajar en esto, porque si no...
¿Vale? Le vamos a poner Frankfurt y le vamos a dar Create.
Esto nos va a crear una nueva base de datos.
Aquí tenéis los límites.
256 megas, 60 horas de computación, 256 megas de transferencia
y 256 megas que podéis escribir.
Estos son los gratis, porque veis, esto en el plan Hobby.
Si pagáis, pues esto será mucho más.
Pero bueno, para proyectos sencillos no vais a tener ningún tipo de problema
y lo vais a hacer súper fácil.
Aquí tenéis como diferentes formas de conectaros.
Aquí fijaos que tenéis PSQL, Vercel, Vercel Postgres,
Comprisma, PG o Enf.local.
Por defecto y por fortuna, salen todas las variables de entorno,
salen totalmente con asteriscos, si no os tenéis que preocupar.
Le podéis dar a Copy Snippet y ya os lo copia.
Y si le dais a Show Secret, os van a aparecer ahí
todas las opciones y todo esto.
Lo que voy a hacer es aquí en el archivo
Enf.local, que tenemos aquí,
Enf.example, le voy a quitar el example
y lo que voy a hacer aquí es pegar
todas las variables de entorno que tenemos aquí
para que haga la conexión.
Entonces lo voy a hacer fuera de cámara,
que nos conocemos.
Nos conocemos y luego vienen los troleos.
Pongo esto por aquí.
¿Lo estáis viendo en el brillo de mis ojos?
Muy bien, vale, vale, ya está.
Pues ya lo he hecho.
Ya he copiado este archivo en el .env, ¿ok?
Solo con eso, solo copiando esto,
ya lo bueno que tenemos aquí es
que ya nos podemos conectar a la base de datos
y no vamos a necesitar hacer ningún tipo de cosas.
Otra cosa que podéis hacer, si queréis,
podríais conectar el proyecto,
si lo habéis subido a Github,
y hacer un Vercel Link.
Luego hacéis un Vercel Enf Pool
y le decís a qué archivo lo queréis guardar.
Y entonces automáticamente os crea el archivo Enf,
lo cual es bastante brutal, ¿vale?
Ahora, podéis utilizar diferentes clientes de PostgreSQL,
pero lo más ideal es que utilicéis justamente el de Vercel.
¿Por qué?
Porque fijaos la magia.
Como ya sabe Vercel cómo son las variables de entorno,
ni siquiera vais a tener que crear la conexión,
sino que automáticamente vamos a crear,
vamos a instalar la dependencia, ¿vale?
Vamos aquí, npm install,
instalamos la dependencia para trabajar
con nuestra base de datos de Postgre, ¿vale?
Y directamente, ya va a saber directamente
cómo conectarse a la base de datos, ¿ok?
Ahora ya podríamos hacer aquí
todo lo que quisiéramos con nuestra base de datos
sin ningún tipo de problema.
Ahora, para conectarnos a nuestra base de datos
que tenga algún tipo de dato,
porque si vamos aquí, nos vamos a Data,
fíjate que nuestra base de datos ahora mismo está vacía.
Vamos a hacer una cosa.
Al principio del curso, te he comentado
que tenemos un archivo por aquí en scripts
que se llama sit,
que esto es como un archivo
que lo que hace es la semilla
que va a crear un montón de datos
para tu base de datos,
para que así no esté vacía
y puedas empezar con algo.
Vamos a irnos a nuestro Package.json,
vamos a crear aquí un sit
y vamos a poner Node
y ejecutamos menos r, dotenv config
y ejecutamos el script sit.js.
Con esto lo que estamos haciendo básicamente
es que va a leer, va a importar,
va a hacer un require,
por eso el menos r es require de este módulo
y me ejecutas este script de aquí.
Así nos aseguramos que está leyendo la variable entorno.
Ejecutará esto,
que no es tan importante lo que está haciendo,
pero que sí que sepamos
que está creando todas las tablas
y está insertando información
para que la tengamos en la base de datos
y así no empecemos de cero.
Hacemos npm run sit
para ejecutar este script.
Está creando las tablas
y ahora si nos vamos aquí
y refrescamos,
fíjate que ahora en choose table
ya tenemos las tablas
y podemos ir a customers,
ya tenemos aquí información,
invoices, revenue, users.
Incluso podéis hacer, si queréis,
podéis hacer incluso una query aquí
normal y corriente.
O sea, podéis hacer
select invoices.amount from invoices,
por decir algo,
que es lo que me he acordado, ¿veis?
Y ya podéis hacer,
no es la mejor forma de conectarse,
recordad que podéis conectaros
con vuestro cliente
utilizando las variables de entorno,
pero lo podéis hacer.
En el mundo digital,
brillas con esplendor,
profesor de programación,
maestro de valor.
En cada línea de código,
en cada función,
nos enseñas el arte,
nos das dirección.
Tu sabiduría es una fuente inagotable.
Nos guías con paciencia,
de manera notable.
De manera notable.
Con gratitud y admiración
te honramos hoy
por ser el guía que nos impulsa
a volar alto.
¡Oh, tía!
¡Qué chulo!
Muy bien, ¿eh?
Me ha gustado.
Muchas gracias.
Me ha encantado
Axiever.
Muy bien, muy bien.
Buena...
No sé si la ha hecho
inteligencia artificial,
ChagPT,
pero me ha gustado, ¿eh?
Bueno,
vamos con más cositas.
Ya hemos visto ahí
que podemos utilizar
la data y tal.
Vamos a hacer
el fetching de datos.
Vamos a hacer
el fetching de datos
porque, obviamente,
es lo más importante
para nuestras aplicaciones
de Next.js
y vas a ver
cómo lo podemos lograr,
lo fácil que es
y cómo te va a volar la cabeza.
Hay diferentes formas
en las que podríamos hacer
el fetching de datos
en nuestra aplicación.
Podríamos ir...
Ahora vamos a necesitar
ir a nuestra página...
¿A qué página necesitamos ir?
A la de Dashboard.
A la de Dashboard, aquí.
Y esta página
la vamos a nutrir
de contenido, ¿vale?
Pero, ¿cómo podríamos hacer
el fetching de datos?
Normalmente,
lo que hacía la gente
o lo que harías en React
sería algo así.
Pero, ¿qué pasa con esto?
Que el problema
que tendríamos
del useEffect
y hacer el fetch aquí,
el problema que tendría
que esto,
incluso aunque utilices
React Query, SWR y todo esto,
el problema
es que esas bibliotecas
por dentro
también hacen esto.
Lo que tú no lo ves.
El problema
es que esto haría
el fetching de datos
en la parte del cliente
y, por lo tanto,
ya estaríamos perdiendo
un poco de tiempo
porque podríamos haber
hecho el fetching de datos
en la parte del servidor,
tratar esos datos
y renderizar directamente
HTML.
Va a ser siempre
mucho más rápido
que sea nuestro servidor
el que haga el fetching
de datos
que no que lo haga
el cliente, ¿vale?
O sea,
tiene sentido
por diferentes motivos.
Lo primero es que
el servidor siempre va a tener
una conexión muy buena.
El cliente no lo sabemos.
El cliente puede estar
en el móvil,
en el metro,
en un montón de sitios.
Lo segundo
es que la latencia
que va a tener el servidor
va a ser mucho menor
porque, obviamente,
el usuario puede estar
en Panamá,
en Costa Rica,
no sé qué,
no lo vamos a saber
y, en cambio,
el servidor va a estar
conectado a redes
de alta velocidad
sin ningún tipo de problema.
Y luego es porque
vamos a optimizar
también los recursos.
En lugar de hacer
que el usuario
tenga que hacer
el fetching de datos,
descargar los recursos
para renderizar y tal,
y luego el componente
para renderizar,
lo que estamos haciendo
con NextGIS es decir,
oye,
hazlo en el servidor
y directamente
devuélvele ya
renderizado
lo que sea
que tiene que renderizar.
Por lo tanto,
vamos a enviarle
menos información.
Va a tener que hacer
menos idas y venidas.
Así que es súper importante
que sea NextGIS
en el servidor
el que hace
el fetching de datos.
¿Cómo lo vamos a hacer?
Como hemos dicho,
por defecto,
lo que está ocurriendo
con nuestros componentes
es que se están
renderizando
en el servidor.
Nuestra página
del dashboard,
esta que vemos aquí,
se está renderizando
en el servidor.
Así que esto
es lo que se le llama
un React Server Component.
un componente
que se renderiza
en el servidor.
Y una cosa
que tiene interesante
los componentes
que se renderizan
en el servidor
es que pueden ser
asíncronos.
Un componente
que se utilice
solo en el servidor
puede ser asíncrono.
Por lo tanto,
aquí ya podrías
hacer una wait
y podrías hacer
un fetch
de lo que tú quieras.
Aquí podríamos tirar
de una API externa,
podríamos tirar
de una API externa
y cuando tengamos
aquí la respuesta
podríamos hacer
una cosita así.
Podríamos hacer esto
y este JSON
ya lo podríamos mostrar.
Esto funcionaría
sin ningún problema
pero ojo,
importante,
porque en este caso
ya tenemos
el componente
porque en este caso
es un React Server Component.
Esto no funciona
en los componentes
de cliente de React
normales y corrientes,
solo en los React Server Components.
Vamos a ver cómo funciona,
vamos a ver bien el caso
para que lo veamos
muy, muy, muy claro.
¿Vale?
Si vamos a nuestro,
a un archivo
que tenemos aquí,
¿Veis en lib?
Que os había dicho
que había diferentes archivos.
Tenemos uno
que se llama Data
y este de Data
lo que tiene es
pues para hacer
un fetch de Revenue,
un fetch de las últimas facturas,
fetch de la car,
fetch de las facturas
ya filtradas,
de la página de facturas,
hay un montón de fetch
y en cada uno
está haciendo un SQL.
Por ejemplo,
para recuperar el Revenue
pues está haciendo aquí
un Select All
from Revenue.
Ya está, simplemente.
No hace falta saber SQL
para entender esto,
pero si quieres aprender SQL
tengo un vídeo
en mi canal de Midulife
que seguro que te puede ayudar
que en menos de una hora
te enteras de todo.
Bueno, pues este fetch Revenue
que es un método asíncrono,
en este caso
estamos haciendo una llamada
a SQL,
a una base de datos,
pero esto podría ser
un fetching de datos
a donde tú quieras.
Podría ser una API externa,
podría ser cualquier sitio,
pero en este caso
es interesante
que la hagamos en SQL
y ojo,
aquí no estamos haciendo
una llamada normal y corriente
de que pueda tener,
porque mucha gente cree
y ve aquí un template string
y se cree que aquí
te pueden inyectar
lo que sea, ¿vale?
Pero no,
como ya dijimos,
esto es un template,
¿cómo se llama ahora?
No me acuerdo,
template,
template literal,
que básicamente esto
es como si fuese
una función, ¿vale?
Ves que aquí tienes SQL
y llama directamente
al template string,
esto es porque es como
si fuese una función
a la que se le van a inyectar
como parámetros
las cosas que se pasen
por dentro, ¿ok?
Así que lo digo
para lo que tengas pendiente
y que la gente
que muchas veces
se crea de esto,
pues no es correcto.
Ahora,
ya tenemos aquí
el fetch revenue y tal,
vamos a utilizarlo,
este fetch revenue,
podemos irnos aquí,
fetch revenue,
hacemos una wait
y aquí ya tendríamos
el revenue.
Si aquí ponemos
un console.log de revenue
e importamos
el fetch revenue,
¿vale?
Vamos a ver
si funciona realmente esto.
Hemos hecho aquí
un fetch a saco.
Nos vamos aquí
a nuestra página,
¿vale?
No sé qué le ha pasado ahí,
no sé por qué
algún error había tenido,
¿vale?
Runtime required.
¿Qué ha pasado?
Lib data,
creo que es por este.
Ah, bueno,
espérate,
porque también
no hay otro result dynamic.
Creo que puede ser por esto.
No, no.
Lib,
no.
Puede ser por el turbo,
que lo he dejado al principio,
que he dicho,
vamos a utilizar el turbo
y a lo mejor
el turbo
no funciona del todo.
Bueno,
vamos a quitar el turbo,
vamos a utilizar
el modo normal
y vamos a ver
si funciona,
que debería funcionar.
¿Vale?
Me parece que el error
va por ahí, ¿eh?
¿Ves?
El error es porque estoy
utilizando el turbo
y el turbo ese
no es 100% compatible todavía.
Pero bueno,
mientras lo hemos podido utilizar,
pues lo hemos disfrutado
y ya está.
Vale,
fíjate en una cosa.
Aquí en nuestro componente,
vale,
aquí fíjate que ya tengo
el console.log.
Aquí he puesto un console.log
y este console.log
funcionar funciona
porque tengo aquí el console.log
con toda la data
que tiene la base de datos.
Si vuelvo al editor,
fíjate que aquí en la consola
no tengo la data
porque en el cliente
no se está actualizando,
pero sí que la tengo
en la terminal
porque es en el servidor
donde se ha hecho
el fetching de datos.
Así que ahora
tengo toda esta información
porque he hecho
el fetching de datos
en el servidor
pero no está llegando
a lo que sería
la parte del cliente,
sino que simplemente
hacemos aquí el fetching de datos,
renderizamos esto
y como esta data
ya no la necesita
en el cliente,
la desecha
y ya está.
Vamos a hacer
que sí que realmente
podamos ver nuestro dashboard
y que se vea.
Para eso
vamos a tener,
aquí tiene ya
todos los estilos,
hechos,
aunque tiene comentadas
unas cuantas cosas,
con un h1,
div
y aquí hay unos componentes
que todavía están comentados
porque no tiene la data todavía.
Ahora lo vamos a añadir.
Lusitana este
lo vamos a importar
que es la fuente
que debería mostrar
y simplemente
lo que hemos hecho
es darle un poquito
de layout.
¿Ves?
Que tenemos aquí el dashboard
y ahora mismo está todo vacío
porque no estamos cargando los datos.
Pero ya tenemos el revenue,
así que vamos a aprovechar
que ya tenemos el revenue
y vamos a buscar
el gráfico
donde se carga el revenue
que es aquí.
Fíjate que aquí
en el revenue
funciona.
Este revenue chart
es un componente
que ya es un gráfico
que pasándole el revenue
te lo pinta.
Agregamos la importación
y dentro del componente
vamos a tener que
descomentar algunas cositas.
¿Ves?
Que pone nota,
comenta este código
cuando estés en este punto del curso.
Estamos en ese punto del curso.
Estamos en el punto del curso
en el que queremos mostrar
este gráfico.
Bueno, pues lo descomentamos
¿vale?
Para que nos haga todo esto.
Ya es un gráfico
que está preparado
para recibir el revenue
y mostrarlo
y ahora nos vamos aquí
y ya tenemos esto.
¿Qué es lo que ha hecho esto?
Esto lo que hace es
desde el servidor
está esperando
a estos datos
para poder mostrarlos.
Hace una wait
a nivel de componente.
Bueno, estamos en una página
pero podría ser
a nivel de componente
y de hecho lo vamos a ver después
que es muy chulo
para que veas
cómo se hace un streaming de datos
que eso es brutal.
Entonces, estamos esperando
a esta información
y cuando tenemos esta información
directamente ya mostramos
todo esto.
Por lo tanto,
si esto tarda
dos segundos
el problema que vamos a tener
es que nuestra página
no se mostrará
hasta que no pasen
dos segundos.
¿Vale?
Podríamos seguir haciendo
más fetching de datos.
Hemos hecho el del revenue
vamos a seguir con los otros.
Por ejemplo,
podríamos tener
el del fetch
latest invoices
que sea lo mismo, ¿no?
Latest invoices
await
y esto
lo podríamos poner
aquí.
¿Vale?
Aquí.
Latest invoices
cargamos este componente
y dentro
pues lo mismo.
Tiene todo comentado
porque hasta que no
tengamos los datos
pues no tiene sentido
que utilicemos.
Lo descomentamos
es un componente preparado
para mostrar
la lista de facturas.
Guardamos los cambios
y ya lo tenemos aquí.
Entonces,
aquí hay un tema.
¿Qué estamos haciendo aquí?
Que primera está esperando esta
que esta serían dos segundos
y luego está esperando esta
que sería un segundo, ¿no?
Por lo tanto,
como mínimo
ya tardará
tres segundos
en mostrar nuestra página
porque como estamos
haciendo una wait
que esperamos primero esto
y luego estamos esperando esto
pues ya serían
tres segundos
que estaría tardando.
Hay más información
que podríamos mostrar
pero os lo voy a dejar
para ejercicio, ¿vale?
Si vais aquí
veréis que podéis mostrar
total paid invoices
total pending invoices
o sea que hay más cosas
que podéis mostrar.
Te lo dejo de ejercicio
para que lo hagas tú
porque ahora lo que te voy a enseñar
es cómo podemos arreglar
el problema este.
Imagínate, mira,
imagínate que vamos
a la data esta
el fetch revenue
para recuperar los datos
de revenue
y artificialmente
vamos a hacer
vamos a simular
que tarda
tres segundos, ¿vale?
Fíjate lo que pasa.
Voy a refrescar
y entonces fíjate
que está cargando
uno, dos
y hasta que no pasan
tres segundos
no enseña la página.
¿Ves?
Es mucho más lento.
Ahora la experiencia
que tenemos es malísima
porque le damos a recargar
y fíjate
todo lo que tarda
está tardando un montón.
Tarda tres segundos
y hasta que no ha terminado eso
no está cargando
toda la página
lo cual pues es un rollo, ¿no?
O sea,
¿tarda eso tres segundos?
Pues como eso no lo tiene
no puede mostrar absolutamente nada
pues estamos ya
estamos jodidos.
Vamos a mejorar
la experiencia de desarrollo
utilizando justamente
lo que sería
el streaming de los datos.
Lo que nos va a permitir esto
es decir
oye,
quiero que me muestres
una parte
de lo que tengo disponible
y lo que no tengo disponible
pues me enseñas un esqueleto mientras
y esto sería
lo que es suspense, ¿vale?
Así que vamos por partes.
Vamos a hacer
que esta parte de aquí
no espere
o sea,
o que no espere el resto
a esta parte de aquí.
Para lograrlo
¿qué vamos a hacer?
Bueno,
podríamos hacer dos cosas
porque una cosa
que podríamos hacer
es poner el loading.
Creo que
si hacemos aquí
en dashboard
y ponemos
loading.tsx
y hacemos
export default
loading
function
loading
¿vale?
return
y ponemos aquí
cargando
cargando
¿vale?
Y hacemos esto
si ahora
¿vale?
Vale.
Ahora al menos
hemos hecho algo.
Fíjate que ahora
al menos te aparece un cargando
que no está mal.
¿Cómo hacemos esto?
Esto es otra vez
pues como una regla
que es cuando tú creas
un archivo loading.tsx
en lugar de no cargar nada
lo que vamos a conseguir
es decir
mientras esté cargando
esta ruta
de dashboard
mientras esté cargando
si no tengo los datos
muéstrame algo.
Así que ahora
cuando entremos
pues al menos
le mostramos un loading
o sea, un cargando.
Lo podríamos llevar
a otro nivel
porque obviamente
esto es demasiado sencillo.
Podrías hacer
tener un esqueleto
en condiciones
en lugar de tener esto
decir bueno
pues voy a cargar
el esqueleto
del dashboard
y esto ya empieza
a tener bastante mejor pinta.
Fíjate ¿vale?
Cargas
sale como un esqueleto
y cuando termina
pues aparece ya
el contenido correcto.
Esto lo habrás visto
en Twitter
en Facebook
en un montón de sitios
y esto no está mal
pero estamos haciendo
que solo por un trozo
de la UI
en este caso
esta parte de aquí
que es la que está tardando
tanto por esto
que ya hemos añadido aquí
que tarde tres segundos
por culpa
literalmente
de una línea
que es esta
que tenemos aquí
por esta línea de aquí
esta línea de aquí
lo que estamos haciendo
es que cargue
o veamos
un esqueleto
de toda la página
y esto obviamente
lo vamos a querer arreglar
vamos a querer mejorarlo
de alguna forma
y para eso
vamos a hacer
lo que se le llama
el streaming de HTML
y esto es una de las cosas
que te va a volar
más la cabeza
y es una de las cosas
por las que sirve
a Next.js
o sea
esta es la clave
por la que Next.js
realmente marca la diferencia
¿qué vamos a hacer?
mira
fíjate
vamos a ir aquí
a nuestro componente
este revenue
y lo vamos a envolver
con un componente
de suspense
el componente de suspense
esto en realidad
es una cosa
que es de React
¿no?
esto es una
una dependencia
que tenemos en React
un componente de React
que lo que va a ocurrir
es que le estamos indicando
que lo que está envolviendo
lo vamos a esperar
va a ser asíncrono
y lo vamos a esperar
y mientras lo esperamos
podemos ponerle aquí
un fallback
¿vale?
un fallback que se va a cargar
mientras
por ejemplo
voy a poner aquí
cargando
¿vale?
mientras esta parte de aquí
se esté cargando
vamos a mostrar
el cargando
y cuando ya lo tengamos disponible
lo de dentro
lo que vamos a hacer
es que se renderice
lo de dentro
entonces
este revenue
que habíamos hecho aquí
que es el de 3 segundos
que nos está molestando
lo vamos a quitar de aquí
lo quitamos de aquí
y nos vamos a ir
a nuestro revenue chart
y en este componente
que también es un React Server Component
y esto es una de las cosas
más increíbles que tienen
es que puedes hacer
el fetching de datos
de forma granular
a nivel de componente
vamos a hacer
que en lugar de que le llegue
por props
esto lo vamos a quitar
y vamos a hacer
que el revenue
lo cargue
¿vale?
vamos a hacer este fetch
aquí dentro
lo importamos
y esto es clave
porque
los React Server Component
es una cosa que nos ayuda
también
es con el prop drilling
que es un problema de React
¿no?
de que tú tienes que hacer
el fetching de datos
a nivel de página
y pasar
a nivel de página
al componente
de componente a componente
a componente a componente
porque
por culpa de
gracias a eso
puedes hacer que la información fluya
pero lo bueno
de los React Server Components
es que de forma granular
un componente
puede hacer el fetching de datos
y al hacer el fetching de datos
ya no tienes que hacerlo
a nivel de página
sino que lo puedes hacer
a nivel de componente
y lo que es mejor
como lo haces
a nivel de componente
podemos decir
bueno
como a nivel de componente
este
este no
este de aquí
este componente
tiene que cargar
de forma asíncrona
información
lo que vamos a hacer
es suspenderlo
vamos a hacer un suspense
le ponemos un fallback
que sea este cargando
de forma que
si no tenemos información todavía
mientras está cargando
que muestre esto
y cuando ya por fin
se haya resuelto
mostramos el componente
con la información
vamos a guardar los cambios
nos vamos aquí
parece que todo está igual
vamos a reiniciar
wow
que acaba de pasar
que está pasando
esto es increíble
¿por qué?
porque lo que puedes ver
es que
como esta información
ya la tenemos disponible
desde el principio
lo que está haciendo
es mostrarla
y esta parte
solo ese componente
lo que está ocurriendo es
está esperando
que vengan los datos
y cuando tiene los datos
los está mostrando
y alguien me estará diciendo
bueno ya
pero pega un salto
un poco raro
bueno pero
lo mejor de esto
es que este fallback
tú puedes poner
el que tú quieras
y que te evita a ti
poner un esqueleto
tan chulo
como uno que se encaje
directamente
con ese contenido
de forma que ahora
cuando refresques
aparezca algo así
y que cuando tengas
esta parte
realmente encaje
perfectamente
a nivel de componente
con la información
ahora lo que estamos haciendo
es como esta información
de los últimos facturas
la tenemos disponible
inmediatamente
se la mostramos al usuario
y bueno
esta parte
cuando podamos
pues la vamos a mostrar
se la vamos a enseñar
y esto justamente
es lo que sería
un streaming
del html
¿por qué un streaming
del html?
porque básicamente
lo que estamos viendo aquí
es que está dejando
la conexión abierta
para mostrar la información
¿vale?
fíjate
aquí está dejando la conexión
y cuando tenga la información
entonces es que
la está enviando
cuando ya tenga la información
pues la enseñamos
y ya la tenemos ahí
la cambiamos
y ya está
así que
desde el principio
al usuario
le vamos a enseñar cosas
y solo la parte
que no hemos podido cargar
pues cuando la tengamos
se la vamos a mostrar
y esto lo mejor
es que lo podríamos llevar
a todos los sitios
o sea
esto mismo
lo podríamos llevar
también
aquí ¿no?
podríamos hacer
que en lugar de esperar
a tener el latest invoices
aquí
latest invoices
skeleton
también le podríamos poner
un esqueleto
y así
que sea mucho
mucho mucho
más granular
que de esta forma
todas las cosas
en lugar de cargarlas
a nivel de página
también el latest invoices
lo vamos a cargar
dentro del latest invoices
ya no necesitamos las props
nos vamos para aquí
y aquí es donde vamos a cargar
el latest invoices
importamos la dependencia
y ya está
y ahora estamos haciendo
el fetching de datos
de una forma mucho más granular
que bueno
en este caso es inmediato
vamos a darle
vamos a simular un poquito más
¿vale?
para que lo tengamos
vamos a simular
una wait aquí
¿vale?
no sé
un poquito menos
para que veamos la diferencia
de un segundo solo
y aquí ahora
deberíamos ver que
los dos no aparecen
aparece primero uno
y luego el otro
y además
hemos arreglado una cosa
brutal
y es que ahora
estamos haciendo
el fetching de datos
en paralelo
seguro que antes has pensado
eso con un promisor
se arregla
pero no se arreglaba
del todo
porque el promisor
sí que mejoramos el tiempo
de hacerlo
en paralelo
el fetching de datos
pero aún así
estamos dependiendo
de que terminen todas
para poder mostrar la página
lo que estamos haciendo aquí
es simplemente
cuando tengamos
la mínima información
mostrársela al usuario
y cuando tengamos uno
se lo mostramos
y esperamos al otro
y se lo mostramos
en cuanto antes
pero fíjate que al menos
tenemos todo el layout cargado
toda la página cargada
y cuando estamos teniendo
esa información
es cuando estamos
marcando la diferencia
es tremendo
porque al poder hacer
el fetching
a nivel de componente
el control granular
que estás haciendo
el control de datos
y la experiencia
del usuario
es tremenda
tú imagínate
que cuando entramos
a Twitter
si en lugar de
fíjate
ver la X
luego este cargando
luego vas viendo
como se está cargando
ahí por partes
imagínate poder entrar
directamente a Twitter
y que solo sea
esta parte
y esta parte
que esté teniendo
ese playholder
marcaría totalmente
la diferencia
y seguro que lo entrarían
mucho más rápido
en lugar de
estos flasheos
que está dando
¿por qué esto no se puede hacer
con React?
porque React
no tiene servidor
entonces servidor
tienes que renderizar
desde servidor algo
piensa y fijaos
que aquí
estamos haciendo
service rendering
se está renderizando
desde servidor
y lo podemos ver aquí
cuando tú haces un
view source
vamos a encontrar
por ejemplo
recent revenue
o sea ya estamos
cargando cosas
ya estamos mostrando
HTML
React no puede mostrar
HTML por sí solo
te da las herramientas
los mimbres
pero no lo tienes
desde el principio
entonces cuando muchas veces
digáis
ostras
next.js
es que no sé qué
esto es next.js
esto es lo que realmente
marca la diferencia
de next.js
el hecho de poder hacer
streaming de datos
y tener partes estáticas
de tu página
y otras partes
que sean dinámicas
no ocupas estado
porque los datos
vienen directos
desde la base de datos
bueno
no porque vengan
directos de la base de datos
sino porque lo que estamos
haciendo
no necesitamos estado
porque lo que estamos haciendo
esto es un componente
que se renderiza
en el servidor
y lo que estamos haciendo
es simplemente
hacer una wait
directamente
y como esto va a esperar
hasta renderizar esto
pues por eso no he detectado
ningún tipo de estado
a nivel de SEO
¿te penaliza que el contenido
primero sea un esqueleto?
eso es lo más interesante
según Google
no penaliza
y además
hay otro tema interesante
y es que
si detecta
podríamos hacer
que si se detectase
que es un bot
podríamos hacer
que espere
y que ignore
el suspense
¿sabes?
si es un bot
ignoras totalmente
el suspense
y esto no está penalizado
porque justamente
de esto habla Google
se llama
Dynamic Rendering
y esto es lo que
lo que habla
no, Dynamic Rendering
no, esto es lo que
recomendaban antes
¿ves?
es una solución provisional
esto no es exactamente
esto
esto es una cosa distinta
porque esto lo que hacía
era hacer un
renderizado estático
de algo que era dinámico
para dárselo a Google
pero sí que
he visto un montón de veces
que dicen que no hay
ningún tipo de problema
siempre y cuando
o sea, lo que penaliza
Google
es que tú
enseñes
información diferente
al usuario
y a Google
en el sentido
de que sea
diferente
porque piensa que
hoy en día
de hecho aquí lo pone
hoy en día Google
carga realmente
el JavaScript
¿vale?
ahora sí que carga
el JavaScript
lo que pasa es que
tarda un poco más
pero lo que estamos
utilizando ahora mismo
en Google
está cargando el JavaScript
y se va a asegurar
que estés renderizando
exactamente lo que espera
pero en React
también está el suspense
¿qué diferencia hay
a hacerlo en React?
porque como
de nuevo
el tema
es que tú puedes utilizar
el suspense
para hacerlo con cargas
dinámicas
pero no puedes hacer
este efecto wow
de renderizar desde el servidor
suspense es un componente
de React
que si haces cualquier cosa
dinámica
o cargas dinámicamente
un componente
lo puedes utilizar
para cargar
un fallback
puedes hacer
este esqueleto
pero lo que no vas
a poder hacer
es
¿ves?
vas a poder hacer esto
pero lo que no vas a poder hacer
es renderizar desde el servidor
¿vale?
¿cómo podríamos refrescar
los datos
de un componente server
desde un componente cliente?
por ejemplo
un botón
para refrescar la gráfica
lo podrías hacer
sin ningún problema
lo que tendrías que hacer
es hacer un revalidate
eso lo veremos más adelante
pero lo que puedes decirle es
quiero que revalides esta ruta
y por lo tanto
se renderizan los componentes
en el servidor
no habría ningún problema
se puede decir
que la esencia de Next
es el service a render
y tratar de utilizar
lo menos posible el cliente
efectivamente
Next.js
lo que viene a proponerte
es que muevas
cuanto más puedas
al servidor
para que la experiencia
del usuario
sea la mejor posible
y obviamente
es que es lo que tiene
todo el sentido del mundo
para que lo tengamos en cuenta
Next.js
es un framework
de backend
porque
todo lo que te añade
es la parte del backend
no es la parte del front
la parte del front
ya la tenemos con React
y sí
te la adorna un poco
con navegación SPA
con un montón de cosas
pero
lo que justamente
te propone
es toda la parte del backend
el enrutado
basado en sistema
de archivos
poder tener rutas
de APIs
el poder hacer
fetching de datos
server
ser rendering
todo este tipo
de cosas
es lo que justamente
está dando
volvemos a PHP
renderizado desde el servidor
a ver
el hecho de que volvamos a PHP
nunca ha dejado de tener sentido
el renderizado en el servidor
o sea
es que esto es una cosa
que la gente siempre ha entendido mal
el hecho de decir
no
React
SPA
pero el renderizado en el servidor
de hecho
desde el principio
en mi empresa
por ejemplo
utilizamos React
desde antes
desde antes de Next.js
y React siempre
se ha podido renderizar
en el servidor
no es una cosa nueva
no es una cosa novedosa
desde el día uno
desde el día uno
React ha pensado
en poder renderizarse
desde el servidor
lo digo porque
React.dom
tenéis
las APIs del servidor
de React.dom
esto ha sido desde el principio
no es una cosa nueva
siempre ha estado pensado
en
en poder renderizarse
desde el servidor
de tener el render to string
que ahora por ejemplo
render to string
no está tan recomendado
lo recomendable
sea render to pipe
pavel string
pero esto ha existido siempre
entonces
es que nunca ha sido mala idea
renderizarse desde el servidor
siempre ha sido algo
que React ha tenido en cuenta
solo que Next.js
ahora
nos lo está simplificando
un montón
y Angular
para cuando el curso
desvelte kit
es que siendo que
varias de estas cosas
son más sencillas allá
lo tendemos
lo tendemos
la gente
¿por qué jatea todo
en vez de si quieres
lo usas
y si no te vas a Angular
o lo que te da la gana?
sí a ver
yo creo que Angular
está genial
Next.js está genial
a ver
Remix está genial
pero yo creo que esto
es súper genial
o sea que está muy muy muy bien
o sea que creo que
la experiencia
que conseguís
con este tipo de cosas
es tremenda
y hacer esto
con pocas líneas de código
como lo hemos logrado
es bastante difícil
o sea que
os recomiendo
que le echéis un vistazo
yo creo que vale la pena
porque este tipo de experiencia
de usuario
está muy bien
no la idea
de las SPA
era mover renderizado
al cliente
para evitar
eso es mentira
eso es mentira
y es una cosa
que se repite mucho
pero porque no se entiende
la idea de las SPA
no era la idea
eso es la idea
que nosotros le hemos dado
¿vale?
la idea de las SPA
es simplemente
es la navegación inmediata
entre rutas
dentro del cliente
punto
punto
el hecho de
la idea de las SPA
significa
single page application
no era mover
el renderizado
al cliente
para evitar
que el server
tuviera tanta carga
y tal
y además
del separation of concerns
para que el trabajo
pueda avanzar rápido
teniendo claro
que es back y front
no tiene nada que ver
SPA
que significa
single page application
y que al final
de lo que se trata
realmente
la idea
es básicamente
de tener
en el cliente
navegaciones
más rápidas
transiciones inmediatas
punto
cualquier otra cosa
que tú entiendas
de cómo eran las SPAs
de mover y tal
eso son cosas
que al final
son cosas
que habéis entendido vosotros
porque habéis querido
que sean interesantes
¿vale?
que podéis pensar
en separación
de los conceptos
y tal
pero no era la idea
de las SPAs
las SPAs
hemos hecho una SPA
la SPA
es básicamente
que podamos tener
una navegación
de una página a otra
y que sea lo más
instantáneo posible
evitando tener
que recargar la página
punto
ya está
esa es la diferencia
entre la SPA
y la MPA
a partir de ahí
que cada uno
pues
ah bueno
es casi separado
conceptos
o que haya un framework
que hiciera eso
puede ser
puede ser interesante
pero al final
¿se tiene que revalidar
toda la ruta
o se puede por ejemplo
solo el gráfico?
se tendría que revalidar
toda la ruta
lo que podrías hacer
es que el gráfico
fuese una subruta
que no sé qué
eso lo podrías llegar a hacer
pero no
tendrías que revalidar
toda la ruta
no entiendo la polémica
con Next
puedes usar una app igual
claro totalmente
podéis utilizar
a ver
yo he utilizado SQL
como ejemplo
pero
a ver
otro error muy común
que es el hecho
de que la gente
puede ver esto de SQL
esto de SQL
que veis
todo esto
esto se queda en el servidor
¿vale?
Next.js sería un monolito
total
total
todo esto que veis
esto no llega
al cliente
¿vale?
esto no llega al cliente
de ninguna forma
si vosotros buscáis
en el JavaScript
que se descarga aquí
no vais a encontrar
estas cosas
¿vale?
si vais a search
si buscáis SQL
select
no sé qué
no sé cuánto
no lo vais a encontrar
no está ahí el select
eso está solo
solo en el servidor
o sea que
no se está mezclando
o sea
no se está mezclando
frontend y backend
realmente está separado
lo que pasa es que
se está como simplificando
el que puedas trabajar
mucho más integrado
y no tener que repetir
la UI dos veces
mira
sobre lo que se comentaba
antes de separación
de conceptos
os voy a comentar
una cosa que realmente
sí que es lo que se está buscando
con este tema de cosas
¿no?
el tema es que Next.js
es un monolito
que durante mucho tiempo
han tenido mala fama
¿vale?
los monolitos
pero los monolitos
no son malos per se
a veces son buenos
a veces son malos
pero sobre todo
pueden estar mal hechos
y pueden tener muchos problemas
el problema
el gran problema
que hemos tenido muchas veces
como mucha gente habla
de los errores del pasado
de PHP
y todo esto
¿no?
el problema principal
que hemos tenido históricamente
no era
el hecho de
mezclar
el backend y el frontend
el problema que teníamos
históricamente
era repetir
el frontend dos veces
y crear la UI
tanto en el backend
como en el frontend
y esto lo habréis visto
un montón de veces
en monolitos
y todo esto ¿no?
habréis visto
que lo que había que hacer
era
tú creabas en el servidor
en PHP
la UI
y luego
dinámicamente
con jQuery
con lo que sea
tenías que
recrear
la misma UI
para parchearla
este ha sido siempre
el problema histórico
y lo
lo que realmente
busca Next.js
que me parece muy interesante
es que
solo lo escribes una vez
o sea realmente
estás utilizando
siempre el mismo lenguaje
y la UI
es la misma
tanto para el servidor
como para el cliente
el hecho de separar
al final
podéis separarlo
a ficheros
sin ningún tipo de problema
o sea
podría separar mejor esto
lo podrías meter
en una carpeta server
al final
os está dejando
a vosotros
este tipo de problemas
sin ninguna cosa
eso es mentira
dice Gato1Neptuno
dice no
pero eso ya está
solucionado en PHP
usamos includes
y hacíamos una sola vez
cada pieza de UI
esto no es verdad
tampoco
no es verdad
porque eso es
de forma estática
entonces Gato1Neptuno
si el usuario
por ejemplo
hacía click
a un elemento
y tenías que cargar
tres elementos más
eso
¿cómo lo hacías?
con el include de PHP
eso no lo hacías
con el include de PHP
eso lo hacías
parcheando con jQuery
porque ese es justamente el problema
que con el include
tienes la parte estática
pero la parte dinámica
te la estás perdiendo
¿entiendes?
es que me parece que mucha gente
esto no lo entiende
y ese era el verdadero problema
que había
no se trata tan bien
es que incluso
los nuevos frameworks
lo podéis ver
que sí
que a lo mejor
hay algún framework
que reconvierte
o compila JavaScript
que lo consigue solucionar
y es que está bien
porque es hacia donde van
los nuevos frameworks
tanto Next.js
como frameworks nuevos
de PHP y tal
vienen a solucionar eso
de que tú escribas
la misma UI
tanto en servidor
como en cliente
pero no lo soluciona
el include
lo está solucionando
los nuevos frameworks
o sea
no es un tema
de que sea Next.js
que solo lo está haciendo
es que lo está haciendo
todo el mundo
porque al final
era el problema
que estamos teniendo
realmente en la UI
que es lo que me parece
realmente importante
¿sabes?
el hecho de evitar
parchear
en el cliente
la UI
cuando es dinámica
¿entendéis?
ese es realmente
el problema
que hemos tenido
muchas veces
entonces no harías
una API con Express
que haga las consultas
y usa Next
no porque en este caso
Next.js
ya tienes una forma
de crear las rutas
de las APIs
entonces ya no tendría sentido
ya deje en PHP
que sabemos que
pero no es un problema
de PHP
no digo que sea
algo negativo
de PHP
o sea
PHP es positivo
en muchas cosas
y seguro que hay frameworks
que han salido
hoy en día
que solucionan eso
pero me refiero
a cosas antiguas
¿sabes?
de por ejemplo
como era antiguamente
lo digo así
ya sea como por ejemplo
con C Sharp
también ha pasado
durante mucho tiempo
me refiero
antiguamente
como lo hacíamos
el problema
de los monolitos antiguos
de que hacíamos eso
que no hate a PHP
me refiero a como lo hacíamos
antes los monolitos
y justamente lo interesante
de Next.js
es evitar
cometer ese error
de tener que reescribir
la misma UI dos veces
eso es lo que realmente
creo que lo hace necesario
interesante
¿ya no es necesario
context y use context?
sí
porque a lo mejor
necesitan menos
¿te parece bien
que React.js
deje en tanto juego
al dev
para que organice
el código
como le parezca?
yo creo que sí
porque hay veces
que pasa
mira
si le da mucho juego
porque le da mucho juego
pero si no le di ese juego
la gente se quejaría
y yo creo que una de las cosas
buenas justamente
es que le dé ese juego
porque
porque al final
eso es lo que permite
es que la gente
encaje mejor
su forma de programar
y como lo quiere hacer
es una cosa
que le ha ido muy bien
durante mucho tiempo a React
y espero que le vaya bien
yo creo que lo bueno
es la libertad
y que la gente invente
sí
porque al final
hay veces
y hay patrones
que al final llegan
que se quedan tarde
que no funcionan
y todo esto
no funcionan
así
y