This graph shows how many times the word ______ has been mentioned throughout the history of the program.
vamos a hacer en la clase de hoy. Os recuerdo a todos y a todas que esta es la serie de vídeos
donde estamos haciendo un clon de Twitter, o de Twitter, o Twittera, o Twittera, o como
queráis pronunciar, desde cero con Next10, ¿vale? Y estamos viendo cada una de las etapas,
lo estamos intentando hacer con las mejores prácticas y por lo tanto hay una cosita que
se nos ha pasado de largo que era el tema del linter, ponerle un linter a nuestro proyecto.
Yo es que estoy como tan acostumbrado, ¿no? Pues que ya pues ni linter ni nada. Pero sí, vamos a ponerle
un linter y además vamos a añadirle Prettier. Entonces, si te estás añadiendo ahora a esta
serie de vídeos, te digo que tenemos en GitHub un repositorio donde tienes todas las clases
disponibles, ¿vale? Aquí tenemos la primera donde hicimos una inicialización, una introducción
de Next10. Además le puedes dar a código para que te lleve directamente a la rama donde está
el código que hicimos en esa clase. Desde Master podrías empezar desde cero, pero en Master
el Ritmi ya te dice las clases que hemos ido haciendo. Además también tienes un acceso
directo a cada uno de los vídeos. Lo mismo aquí con la segunda clase que fue la semana
anterior, que hicimos el login con GitHub usando Firebase y también hicimos más StyleJSX.
Y tienes lo mismo, el código que va a ser este código del que vamos a empezar hoy y el vídeo
para que no te pierdas absolutamente nada. De hecho, ya que estamos aquí, que he dicho
lo del código, pues le voy a dar a código porque es aquí, ¿no? Que tenemos esta rama
02 StyleJSX Login con GitHub que, vamos a ver si tengo esto por aquí. Sí, vale. Vamos
a ver en qué rama estoy porque creo que estoy en Master. Vale, pues este es mi editor de
código. Vale, igual me he pasado de grande. Estoy en mi proyecto de Depter, entonces estoy
en Master. Pues vamos a cambiar, esto es un alias que yo tengo, ¿vale? Que es para cambiar
de rama fácilmente. Y vamos a cambiar a esta de 02. A ver, está
el JSX Login con GitHub. Entramos en ella. Ay, no, es que claro, es que esa ya existe.
Voy a hacer un checkout. Si ya existe, no la puedo volver a crear. Es que ese es el alias
para crearla. Vale, git checkout y el nombre de la rama y ya estamos dentro. Entonces ya
habremos visto a la izquierda, ¿no? Que nos ha creado un montón de archivos y tal, que
son los de la clase anterior. Así que vamos a empezar a partir de ahí. Lo primero que
vamos a hacer, si es que todo funciona como debería, vamos a hacer un npm run y aquí
vamos a ver los scripts que tenemos en nuestro proyecto. Hacemos un run dev, a ver si esto
funciona bien. Hay veces, si por lo que sea te da un error el run dev, es que NextDS como
funciona es que hace una pequeña build antes de empezar para que luego vaya mucho más rápido,
¿vale? Entonces, si por lo que sea te falla o te da algún tipo de error, intenta hacer
un npm run build, este script que tenemos aquí, ¿vale? Y de esta forma seguramente
te lo solucionará. Y te creará esta carpeta Next y ya está. Hay veces que si cambias
de ramas y lo que sea, pues te puede desaparecer y eso pues no es bueno. Así que voy a poner
esto por aquí. Y esto ya nos debe haber dejado en localhost 3000 pues nuestro proyectito,
¿vale? Lo vamos a entrar. De hecho, está bien, ¿no? Porque hasta que no entras al proyecto
pues no empieza a compilar y todo esto, ¿vale? Muy bien. Pues ahora que ya tenemos
esto, voy a configurar, voy a poneros por aquí más cerquita porque empiezo a tener
aquí un montón de ventanas. Vale. Esto por aquí. Perfecto. Vale. Pues esto es como se
quedó la home porque hicimos el login con GitHub. Y me he dado cuenta que hay un error, ¿vale?
Hay un pequeño error aquí que lo dejamos al final, que no nos dimos cuenta. Y seguramente
lo arreglemos después, ¿no? Pero es cuando no estás logado, no has iniciado la sesión,
pues deja de funcionar la parte de aquí abajo. Entonces, eso lo vamos a ver, lo solucionaremos.
Pero antes me gustaría pues que hiciésemos ya lo del linter y el priter. Así que empiezo
a explicaros un poquito de qué se trata. Tenemos el slint. El slint es una herramienta
que lo que hace es lintarnos el código. Que lintar es un poco raro, ¿no? Es un nombre,
es un verbo un poquito extraño, ¿no? Pero lo que hace es encontrarte problemas
que tengas en tu código. Y lo interesante de esto es que no solo te mira los problemas
que tienes al formatear tu código, ¿no? O sea, de, digamos, una sintaxis de cuántos
espacios utilizas, si hay punto y coma, si utilizas comillas y cosas así, sino que
además es lo suficientemente inteligente para detectar otros problemas. Como por ejemplo,
pues que te has dejado una variable sin usar. Y te dice, oye, esta variable la tienes aquí,
la has creado, pero no existe. O sea, no la estás utilizando en el código, ¿no?
Y eso te lo puede decir como un error. Así que digamos que tiene como dos misiones.
Una, ver si estás formateando correctamente tu código. Y otra más, de ver si tu código
pues contiene bugs o código muerto, cosas que no necesita, cosas así.
Entonces, lo más interesante, además de slint, es que te puede solucionar automáticamente
estos problemas, ¿no? Tiene esto de, aquí lo pone fix automatically, que lo que hace
es que tú le pasas un parámetro fix y lo que hace es, pues, directamente solucionarte
ciertos problemas. No te los soluciona a todos, ¿vale? Esto no es magia, ni es inteligencia
artificial, ni machine learning, ni nada. Pero hay algunos que sí que los puede solucionar.
Si te has dejado espacios de más, si te falta un salto de línea, si has puesto comillas
y cosas así, sí que lo soluciona. O, por ejemplo, si hay una variable que la has utilizado
como let y no la cambias en ningún sitio, hay una regla que tiene slint que te dice,
ah, pues, esto podría ser una const y te la cambia automáticamente.
Al final, lo interesante es que slint es tan potente como tú quieras. ¿Por qué? Porque
en realidad slint va a base de reglas. O sea, en realidad piensa que slint es una herramienta
que como tal lo que hace es encontrar esos problemas. Pero ¿qué problemas encuentra?
Por defecto, tiene algunas reglas, ¿no? Y al final tú le puedes ir añadiendo reglas,
puede ser, bueno, pues esto es una locura porque dependiendo de las herramientas que
utilices o la librería, bibliotecas que tengas en tu proyecto, pues, por ejemplo, React
tiene sus propias reglas, las que puedes ir viendo si estás utilizando bien los hooks
y cosas así. Entonces, aquí podemos ver que tienes plugins y los plugins en sí mismo
tienen reglas. Y luego tienes los presets que tienen plugins, que los plugins tienen reglas.
Así que es muy configurable, está muy, muy, muy bien y es lo primero por donde vamos
a empezar para añadir en nuestro proyecto porque nos va a ayudar a asegurarnos que
en nuestro proyecto, pues, no cometemos errores antes de comitear o hacer un deploy y tal.
Así que vamos a ir a nuestro proyecto y lo primero que vamos a hacer aquí, voy a hacer
esto más chiquitito, voy a abrir otra pestaña y la voy a hacer un poquito más grande.
Lo primero que vamos a hacer aquí es básicamente añadir slint, así. En este caso, yo estoy
utilizando yarn, ¿vale? Porque al principio, pues, estaba cuando creamos el proyecto, existía
esa posibilidad y yo estoy utilizando yarn porque lo tenía ya instalado en mi máquina
y ya lo he utilizado. Pero puede ser que tú tengas npm. Si tienes npm, pues, haces npm install
slint menos d mayúscula, que esto es, que significa que es una dependencia de desarrollo.
Creo que en yarn también es slint menos d para decirle que es de desarrollo. Si no, ahora
vamos a ver si le gusta o no le gusta. Vamos a empezar por aquí. Esto no debería tardar
mucho. Vale. Entonces, ahora lo que deberíamos hacer es inicializar toda la configuración
de slint y tal. Entonces, esto funciona con los archivos de configuración y luego tienes
que instalar los paquetes. Podríamos ponernos a buscar ahí qué plugins tenemos que instalar,
qué reglas tenemos que instalar y tal, ¿no? Pero hay una cosa que no utiliza mucha gente,
pero a mí me parece muy interesante, que es el utilizar slint en sí mismo para inicializarlo.
Vale. Creo que es npx slint guión guión init. Y esto lo que hace es inicializar toda la configuración.
Nos va a hacer unas preguntas y esto lo que va a hacer es preguntarnos, pues, nada, qué estilo
nos gustaría, qué esperamos de slint y cosas así. Ahora, si no conoces npx, esto es lo mismo
que ahora mismo si hiciésemos .barra node modules .bin, que es donde guarda los binarios,
las dependencias de node que hemos instalado, slint guión guión fix. Es lo mismo en este caso.
npx viene con las últimas versiones de npm y lo deberíais tener. Vale. Esto me ha dejado...
Ay, fix. He puesto fix. Fix esto no ahora. Ahora no. Ahora no fix. Init. ¿Vale? Guión guión init.
Aquí vienen las preguntas. Si queremos mirar sintaxis, si queremos mirar sintaxis y también
pues encontrar problemas, si queremos mirar sintaxis y encontrar problemas y asegurarnos
que utilizamos un estilo en nuestro código. Y esto es muy interesante, ¿vale? Aquí ya podéis
ver lo potente que es el linter o en este caso es lint, ¿no? Porque no solo va a chequear
la sintaxis y encontrar problemas, sino que nos va a asegurar que toda la gente que tenemos
en nuestro proyecto va a utilizar exactamente el mismo estilo de código. Esto quiere decir
que si decimos que utilizar puntos y coma es un error, nos va a decir esto es un error,
¿vale? No lo puedes hacer y por lo tanto pues deja de utilizar puntos y coma. O al revés,
¿vale? Pero lo interesante es que no vamos a encontrarnos una línea que tiene punto y coma
y otra que no tiene punto y coma. En este caso nos gustaría ir a por el paquete completo,
¿vale? Queremos chequear la sintaxis, encontrar problemas y asegurarnos que utilizamos el mismo estilo
en todo nuestro código. Así que vamos a por esa opción. Ahora tenemos otras tres opciones
más, ¿no? Que si utilizamos JavaScript Modules, si utilizamos como un JS o si no es ninguna
de estas. En nuestro caso, JavaScript Modules porque utilizamos los imports, los exports y
todo esto. ¿Qué framework estamos utilizando en nuestro proyecto? Pues React, Vue o ninguno
de estos. En este caso, React. Y ahora, si utilizamos TypeScript o no utilizamos TypeScript.
En este caso, le decimos que no estamos utilizando TypeScript. Esto al final, lo que nos está
haciendo es la configuración, que si luego utilizamos TypeScript, pues lo podemos arreglar, ¿vale?
Esto no es inmutable. Entonces, vamos a decirle que también utilizamos tanto Browser como
Node. Para esto le vamos a dar a la A, ¿vale? Para que nos seleccione las dos. Y ahora nos
dice que qué estilo nos gustaría utilizar. Y entonces le voy a decir que uno, popular.
Podríamos decirle que ir contestando un montón de preguntas que nos hace ahí como si fuese
un costonario, pero yo tengo muy claro el estilo que me gusta. Es mi opinión, es subjetivo
y en este punto sería súper bien que elijas el que más te guste a ti. En mi caso, de los
que nos ofrece, me gusta muchísimo Standard, ¿vale? Porque no utiliza puntos y coma y como
sabéis, pues yo no utilizo puntos y coma. Y además tiene otras reglas que a mí particularmente
me parecen muy buenas de inicio. Así que vamos con la de Standard. Y ahora nos va a decir
en qué formato nos gustaría tener la configuración. En este caso le podemos decir que nos lo ponga
en JavaScript, en Jam, en JSON o lo que sea. Pues vamos a decir JavaScript. Ahora nos
dice, oye, estoy encontrando que necesitamos ciertas dependencias para todo lo que hemos
dicho, ¿vale? Necesito ciertas dependencias para funcionar y no las tienes instaladas y
son requeridas, por lo tanto te las voy a instalar. Dice, ¿te gustaría utilizar MPM para
instalarlas? Pues le vamos a decir que no, ¿no? Porque no podemos utilizar MPM en nuestro
proyecto. Lo importante, por ahora, ahora lo arreglamos esto, ahora solucionamos esto,
porque, bueno, ya ha intentado ejecutarse, pero ha dicho que algo ha ido mal, porque no
ha podido encontrar esto, lo otro, bueno, eso ahora lo solucionamos. Lo interesante es
que ya nos ha creado este archivo, slingrc.js. Y podemos ver, pues, que esto ya tiene configuración
que ha venido determinada por nuestras respuestas, ¿vale? Hasta aquí, bien. Ya nos ha creado
el archivo, perfecto. Así que, lo que vamos a hacer ahora es instalar las dependencias
que nos ha dicho y las vamos a hacer con YAR, ¿vale? Vamos a subir para arriba y vamos
a copiarnosla, ¿vale? Para, como total, no, todo esto de que sea latest y todo esto no
nos interesa tanto, o sea, esto lo vamos a quitar para instalar las últimas, bueno, es
que con YAR creo que esta sintaxis no va a ir bien y nos puede fallar por alguna cosilla.
Al final, esto que estamos haciendo es exactamente lo mismo, pero lo que voy a decir es que añada
todos estos paquetes y ya está, ¿vale? Así que hago un YAR, voy a hacer un poco más grande
esto, porque como está tan abajo, y voy a pegar todos los paquetes estos, ¿vale? Así
que, pum, los pego ahí y que se instalen. Vamos a ver por dónde nos sale esto, ¿vale?
Así que, a ver, se debe estar instalando, ¿vale? Ya se han instalado todas, voy a cerrar
este archivo, voy a entrar aquí a slint, ¿vale? Vale, perfecto, porque ya ha pasado
algo aquí. Voy a cerrar mientras en la terminal para que veamos mejor qué está pasando por
aquí. Voy a cerrar esto. ¿Qué ha pasado? ¿Qué ha pachao? Que de repente mi archivo
esto está lleno de rojo por todos los lados, ¿no? O sea, ¿qué ha pasado aquí? Vale,
lo que ha pasado aquí... ¡Ay! Se me ha olvidado el menos D, me lo ha dicho Nicolás Santi,
mira, no pasa nada, no nos preocupemos, ¿vale? No pasa nada. Al final, no he puesto el menos
D y por lo tanto me lo ha puesto como dependencias. No pasa nada, porque hacemos esto, lo seleccionamos,
le damos al Alt y lo vamos bajando y ya está. ¡Pim! Ya está solucionado. Nadie ha visto
nada, no ha visto nada. Guardamos ahí el archivo y ya está. ¡Pum! No ha pasado nada.
Vale, entonces, volvemos aquí. ¿Eh? No ha pasado nada, no ha pasado nada. En vuestro caso acordaos
de menos D mayúscula, ¿vale? Cuando hagáis el Jan-A. Vale, entonces, el caso que...
¿Qué ha pasado? Ya está, se te fue el de... No, no pasa nada, ya está, ya está, ya está,
ya está arreglado, ya está arreglado. Vale, entonces, el caso. Ya tenemos aquí, lo tenemos
todo en rojo, ¿vale? Esto es un poco raro que esté todo en rojo, ¿vale? Pero esto está en rojo
por un motivo y es que el linter, ya con todo lo que se ha inicializado, el propio linter,
en su propio archivo de configuración está detectando problemas, ¿vale? ¿Y qué nos está
diciendo? Bueno, nos está diciendo de todo. Pues que estamos metiendo comillas donde no
es necesario, que los strings tendríamos que utilizar single quotes, digamos que por defecto
pues hay diferentes reglas, ya. Si yo ahora lo guardo, me lo va a solucionar, ¿no? Pero
¿por qué? ¿Por qué me ha detectado todo esto? ¿Por qué esto está funcionando tan bien?
Es posible que en tu caso no veas esto, ¿vale? Que hayas instalado todo esto y por
ahora no veas ningún cambio. Lo primero es que para solucionar la integración en tu
editor tienes que ver qué extensión tienes que instalar. En nuestro caso, en Visual Studio
Code, tenemos la de Slint, ¿vale? Además, súper importante que no te instales una random
porque hay veces que te aparece por lo que sea Slint y tal. Es muy fácil detectar cuáles son
las buenas porque tiene como 10 millones de descargas, o sea, 10 millones de descargas.
Además suelen tener una estrellita cuando son destacadas. En este caso tienes que instalar
Slint. Entonces, yo lo tengo configurado además de que si yo ahora le doy a guardar, lo que
va a hacer es solucionarme los problemas. ¿Y cómo me los va a solucionar? Porque estaría
utilizando el comando slint-fix. Lo que podemos hacer es en la terminal, vamos a volver aquí
a la terminal, y vamos a ver los problemas que ahora mismo tenemos en nuestro código.
Podríamos poner npx slint, punto, y esto nos debería buscar todos los problemas que
tenemos, ¿vale? Aquí ya nos salen un montón de problemas en todo nuestro proyecto. El error,
aquí se necesita un espacio y tal. Ahora, lo que podemos hacer, ¿vale? He puesto el npx
porque ya lo tenemos en NodeModules, lo tenemos en la carpeta binario, ¿vale? Lo mismo, aquí
podemos hacer .nodeModules barra .bin barra slint. Podríamos hacer esto perfectamente.
Ahora, me salen un montón de errores, pero ni me voy a preocupar. Lo que voy a hacer es
guión guión fix, ¿vale? Le voy a decir, oye, los que puedas, arreglalos, porque no me los
voy a mirar yo manualmente. Así que vamos a hacer esto con el fix, ¿vale? Entonces,
podemos ver que ahora tengo menos errores. Antes tenía 40 y pico, pues ahora tengo 36.
Bueno, no sé cuántos tenía antes, pero ahora tengo menos errores. Me ha solucionado
unos cuantos. Me ha guardado los cambios en los archivos y, de hecho, podemos ver aquí
en los cambios que tenemos para comitear, ¿no? Pues, por ejemplo, aquí, pues que tenemos,
bueno, me ha añadido un salto de línea y es que al final hay una regla que te dice
que todos los archivos tienen que tener un salto de línea al final. Bueno, pues eso nos
lo ha hecho en todos los archivos. Perfecto. Aquí, por ejemplo, en el import, pues ves
que esto yo lo había dejado junto y ahora, pues me ha dejado un espacio porque ahora
hay una regla que te obliga. Aquí podríamos ver que estos son tipo de errores más de
formateo de tu código, ¿vale? Que luego más adelante con Pritier veremos que pueden
chocar. Vale, pues voy a cerrar esto y ahora, ¿qué pasa? Pues que tengo aquí un error que
me dice que React tiene que estar en el scope y tal. Bueno, como es un coñazo, ¿no? Que
estemos aquí y tengamos que poner en la terminal estas cosas que a lo mejor o no entendemos
o no nos acordamos o lo que sea, lo primero que deberíamos hacer es en el Package.json
pues tener un script que nos diga, oye, vamos a alentar nuestro código y así directamente,
además, como los scripts del Package.json directamente tienen acceso al path del node modules
bin, no tenemos que hacer nada de npx ni nada, sino que ponemos slink, slink punto y le
decimos el fix, ¿vale? Y ahora ya pues hacemos npm run link y esto nos hace exactamente lo
mismo que hemos hecho antes. ¿Vale? Peta, ¿por qué? Porque tenemos los errores. Entonces,
esto hasta aquí. Ahora, como decía, ¿qué pasa? Voy a tirar hacia atrás el archivo de
configuración, el que tenía un montón de... ¡Ay! He tirado para atrás el archivo de
configuración y es el que justamente tenía todos los cambios preparados. O sea, no tenía que haber
tirado para atrás. Bueno, no pasa nada, lo puedo volver a crear, lo puedo volver a crear. Así... ¡Ay!
Venga. JavaScript... Sí, es que quería enseñaros los errores otra vez. Venga, a JavaScript. ¿Quieres
instalarlos? No. Vale. Ahora esto me lo debe haber creado otra vez. Vale, ya está. He hecho el in-it otra vez,
súper rápido y no se ha notado, ¿vale? Entonces, este es el que teníamos aquí hoy, pues un montón
de problemas, errores y tal. Que veo que ahora no me los está... ¡Ah, sí! Bueno, no me los está enseñando
porque se ha quedado tonto porque he hecho otra vez el link. Pero el tema es que cuando guardo,
cuando guardo veréis que me lo formatea, ¿vale? Esto de que al guardar te lo formatee, lo podéis
conseguir si vais a vuestras opciones, ¿vale? Esto no lo hace por defecto. Pero entre las opciones... ¡Ay!
Me ha salido como JSON. No quiero... Open... A ver, Open Settings. Aquí está. Y aquí
tenemos el Slink. Vale. Aquí tenemos un montón de opciones que te dice, oye, cómo tenemos que
hacer el formateo, cuándo lo tiene que hacer, si tiene que utilizar el Slink que tienes en
el NodeModules o no. Aquí va un consejo, ¿vale? No utilicéis nunca el global. Y os digo
por qué. Porque si tenéis el global, solo podéis tener una versión del Slink. Entonces,
lo que tenéis que hacer es que cada proyecto puede tener la versión 2, la 3, la 4, la
5... Creo que van por la 7. ¿Vale? Entonces, no utilicéis la global. Es mala idea. Siempre
que podáis, utilizáis la de vuestro proyecto. ¿Vale? Eso es importante. Creo que se puede
hacer que utilicéis el global, pero evitarlo siempre que podáis. ¿Vale? Y sobre todo aseguraros
que está activado. Vale. Veo que el de J... Así. Hice Code Actions on Save. Yo lo tengo
en inglés. No sé si en castellano está traducido. Me imagino que no. Pero bueno.
Pero bueno. Podemos hacer, por ejemplo, que solo cuando guardamos, pues haga... Solo... O sea,
formatee todo. O sea, los que son problemas. También los que pueda ser warnings y tal. Si
por lo que sea no encontráis aquí el de Save, que por lo que veo no está o no lo encuentro.
El de... Ah, mira. ¿Cuándo tiene que ejecutarse? Este también es interesante. Si lo ponéis
en Type, mientras escribís, lo va a estar ejecutando. Esto puede ser a veces que sea un poco...
un poco... Si estáis en una máquina antigua, esto puede ser bastante tocho y a lo mejor
escucháis ahí que va el... Así que a lo mejor lo podéis cambiar a on Save. ¿Vale? Por
defecto son Type. Vas escribiendo y te lo va diciendo. Vale. Entonces, si por lo que sea
no está aquí, pues sí que podéis crear... Podéis abrir este, que es el de los settings,
pero como JSON. Y aquí, en uno de los settings, vamos a encontrar este. Que para JavaScript,
porque podéis tener settings en Visual Studio Code por cada uno de los idiomas. ¿Vale?
Así que podemos utilizar este, JavaScript, y hacéis un Format on Save. ¿Qué pasa?
Que lo que va a hacer es formatear el archivo, pero vosotros le podéis decir qué formateador
es el que queréis utilizar. Pero ahora veréis aquí que estamos utilizando Prettier.
¿Por qué es esto? Porque la extensión de Prettier lo que va a hacer está configurado
de forma que va a ejecutar Prettier, pero también va a ejecutar el slint-fix.
Y lo va a hacer por vosotros. O sea, está integrado. ¿Vale? Así que en este caso
no os va a hacer el trabajo. Pero si no, si no utilizáis Prettier, por lo que sea,
pues tendríais que decirle que utilizase el slint. ¿Vale? Entonces, hasta aquí voy a guardar
los cambios. Ya me formatea esto. Ya veréis que yo siempre que guardo, pues me formatea
directamente todo y ya está. Y así no me tengo que preocupar. Entonces, importantísimo, ¿vale?
Hay que utilizar la extensión de slint en vuestro editor si queréis tener la integración
completa del linter en vuestros ficheros. Si no, no vais a ver ningún tipo de...
Uy, esto lo dejamos así, vacío. ¿Vale? No vais a ver ningún tipo de rayado
como lo vemos aquí. ¿Vale? Aquí podemos ver que me está diciendo React, tiene que estar
en el scope. Esto lo vamos a solucionar ahora. ¿Vale? Pero súper importante. Si no, no vais a ver
estas rayitas de aquí. ¿Vale? Si no lo tenéis la integración, tenéis que instalar la extensión.
A veces necesitar hacer un restart. ¿Vale? Pero tenéis que instalar la dependencia.
Tenéis que tener el slint.rc. Si no, también el slint.rc lo podéis tener dentro del package.json.
Bueno, aquí cada uno, esto va por gustos. Pero súper importante que al menos tengáis
el slint.rc o el package.json. Lo va a detectar si lo tenéis en cualquiera de los dos sitios.
Y una vez que tengáis eso, pues entonces ya sí deberíais ver cómo os enseña los errores.
¿Vale? Esto es súper importante. Dicho esto, ¿qué pasa? Que ya estamos viendo algunos errores
que a mí personalmente me están molestando. ¿No? Todos estos, por ejemplo, aquí hay dos
errores en este código. Uno, el que el onclick, las props, esta le faltan las validaciones de
las prop types. Y esto porque por defecto, que hemos utilizado estándar, que por cierto
no os lo he enseñado, pero tiene un montón, un montón de reglas por defecto. A ver, rules.
Bueno, tiene un montón de reglas. Por ejemplo, utiliza dos espacios, single quotes, que no puedes
utilizar variables sin usar, cosas así. Tiene un montón, un montón de reglas. Y especialmente
tiene algunas también para React. ¿Vale? También tiene su, digamos, el React style. ¿Vale?
Entonces, como utilizamos estándar y todo lo que tiene de slint, lo que vamos a hacer
aquí es que estos dos errores, el de las prop types, que lo tiene por defecto, y el de
React in JSX scope, los vamos a desactivar. Y os explico por qué. Lo primero, porque las
prop types, y tardaríamos demasiado en ponernos a hacer aquí prop types para
todos nuestros componentes. Y segundo, porque, bueno, creo que no es tan necesario. Si lo
queréis, este lo podéis dejar. Pero luego el otro, que es este, el de React in JSX scope,
es porque él espera que hagamos esto. ¿Vale? Import React from React. Si hago esto, desaparece.
¿Qué pasa? Que en Next.js, cómo funciona, es que este import te lo hace de gratis. Y solo
lo deberías utilizar cuando haces esto. ¿Vale? Cuando haces un user state o lo que sea.
Por lo tanto, como a mí no me gusta escribir código, ya sabéis que soy súper vago, ¿vale?
Y por eso no escribo puntos y coma. Pues entonces, en este caso, vamos a hacer que este error no
nos le dé más. Para eso, vamos a sobreescribir algo sobre las reglas. Aquí podemos ver un
poquito la configuración. Nos dice los environments, que serían los entornos en los que se ejecuta
este código, que es el navegador, es 2020 y Node. Luego, las configuraciones que extiende,
que es las recomendadas de Slin y el plugin de React. ¿Vale? Veo que no ha puesto la de
standard. A ver, esto es un poco raro, ¿eh? A ver si me lo he saltado. Cuando he hecho
aquí el SlinTint, ¿vale? Que le he dicho esto, JavaScript, React, ¿no? Y usa popular style,
le he dicho standard, ¿no? JavaScript. A ver, no, quiero instalar esto. A ver, a ver.
Es que veo que no me ha dejado ninguna de standard. Ahora sí. Vale, vale. No sé,
se le habrá ido, se le habrá ido, ¿vale? Con razón. Vale, ahora sí. Ahora sí que veo
plugin React recommended y standard. No la de SlinT, sino standard, que es lo que queremos
utilizar, ¿vale? Luego, el parser options. Esto es porque, ¿qué pasa? Que el parser de
SlinT puede soportar un montón de lenguajes, como por ejemplo, o sea, no solo hemos visto
que tiene soporte para TypeScript, pero también para JSX, que es lo que utilizamos en React.
Entonces, le tenemos que decir, oye, esta feature la tienes que activar. Le tenemos
que decir también qué versión de JavaScript utilizamos, en este caso la 11, pero quizás
quieres utilizar una menor, como la 6, o la que sea. En este caso, cuanto más, pues mejor,
seguramente, ¿no? Y el tipo de los módulos del import, si utilizamos un import, si hacemos
un módulo .export, al final esto también se lo podemos decir para que ayudara al parser.
El plugin, que es React, y aquí tendríamos las reglas. Ya tenemos un montón de reglas por
los plugins y el preset, ¿vale? Pero ¿qué pasa? Que las podemos sobreescribir. En este
caso, vamos a ver cómo se llama esta, que es la de React barra React in JSX Scope, ¿vale?
Pues lo que podemos hacer aquí es decirle, ¿vale? La regla de React, React, ¿cómo era?
React in JSX, eso, in JSX Scope, podemos decir que esta nos la desactiva. Y le ponemos aquí un
off, guardamos los cambios, ¿vale? Ahora se está volviendo loco porque tengo, se ha vuelto
loco por el otro, a ver. Ah, ahora se ha vuelto loco porque tengo las dos versiones. A ver,
creo que voy a tener que cerrar el linter. ¿Qué ha pasado? Que aquí, como antes en el otro
estándar, creo que se ha vuelto loco porque como he tenido que cambiar a estándar, el Slim
recommended no utiliza estándar. Entonces, mientras que me lo formatea con uno y lo guarda
con otro, seguramente se está volviendo loco. Este es el típico problema que te puede ocurrir.
Pues nada, vamos a ver. Voy a ver si soy capaz de volver a abrir mi proyecto. Ay, lo tenía
que haber cerrado del todo. A ver si así deja de volverse loco, ¿vale?
No, ahora me lo vuelvo a hacer. Y esto seguramente es porque Prettier se ha quedado con el otro
y ahora me ha dejado... Vale. Bueno, ahora me está haciendo esto, que me lo está formateando
de las dos formas. Lo que vamos a hacer, voy a desactivar por ahora Prettier, ¿vale?
Porque como no tenemos Prettier y a lo mejor tengo la extensión, esto es lo que os comento
que pasa con estas cosas, ¿vale? Es que... Pero claro, es que el tema es que como he hecho...
No, reload, recuerden. Como he utilizado primero el uno y luego el otro, pero antes me tenía que haber funcionado
bien. Bueno, vamos a hacer el format y ya está. Claro, ahora me dice que no tenemos esto y tal.
Bueno, ahora sí que funciona. Esto es lo que pasa y esto es una cosa que va a sentir bastante interesante
de que Prettier y el linter se pelean entre ellos, ¿no? Porque como hemos visto, el linter
también formatea tu código, ¿vale? Entonces ahora lo he solucionado porque he desactivado
Prettier, pero luego lo arreglaremos para que no se peleen entre ellos, porque si no, esto puede ser
bastante molesto, ¿vale? Entonces, vamos a volver a terminal. A ver si aquí me deja...
Vale. Y voy a volver a hacer esto más grande, ¿vale?
Entonces, por ahora lo que he hecho es desactivar. Ahora no me debería salir el error, ¿vale?
He desactivado uno de los dos. Yo os recomiendo... Bueno, esto es una tontería, ¿vale?
Pero yo lo que suelo tener, para no tener que acordarme, pues hacéis aquí esto y podéis
tener como un pequeño diccionario, ¿vale? Porque hay tres estados. Lo puedes desactivar, lo puedes
activar, pero para activar no es que lo tengas en on y ya está, sino que lo que tienes es
que sea un error o también puede ser que sea un warning, ¿vale? Entonces imaginemos que
yo quiero que alguna regla que me está molestando, en realidad quiero que sea un warning, ¿no?
O la quiero desactivar. Pues si la quiero desactivar, haríamos esto, rules.off y ya está.
Pero podríamos hacer .warn y al menos nos saldría como un warning en lugar de ser un error.
Así de esta forma en nuestros componentes, si vamos aquí, pues lo que vamos a ver es que
ahora nos dice que es un warning, ¿vale? Así que si hay alguna regla que por lo que
sea, pues os gustaría que no fuese un error, sino que fuese un warning, lo podéis hacer
también, ¿vale? Pero en este caso la desactivamos. Pero al menos ya tenemos eso preparado en el
caso de que queramos hacer cualquier cosa. También vamos a desactivar la de las proptypes,
¿vale? Que es la de react-proptypes. Aquí react-proptypes y esta también. Off.
Que si queréis utilizar proptypes, le dais caña, ¿eh? Vale. Pues ya tenemos esto. Entonces,
ahora que ya tenemos esto, la cosa interesante es decir, bueno, si ya tenemos esto y esto funciona
bien, porque realmente yo si pongo aquí, ¿ves? Ahí tenía un punto y coma. Si yo aquí
tengo un punto y coma y el slint trabaja por mí y me quita el punto y coma, por ejemplo,
si yo ahora guardo, pues desaparece. O si tengo aquí un montón de tabs, ya me avisa, ¿no? O sea,
el link no solo me está diciendo esto. ¿Qué pasa? Que efectivamente si yo pongo aquí una
constante, ya me dice, oye, esto es un error. Digamos entonces que nos está mirando dos
cosas, ¿vale? El estilo del código, pero también si hay errores en el código. Digamos que se preocupa
de que realmente el código funcione bien, ¿vale? Eso es bastante importante. Entonces, ¿qué
vamos a hacer ahora? Vamos a ver qué es Pretier, porque Pretier es un pelín, un pelín
diferente. Y es que Pretier le da igual tu código. O sea, le da igual que tu error
contenga errores. No le importa. Lo que quiere es ver si está bien formateado. Por ejemplo,
los espacios. Mientras que el linter podrías tener, si la variable no se está utilizando,
también tienes el máximo de caracteres que puede tener una línea. Y en el Pretier es
ese tipo de errores o reglas de las que se preocupa, del formateo del código, ¿vale?
Al final lo que hace es decir, vale, estás utilizando punto y coma o no, comillas o no.
Pero al final, si haces eso o no lo haces, en realidad tu código seguirá funcionando.
O sea, que lo que busca Pretier es que utilicemos el mismo estilo de código en todo nuestro proyecto.
Y esto es importante. ¿Por qué es importante? Pues porque resulta que Pretier, originalmente,
mira, voy a buscar por aquí una ISU que es bastante potente, ¿vale? De Pretier.
Vamos a ir primero a Pretier para que veáis un poquito la web. Que ya lo dice, ¿eh?
Es un formateador de código opinionado. O sea, que es subjetivo, tiene una opinión.
Es como estándar, ¿no? De Slint, que ya tiene como unas reglas básicas que dice,
oye, estas son las reglas y las podemos cambiar a mano, pero es bastante complejo.
Pero Pretier es lo mismo. Es un formateador de código que lo que busca es evitar las batallas de,
oye, esto debería ser así, esto así, punto y coma, no punto y coma.
La idea de Pretier es que lo instales y de una, pues ya esté tu código formateado, ¿vale?
Y no se discuta sobre el linter, sobre si tiene que funcionar de una forma u otra.
Entonces, eso sería Pretier. Y para que veáis, ¿no? Cómo llega esto, ¿no?
Esta idea de que es un formateador de código, que la idea es que no tenga configuración.
Pues aquí tenemos una ISU que es bastante mítica, porque es de hace tres años,
que era de Dan Abramov, donde explicaba esto, ¿no?
De que, oye, vais a tener mucha presión para añadir algún tipo de configuración, ¿vale?
Pero porque cada persona pues tiene su opinión, ¿no?
Por ejemplo, yo tengo la opinión de dos puntos y coma, y a lo mejor vosotros pues tenéis otro tipo de opinión, ¿no?
Pero claro, entonces dice, pero la idea es que no haya una configuración.
Porque la idea de Pretier es acabar con ese tipo de debate, ¿no?
De tener una configuración de semicolons o no semicolons.
Y de esto hablaba, ¿no? Decía, oye, no añadáis un archivo de configuración.
Acabad con eso, ¿sabes? Punto.
¿Por qué? Porque tú al final, la idea de Pretier es que tú pones un punto y coma,
y esto lo que haría, Pretier lo que haría es desaparecer.
O sea, borrar, formatearte el código y borrarlo.
Entonces tú puedes trabajar poniendo puntos y coma, pero Pretier te lo va a borrar.
Entonces, bueno, te lo va a borrar.
En este caso lo dejaría porque por defecto lo que hace Pretier es utilizar punto y coma, ¿sí?
Entonces, ¿cuál es exactamente la diferencia, vale?
Que me lo dice Gustavo, me pregunta, ¿no es lo mismo entonces?
Al final Slint también se preocupa por el formateo.
Y efectivamente, o sea, Slint es más grande, digamos, abarca más que Pretier, ¿vale?
Mientras que Slint se preocupa no solo por el formateo, sino también por tu código,
digamos que Pretier solo se preocupa por el formateo.
Pero ¿cuál es la diferencia, digamos, que tienen en el núcleo si los dos, digamos,
Slint también se preocupa por el formateo?
Y de hecho, si a mí me preguntaran si utilizaría Pretier hoy en día,
seguramente no lo utilizaría.
Tengo muchos proyectos en los que no lo utilizo, ¿vale?
Es una discusión interesante, ¿no?
Pero en mi caso, ya el linter hace lo suficiente para no tener que preocuparme yo también por el formateo.
Y los errores de formateo que puedo tener, los estilos de formateo,
ya el linter se preocupa por mí y me los arregla con el fix.
Entonces, ya no me tiene tanto sentido.
Pero entonces, ¿para qué existe Pretier?
Por dos motivos, ¿vale?
Lo primero, porque es bastante más rápido que el linter,
aunque esto es, o sea, no se nota.
No lo vas a notar en todos los proyectos.
Y lo segundo, es que la idea original, y por eso quería incidir en esto,
la idea original de Pretier es no tener configuración, ¿vale?
La idea original de Pretier es, oye, esto es como funciona, ¿vale?
Y ya está.
Y te va a formatear el código y esto es lo que hay.
Entonces, con esa idea original, contrasta un poco con el linter.
¿Por qué?
Porque el linter, en realidad, es solo una herramienta
en la que tú tienes que instalarle plugins y presets.
Y de esos plugins, presets y reglas, pues hay algunas que son de formateo,
otras de calidad del código y tal, pero al final son esos presets
y esos plugins y tus reglas las que deciden cuál es el estilo
en el que va a trabajar, digamos, pues el equipo.
En este caso de Pretier, la idea, que se supone, la idea,
es que no haya una configuración.
La idea de Pretier es, no, no, yo solo me preocupo
porque tu código esté bien formateado y haga lo que tiene que hacer
y ya está, ¿vale?
O sea, formatear el código.
O sea, que podríamos decir que es un subset del linter, del slint,
pero con unas reglas que buscan ser ya cerradas, ¿vale?
Aunque se pueden configurar, y de hecho podemos buscar,
pero estoy seguro que la documentación nos van a decir,
oye, lo puedes configurar, pero no es la idea, ¿vale?
Porque de hecho, pues ha habido muchas veces que han intentado quitarlo
y no nos extrañaría, no te extrañe, ¿vale?
Que lo vaya a quitar.
Así que, a ver, mira, es que está clarísimo esto.
La filosofía detrás del option, del tener opciones, ¿no?
Dice, Pretier tiene algunas opciones por temas históricos, ¿vale?
Pero no queremos más de ellas, ¿vale?
Y seguramente no me extrañaría que en algún momento decidan quitarlas.
Pero qué pasa, que esto va a ser difícil llevarlo atrás, ¿no?
Pero la idea era no generar debates, ¿vale?
No sé si con esto ha quedado claro, pero es importante esta diferenciación, ¿vale?
Podrías quedarte con el linter y ser feliz con el linter,
y yo de hecho muchas veces soy feliz con el linter, ¿vale?
Pero Pretier lo que busca es ser un formateador de código.
Para formatear el código le da igual si tu código tiene bugs o no tiene bugs,
lo único que hace es formatearlo para que todo siga el mismo estilo.
Y además lo que busca es que sea totalmente cerrado ese estilo.
Que lo puedes configurar y ahora lo veremos, pero importante, que no le interesa.
Estuvo muy abandonado, os voy a parar un momento y os leo, ¿vale?
Vamos aquí, ¡pam!
Vale, así que el default del linter no va conmigo.
Pues puede ser de...
Ah, el de Pretier.
Bueno, lo podéis ver cuáles son los defaults.
Por ejemplo, tiene semicolons, creo que son 80 caracteres por línea,
creo que solo utiliza comillas simples.
No, utiliza comillas dobles.
Claro, por ejemplo, en mi caso son totalmente contrarios a los que yo utilizo en estándar, ¿vale?
Entonces es un poco raro.
¿Qué más?
Miguel pregunta,
¿Estos dos plugins sirven de la misma forma en React Native?
Sí, porque puedes utilizar todo esto que hemos visto.
De hecho, incluso la configuración de React la puedes utilizar en React Native.
Y tanto Pretier como es Lint, como es JavaScript, no vas a tener ningún tipo de problema, ¿vale?
Joseph Romero se ha quedado con la duda de por qué no importo la librería de React.
Y el tema, Joseph, es que NextYes, que es el framework que estamos utilizando para nuestra app de Twitter,
el tema es que está haciendo ese import automáticamente.
Cuando detecta que un archivo tiene la palabra clave React, ¿no?
Y además que en JSX lo que hacemos es un React.createlement,
lo que está haciendo NextYes es importarlo por nosotros.
Y de esta forma no tenemos que estar repitiendo constantemente el import en todos nuestros ficheros.
Por eso no lo hemos hecho, ¿vale?
Entonces, ¿vale? Creo que más o menos...
Alguien preguntaba sobre lo del menos D, también Pupi Martí ha hablado de esto.
Y efectivamente lo único que hace el menos D es instalarlo como un script o una dependencia
que tiene que estar en el Depth Dependencies.
¿Y por qué esto es importante?
¿Por qué? ¿Por qué hacemos esta diferenciación, no?
O sea, si vamos aquí y miramos esto, ¿por qué es importante que esté en las Depth Dependencies?
Si tenemos aquí dependencias y Depth Dependencies, ¿cuál es la diferencia?
Vale, la diferencia que habría que leerlo así.
Estas, digamos, que son las dependencias que necesita nuestro proyecto para funcionar, ¿no?
Cuando se ejecuta, ¿qué dependencia necesita que existan en ese proyecto?
Pues estas.
Y las que necesitamos, pero solo para desarrollo.
¿Por qué es importante esto?
Pues esto es importante porque si estamos en un deploy, por ejemplo,
en algún tema de un deploy o algunos CIs o lo que sea,
muchas veces lo que podemos hacer es que nuestro deploy vaya más rápido
si solo instala las dependencias que necesita.
Esto sería un ejemplo.
¿Por qué? Porque no vamos a pasar el linter a lo mejor en el deploy.
A lo mejor no lo necesitamos, ya lo hemos pasado antes, ¿vale?
Pues eso sería un poco el tema, ¿vale?
Vale, creo que más o menos he leído por ahí las cosas que me habéis ido comentando, ¿vale?
Aumenta, buen día, realizar el import, me dicen por aquí,
el import de React, sabiendo que ya Next lo hace, ¿aumenta el tamaño del build?
No, es bastante lo mismo.
Aunque el de NextDS sí que es verdad que utiliza el import optimizado,
que es este, pero al final no lo utiliza nadie, ¿no?
Que es import all from React, ¿vale?
Al final el tema es, bueno, esto...
¿Esto import as React? ¿Puede ser?
¿Queda esto? Sí.
Es un import ligeramente distinto, ¿vale?
Y que no utiliza mucha gente.
Y esto, lo que pasa es que React todavía no está bien optimizado
para que esto funcione como debería.
Pero esta debería ser la forma más correcta de hacerlo
si queremos hacer tree shaking y que no acaben en el bundle,
cosas que no utiliza React, o sea, no utilizamos en nuestra aplicación.
Pero yo creo que ahora mismo no pasa nada si tú haces un import React,
from React, va a ser el bundle, va a ser exactamente el mismo.
O sea, no estoy...
No pondría la mano en fuego, pero estoy bastante seguro.
No creo que haya hecho ningún tipo de diferencia, ¿vale?
Alguien pregunta a Ferdinand, dice,
Oye, ¿y qué diferencia existe con las peer dependencies?
Vale, pues tenemos tres, ¿no?
Dependencias, que necesita el código para funcionar,
o sea, la aplicación para funcionar o nuestro proyecto para funcionar.
Dependencies, las que necesitamos para desarrollar.
Peer dependencies, dependencias que damos por hecho
que van a estar en el proyecto.
¿Por qué? Porque a lo mejor tenemos este proyecto
que es un componente, ¿no?
Y lo publicamos.
Si es un componente de React, ¿cuál será una peer dependency?
React. ¿Por qué?
Porque ese componente solo se puede utilizar
en una aplicación que es de React.
Por lo tanto, sería una peer dependency.
¿Y por qué hacemos que sea una peer dependency?
Porque imagínate que si tú creas un componente botón, ¿vale?
Un botón fantástico, maravilloso.
Pero lo quieres utilizar en una aplicación, ¿no?
Lo haces de código abierto y la gente se lo va instalando, ¿no?
¿Qué pasa?
Pues el problema es que si tú pones como dependencia React,
tú instalarás una versión en concreto de React,
a no ser que pongas que es con una mayor o un asterisco,
lo cual es peligroso, ¿vale?
Lo mejor, lo correcto,
es pensar que ese componente tiene como peer dependency,
tiene React, ¿vale?
Porque él no tiene sentido que tenga esa dependencia React,
porque no se puede utilizar sin esa dependencia.
Tiene que utilizarse en un proyecto que tenga esa dependencia.
Eso sería una peer dependency, ¿vale?
Sobre el tree shaking, que me preguntan por aquí,
ya os haré algún día un vídeo, ¿vale?
Un vídeo para comentaros,
porque si no, si me pongo a explicar qué es el tree shaking aquí,
no terminamos ahí.
Vale, entonces, ¿qué pasa?
Como os he comentado y como habéis visto perfectamente,
se pelean, ¿no?
Slint y Prettier se pelean,
porque como hemos dicho, Slint a veces pisa Prettier,
porque si instalamos Prettier,
claro, Prettier es el que se encarga del formateo,
pero si las reglas de Prettier no encajan con las reglas del linter,
locurón.
Bueno, entonces, ¿qué se tiene que hacer para evitar esa pelea?
Lo primero que tenemos que hacer es instalar una configuración especial de Slint, ¿vale?
Que es, si no me equivoco, es Slint Prettier, ¿vale?
Slint Config Prettier.
Y dije, menos de, que no se nos olvide, ¿vale?
Voy a hacer esto todavía más pequeño, ¿vale?
Y vamos a ver cómo utilizamos esto.
Tenemos que asegurarnos que esta configuración la añadimos en el Slint
y lo que vamos a hacer es que sea la última, ¿vale?
Si tenemos aquí el plugin de React y aquí tenemos Standard,
que es la que tiene un montón de standards,
este preset que os he comentado, que no tiene punto y coma y tal,
la última que tenemos que poner es la que acabamos de instalar,
que es la de Prettier, ¿vale?
Ponemos Prettier, aunque hemos instalado Slint Config Prettier,
porque ya lo detecta así, ¿vale?
Es automáticamente igual que Standard,
a lo mejor es Slint Config Standard,
pues lo mismo, lo detecta automáticamente.
Aquí ponemos Prettier y de esta forma vamos a importar esas reglas,
que lo que hacen estas reglas es que va a desactivar todas las reglas del linter
que se vayan a pelear con las de Prettier.
Por ejemplo, todas las que sean puntos y coma y cosas así.
De hecho, si todo ha ido bien y no se ha vuelto más loco,
si tenemos ahora esto que decíamos que poníamos esto así,
vale, podemos ver...
Ahora lo vamos a ver clarísimo.
Yo ahora he puesto unos cuantos tabs
y podemos ver que no me está enseñando el error.
Ahora se me lo está formateando,
no sé muy bien por qué, pero esto debe ser otra cosa.
Pero el error, el error que me mostraba antes,
no lo está haciendo.
Esto es el Prettier este, ¿no?
Que lo ha desactivado.
Si guardamos esto y yo ahora hago esto,
ahora vemos que tenemos el error de los tabs.
Pero ¿qué es lo que está pasando aquí?
Que básicamente está diciendo,
vale, voy a mirar si está haciendo bien la indentación.
Eso es el Slint.
Pero ¿qué pasa?
Que el Prettier es el que se preocupa de la indentación también.
Por lo tanto, si tenemos configuraciones diferentes,
se pueden pelear.
En este caso lo que hacemos es añadir Prettier, ¿vale?
Esta configuración de Prettier, guardamos los cambios
y ahora ya no tenemos este error.
Porque es como que hemos desactivado.
Lo que hace esta configuración, básicamente,
es lo que hemos hecho nosotros aquí,
pero lo que hace es, vale, el indent desactivado.
Y así con todo lo que son de formatear.
De esta forma, el Prettier es el que, digamos,
tiene ahora la responsabilidad de hacer eso, ¿vale?
Así que vamos a dejar esto por aquí.
Vamos a guardar esto, que lo he dejado con el Prettier.
Perfecto.
Entonces, ahora lo que tenemos que hacer es añadir Prettier.
Vamos a añadir Prettier y también con el menos D,
que no se nos olvide, ¿vale?
Ahora, ¿para qué funcione Prettier?
Vamos a ver si soy capaz de, entre todo,
que funcione Prettier.
Que a lo mejor la he liado con el tema de configuración que he tocado y tal.
Pero bueno, si no, pues poco a poco y con calma.
Lo primero que hay que hacer para que funcione Prettier,
igual que antes hemos creado el slint rc.js,
lo primero que habría que hacer, de la misma forma,
es tener un archivo de configuración de Prettier,
que en este caso puede ser prettierrc.json.
Creo que hay diferentes.
Está prettierrc.json, prettierconfig.
Creo que está el .js, también podríamos hacer lo que fuese,
mira, prettier.config.js.
Al final puede ser una key en tu package.json,
puede ser un prettierrc.json, que es el que he utilizado yo,
aunque podría ser un prettierrc.js.
Al final tienes un montón de opciones, ¿vale?
Lo importante es que exista.
Aunque sea vacío, porque de esta forma el editor,
cuando tenga la extensión, lo detectará, ¿vale?
Entonces, lo que vamos a hacer ahora,
porque lo habéis instalado antes,
es instalar la extensión de prettierr.
Vale, de hecho la tengo, pero la tengo desactivada.
Lo mismo que antes, ¿vale?
La extensión en este caso, a ver, en este caso,
yo ya podría ejecutar, como hemos dicho antes, prettierr.
Podría hacer prettierr, y aquí creo que es punto,
y hacer guión guión check, solo para que nos diga los errores.
Vale, además aquí hemos visto,
he visto ya una cosa que es interesante.
Vale, ahora está haciendo un chequeo de todo,
pero como podéis ver, ha entrado en la carpeta punto next, ¿vale?
O sea, locurón, ha entrado en la carpeta punto next,
y esto, con todo el tema de la caché, pues se puede tardar la vida.
Así que voy a aprovechar, y antes de hacer esto y de seguir,
vamos a añadir otro archivo, que es el prettierignore,
si no me he confundido, prettierignore, creo que es esto,
y aquí le podemos decir las carpetas y los archivos que tiene que ignorar.
Pues le decimos, creo que node modules la ignora por defecto,
tiene sentido, pero aquí le vamos a decir el punto next, ¿vale?
Para que no, ahora no nos mire el formateo de esos archivos.
Así que hacemos npx prettier, por lo que hemos dicho antes,
guión guión check, y ahora sí nos ha mirado los archivos que queríamos.
Entonces, nos ha dicho que ha encontrado algunos errores,
pues lo que podemos hacer es un guión guión write.
¿Por qué? Porque el write es como el fix del linter.
Y ahora lo que va a hacer es cambiar los que están mal formateados,
y podemos entrar a ver qué es lo que nos ha hecho.
Si vamos al botón, pues vamos a ver aquí que nos ha puesto un punto y coma,
y nos ha arreglado los saltos de línea y lo que sea, ¿vale?
Entonces, con esto nos funcionaría, pero obviamente nos gustaría tener
mejor integrada la experiencia para el desarrollo, ¿no?
Lo que vamos a hacer para eso es instalar la extensión, aquí,
vamos aquí a la extensión a la izquierda, aquí, y buscamos prettier.
Vale, es esta, que ya la tengo instalada, pero la tengo desactivada.
La voy a activar ahora, ¿vale? Ahora la tengo activada.
El problema muchas veces es que cuando se activa, se desactiva,
pues se puede volver loco.
Pero una cosa sí que os recomiendo, ¿vale?
Hay un montón de extensiones que se llaman prettier,
que se parecen, que no sé qué.
Por ejemplo, aquí tenéis esta, y más abajo, que no sé si lo estoy tapando,
pero más abajo tenéis esta, que se llama exactamente igual, ¿vale?
Tened cuidado, porque puede ser una versión que no está ya mantenida.
Puede ser alguien que ha creado esa extensión porque hay algo que no le gustaba
y la ha dejado por ahí tirada.
Entonces, instalaos la que veáis, si tiene 7 millones de descargas,
será por algo.
Luego, evitad también las que sean así de prettier con estándar.
¿Por qué?
Porque si estáis en un proyecto que no usa estándar,
la podéis liar muy parda, ¿vale?
Entonces, esta, que es la oficial, es la que hemos instalado, ¿vale?
Y ahora ya aquí nos indica un poco cómo la tendríamos que configurar y todo esto.
¿Vale?
Ya nos dice aquí cuál es el formate que antes he quitado.
Y os voy a...
Ya nos da aquí un poco la configuración también que deberíamos utilizar,
que si entramos, la configuración con comando coma,
entráis directamente a la configuración.
Si no, si queréis entrar a la de JSON,
es, podéis hacer mayúscula, comando P,
y así podéis buscar open settings,
y aquí es esta, la de JSON, ¿vale?
Vamos a comprobar cuál es el formate que estamos utilizando,
porque de esta forma podremos hacer que utilicen prettier,
nada más darle al save lo que queríamos hacer antes, ¿vale?
Entonces, vamos al JavaScript, que está aquí, ¿vale?
Y aquí podemos ver que el formateador por defecto es el de Visual Studio Code
y no sé qué, no sé cuánto.
Este no es el que queremos utilizar.
El que queremos utilizar es el de prettier.
Y antes, a ver si puedo volver...
Vale.
No puedo volver, pero os lo enseño otra vez.
Aquí con la extensión ya os chiva un poco cuál es el formate, ¿vale?
Os dice, oye, asegúrate que estás utilizando este formateador
y no el que viene por defecto.
Así que vamos a hacer esto, ¿vale?
Vamos a añadir el prettier VS Code, ¿vale?
Y aquí, que estamos utilizando por defecto este, ¿vale?
Para JavaScript, lo que vamos a hacer es cambiarlo
y vamos a poner el...
¡Ay! No lo he copiado.
No lo he copiado.
Un momento.
Que con la prisa...
Vale.
El formateador es este.
A ver si ahora sí que lo copio.
A ver si es que a lo mejor no...
Vale.
No, es que no se copia.
No se copia ahí dentro el...
No se copia.
Bueno, es remp.prettier...
No sé si tendrá autocompletado.
O no sé si soy yo que...
Sí, ahora sí.
Vamos a probar si tiene autocompletado.
Yo creo que sí.
Que a veces...
A ver.
No.
Es...
No.
Pensaba que sí.
Bueno, no tiene...
Si escribo de primeras parece que no tiene.
Ahora sí.
Vale.
Hay que quitar las comillas y todo.
Pues si quitas las comillas y empiezas a escribir ahí,
pues ESBENP y hay prettier VS Code y tal.
Vale.
Pues ahora sí.
Entonces vamos a guardar los cambios y a ver, a ver qué es lo que ha pasado por aquí.
En algún momento algo ha pasado aquí que he cambiado la configuración sin querer y por eso me está dando los problemas antes.
Espero que ahora no me vuelva problemas y si no, bueno, ya veremos cómo lo solucionamos.
Vale.
Voy a cerrar esto y vamos a ver si ahora sí que nos formatea bien el código.
Vamos aquí al botón, por ejemplo, y si esto voy haciendo así, vale.
Ahora sí que me lo está haciendo bien.
Y ahora si pongo aquí un punto y coma, si no pongo punto y coma y guardo, pues podemos ver que prettier me lo añade.
Claro, si yo digo, oye, no, es que yo quiero que... no quiero utilizar punto y coma.
Podríamos en el prettier rc.json, podríamos decirle, aquí hay diferentes configuraciones.
Si ponemos las comillas, ya nos dicen todas las configuraciones que hay.
Y la de semicolons, por ejemplo, es la de semi.
Pues le decimos en lugar de true, que es el valor por defecto, le decimos false.
Ahora guardamos los cambios, vamos aquí y ahora si guardo, vale.
Pues aquí podemos ver que me ha quitado el punto y coma.
De hecho, podemos poner un montón y volvernos locos.
Y nos los quita a todos, ¿vale?
O sea, cuando guardes, te los quita.
Es mucho más cómodo mientras vas trabajando y guardas, ¿no?
Que te lo quita automáticamente.
Pero imaginemos que por lo que sea, pues hemos dicho, oye, claro, esto está muy bien, pero ¿qué pasa?
Si hay alguien que por lo que sea no tiene esta configuración, ¿vale?
Una cosa antes de continuar.
Que hay gente que esto no le gusta, ¿vale?
Pero yo os lo digo para que si no queréis que al guardar os haga esto, pues este editor format on save le ponéis un false, ¿vale?
Aquí en este le ponéis un false y de esta forma, pues debería dejar de funcionar, ¿vale?
Vamos a probarlo, a ver si ya ha funcionado.
Igual me deja aquí súper mal.
No, vale.
¿Ves?
Ahora estoy guardando y por más que guardo, no me lo quita.
Si por lo que sea no os gusta, a mí me encanta, ¿no?
Porque es súper instantáneo, lo quita y ya está.
Pero si por lo que sea molesta, pues lo podéis desactivar.
Que lo sepáis, que no estéis obligados.
Ahora he lo puesto true, ahora sí que funciona.
Y lo importante, ¿vale?
Es esto.
Es el tema de que hemos hecho que el linter y el prettier se lleven bien.
Y es tan sencillo como instalar el slint config, slint config prettier, ¿vale?
Que es este de aquí.
Es esta de aquí.
No instaléis otras cosas.
No instalar, os quiero decir, si queréis que el linter y el prettier se lleven bien y queréis ir actualizándolo constantemente y tal, no hagáis inventos.
No, por ejemplo, a mí me encanta estándar, ¿vale?
Pues hay un proyecto que se llama prettier estándar.
Vale, prettier estándar.
¿Qué pasa con prettier estándar?
Uno, se llama prettier estándar y por debajo no usa prettier.
Utiza prettier X.
Cagada.
¿Por qué?
Porque a lo mejor no funciona tan bien con el editor.
Y tú dices, ¿por qué no me funciona?
¿Qué está pasando?
No sé qué.
Entonces ya no es exactamente lo mismo, ya tienes que hacer cambios, no sé qué.
Entonces, no lo hagáis.
Segundo, hay también slim plugin prettier.
Vale, un plugin de prettier y no sé qué.
No lo uséis.
Sé que tiene muchas estrellitas y tal, pero sé que me he tardado un montón de tiempo porque quería explicaros claramente cada uno de los pasos.
O sea, yo cuando me pongo a instalar todo esto, a lo mejor estoy cinco minutos, pero quería explicaros todos los pasos para que tengáis clarísimo qué es cada cosa, qué significa cada cosa,
por qué da problemas en slim completer, cómo lo tenéis que instalar correctamente, qué problemas os podéis encontrar, el tema de instalar las extensiones, ¿vale?
Quería ser súper claro para que lo tengáis cristalino porque veo que hay gente que tiene muchísimos problemas,
qué hace prettier, qué hace slim, por qué esto, por qué lo otro, por qué se pelean entre ellos, por qué cuando guardo que me ha pasado, ¿no?
Y lo habéis visto, ¿no?
Que se han peleado durante un momento.
¿Por qué no logro que funcione?
Pues porque a lo mejor instala el slim prettier este que hace cosas muy raras.
Hay uno que utiliza la configuración de prettier para que sea el linter el que hace, tampoco, ¿vale?
Si quieres utilizar el slim con prettier, utiliza el slim config prettier, desactivas todas las reglas del link que sean de formateo y utilizas prettier.
Ya está.
Y a ver, sé que hemos estado un ratito, a ver, una hora.
De hecho, mira, ya tengo aquí uno que dice, tan sencillo, que lleva como media hora.
Es verdad, es verdad, pero quería ser súper claro, ¿vale?
En todas las cosas que hemos comentado para que esto os quede cristalino, ¿vale?
Y creo que valía la pena.
Luego, para terminar, hay veces que hay gente que no tiene, o sea, no podemos de alguna forma asegurar o...
No podemos depender de que los usuarios, los desarrolladores, tengan en el editor las configuraciones, ¿no?
Y que cuando guardan el archivo, pues todo funcione bien.
Tenemos que tener como algún tipo de control de que antes de comitear ese archivo, está pasando tanto el linter como el prettier.
Entonces, hay un montón de estrategias, pero un montón, ¿eh?
O sea, y casi todas son utilizando husky, pero hay gente que lo hace a mano, hay un montón.
Pero bueno, yo os recomiendo la que a mí me gusta bastante.
¿Por qué?
Porque solo hace lint y prettier de los archivos que has tocado, bastante rápido, la configuración es cero, o te añade la configuración automáticamente.
También utiliza husky, que está de sobra demostrado que va muy bien.
Y a mí me gusta.
Es esta, de lint stage, que creo que además es la que está recomendada por prettier, ¿eh?
Entonces, ¿cómo se instala?
Súper fácil.
Es npx mrm lint stage.
Os explico esto, que es un poco raro, y no os quiero decir, copia y pega, ya está.
Y a lo mejor esto se pone a minar bitcoins y luego me venís a buscar a casa.
A ver, os cuento.
npx es el comando que hemos hablado antes.
mrm, esto es un paquete de GitHub, que es de código abierto totalmente, que lo que está preparado para modificar rápidamente los package.js y tal.
Entonces, como también funciona con presets, lo que está haciendo esto es, vale, haz la configuración.
Esto es, llama al mrm y utiliza el preset de lint stage.
Y el lint stage lo que hace es configurar el package.json para añadirte todos los scripts y ponerte husky y todo esto, ¿vale?
O sea, para que lo sepáis, que es un poco raro, pero que es todo de código abierto, lo podríais ver y no hace nada fuera de lo normal.
Entonces, para añadir esta funcionalidad, lo que vamos a hacer aquí simplemente es ejecutar esto, npx mrm lint stage.
Lo ejecutamos y esto también tampoco debería tardar mucho, pero lo que vamos a ver es que nos va a modificar el package.json, ¿vale?
Nos va a hacer unos cambios en el package.json que nos va a añadir esta funcionalidad que cuando vayamos a comitear, automáticamente va a pasarle tanto el linter como pretier.
Y además lo va a hacer en el orden correcto, porque claro, ¿qué pasa?
Que si tú primero formateas y luego le pasas el linter, también, o sea, lo va a hacer en el formato correcto, que primero es el pretier y luego es el slint, ¿vale?
Así que vamos a ver si esto termina y mientras, antes de ver esto, voy a veros y porque me he quedado, es que había un momento que habéis hablado un montón y se me ha quedado ahí.
Vale, a ver, al final los Nios no me ha quedado claro que era, no sé si alguien me lo ha chivado por ahí, pero me he quedado con las ganas de saberlo.
No sé si alguien lo ha puesto, ¿vale? Si alguien lo ha puesto, pues lo agradezco.
Luego, Jonas Pro, que me ha dado 39 pesos mexicanos, ¿vale? Me voy a prender las modelas.
Un saludo, crack, y buen viaje mañana. Muchas gracias, Jonas. Me voy cerquita, la verdad, me voy cerquita, pero tengo muchas ganas porque, bueno, me entran ganas ya de estar en la playita.
Pero bueno, quería estar esta noche con vosotros.
Sergio Serrano, que no falla, no falla, no falla ni una, ¿eh?
Ten un buen directo, crack. Este toca haberlo resubido. Muchas gracias, Sergio. Espero que te haya compensado y que te haya gustado.
No hace por acá. Agustina Prats, había dicho la profe por aquí.
¿Qué más? ¿Qué más? Vale. Bueno. Ah, mira que tengo por aquí. Madre mía. Madre mía.
José María Lamela, 5 euros y dice, ahí va mi aportación para los mojitos.
Mil gracias por tus clases, es un lujo. El lujo es teneros a vosotros y tener esta comunidad tan brutal.
Muchísimas gracias, José María. Te prometo que me tomo un mojito a tu salud. Está claro, ¿eh?
Alguien preguntaba por aquí, alguien decía, ta, ta, ta.
Alguien preguntaba por un libro, SurfDev, un libro de React que recomiendo para un principiante.
El mío, que sale en septiembre, ¿vale? Estoy escribiendo un libro de React.
Os voy a enseñar la... a ver si soy capaz.
Os voy a enseñar la portada, a ver qué os parece. Y me comentáis qué os parece también, ¿vale?
A ver. Ta, ta, ta. Sí. Ahora lo enseño. Vale. Pues mira, os enseño la portada. A ver qué os parece.
Esta es la portada. Aprende React paso a paso y con ejemplos prácticos.
Pues esto. No sé qué os parece, pero no está todavía la venta. Ya os digo, spoiler.
Creo que vamos a intentar hacer preventa por 10 dólares. Puede ser. Y luego que saldrá por 15 dólares.
Pero la preventa será mejor que está al 80%, 70%, lo pondré a la venta.
Y luego, pues la gente que ya lo compre cuando sea este completo, pues nada, ya será al precio completo.
Y es sobre React, pero va a ser también, me gustaría, pues, bueno, como hago los live y tal,
pues un poco explicando el por qué, para que tengáis muy claro cómo funcionan las cosas por detrás.
Copia esto, haz esto. De hecho, también habrá ejemplos prácticos para que lo hagáis vosotros también, ¿vale?
Para, yo qué sé, para ver cómo funciona algo, que lo comprobéis.
Habrá un repositorio donde tendremos todos los ejemplos y tal.
Y esto soy yo, pues, anunciando el live de hoy. Así que si no me seguís en Instagram,
ya sabéis que os estáis perdiendo un montón de cosas, como los retos de JavaScript que voy poniendo,
que estuvo muy divertido el otro día, ¿vale? Así que, bueno, espero que esto se haya instalado.
Vamos a ver. Esto ha instalado un montón de cosas. Si vamos al Package.json, ¿vale?
Vamos aquí al Package.json. Vale, ya veo que nos ha instalado Husky, LintStage,
nos ha puesto este, Husky, Hooks, que esto lo que dice básicamente es, vale,
cuando haces un pre-commit ejecuta el LintStage. Y el LintStage lo que va a hacer es mirarnos
todos los archivos JavaScript y todos los CSS y MD con Pre-tier, ¿vale?
Y va a utilizar la caché para el Lint y nos va a hacer el fix, o sea que lo va a hacer bien.
De esta forma, ahora, si yo intentase, vamos a poner aquí, add LintStage and Pre-tier,
add LintStage and Pre-tier and more, ¿vale? Creo una nueva, ¿no?
Y por lo que sea, voy a intentar poner un error para que no me haga el commit.
const a, hola. Y no utilizamos esta constante, ¿vale?
Lo que vamos a hacer es intentar hacer un commit, try commit, y ahora que va a hacer el commit,
bueno, claro, no he hecho un git add, que también ayuda, ¿eh? Git, bueno.
Vamos a añadir todos los archivos. El ga es git add all, ¿vale?
Y vamos a hacer el commit ahora. Entonces, ya podéis ver que intento hacer el commit y está haciendo el pre-commit,
está pasando el linter, y cuando le ha pasado el linter, ha fallado.
Y ha fallado justo por el error ese que he puesto, de que hay una constante, pero no está abusándose nunca ese valor.
Y de esta forma, te aseguras que en un equipo, en tu proyecto, pues la gente, pues,
está utilizando bien el linter y el pre-tier y no está subiendo código al repositorio que no esté validado de alguna forma, ¿vale?
Así que con esto yo creo que ya podemos dejar el tema del linter y pre-tier.
Si tenéis alguna pregunta, me la dejáis en el chat, que voy a intentar estar pendiente, ¿vale?
Y voy a quitar esto, que tampoco tiene mucho sentido, pero lo importante es que ya tenemos pre-tier linter bien configurado,
como debe ser, ¿vale? No con cosas raras.
Si a mí me preguntan, y me preguntan, oye, pero tú cómo lo haces para tus proyectos, ¿vale?
Y de hecho lo he hecho en algún vídeo, creo.
Yo utilizo directamente standard.js, porque ya viene con el linter, ya viene con toda la configuración,
y yo no utilizo pre-tier como tal.
Entonces yo utilizo, yo instalo standard.js y con esto ya tiro.
O sea, yo es que hago las instalaciones, las hago súper rápido,
pero creo que en muchos proyectos, pues, la gente utiliza pre-tier linter
y era para que sepáis un poco cómo se debería utilizar, ¿vale?
Y cómo se debería utilizar bien y entendiendo bien cómo funciona cada cosa.
Vamos a meter en el gitignore, ahora que he visto esto,
este slint caché, que no lo vamos a necesitar, ¿vale?
Antes de liarla.
Y el yarn lock, bueno, se lo vamos a dejar, ¿vale?
El punto next, a ver, este sí que lo hemos puesto, vale.
Perfecto.
Pues hasta aquí tenemos todo el tema del linter y tal.
Si os parece, vamos a hacer cositas rápido,
porque hay gente que me ha comentado que, bueno, ¿qué pasa?
Ahora, cuando se inicializa un proyecto con Next.js,
me lo habéis dicho muchos, ¿eh?
Me lo habéis dicho por mail, por Twitter, por YouTube,
en los comentarios y tal.
Ahora, cuando se inicializa un proyecto de Next.js,
ya no utiliza style.js.
Style.js era esto, ¿no?
Lo que utilizamos.
Ahora utiliza CSS Modules por defecto.
Este cambio, que viene desde la 9.5,
y nosotros cuando empezamos el proyecto estamos en la 9.4,
esto es un cambio reciente, pero el tema es que lo han hecho
básicamente porque mucha gente no conocía style.js.
Y CSS Modules, digamos que tiene mayor adopción.
Y de esta forma, la curva de aprendizaje para empezar es más pequeña.
Así que nosotros vamos a seguir utilizando style.js
porque a mí personalmente me parece bastante potente
y ya que lo hemos utilizado, pues lo seguiremos utilizando.
Pero solo para que veáis que esto ya funcionaba antes, ¿eh?
Desde la 9.4, o sea,
desde antes ya se podía utilizar CSS Modules.
Pero solo que veáis que esto existe, pues vamos a...
¿Es era Modul o Modules?
Modul, perdón.
Que he puesto aquí Modules y es Modul.
Para que veáis que esto funciona,
por si queréis seguir a 7 proyectos con CSS
o queréis utilizar el style.js o utilizar los dos, ¿vale?
Que es lo bueno, que podéis utilizar los dos,
como vamos a hacer aquí.
Entonces, como tenemos este avatar aquí,
que es horrible, así, todo cuadrado y tal,
pues lo que vamos a hacer rápidamente
es añadir un nuevo componente
que le podamos pasar esto.
Le podamos pasar la imagen, ¿no?
Y esto tenga el alt, esto tenga el source
y, bueno, vamos a poner que title sea el alt, ¿vale?
Básicamente vamos a hacer que ese avatar
pues tenga mejor vida o mejor pinta.
Vamos a importar los estilos, esto de styles from styles.module.css
y así vamos a hacer los estilos con CSS Modules.
Vamos a hacer algo sencillo, ¿no?
Border radius con 999, width, vamos a poner 49
porque creo 49 es justo la medida que tienen en Twitter,
así que vamos a probar esto, ¿vale?
Y ahora para utilizar los CSS Modules
solo tenemos que añadir aquí un class name
y decirle styles punto
y poner el nombre de la clase que hemos creado,
punto avatar en este caso.
Así que esto por aquí, esto por acá,
a ver, que esto no me lo ha recargado,
no sé si se ha vuelto...
Ah, no sé, ¿cómo lo va a recargar?
Si todavía no estoy utilizando el avatar.
Vale, ahora vamos a utilizar el avatar.
Estoy diciendo, pero ya está ahí.
No, no, no, que no lo estamos utilizando.
En la página home, que la teníamos aquí, en index,
bueno, el index es como la página raíz directamente.
Aquí teníamos la imagen.
Pues ahora vamos a utilizar el avatar.
Le doy a enter aquí para que me lo copie.
Esto, ¿dónde me lo ha dejado?
Aquí, ¿vale?
Avatar.
Y ya así de esta forma podemos...
Ahora está esperando que le pasemos otra cosa, ¿vale?
Vamos a poner esto un poquito más aquí.
Vale.
Aquí nos está diciendo, ¿por qué se queja avatar, no?
Pues esto es un tema de TypeScript,
de la integración que tiene TypeScript con Visual Studio Code.
¿Vale?
Este error que vemos aquí,
esto no tiene nada que ver con el linter,
ni tiene que ver con Prettier, ¿vale?
Este error lo que nos dice es que
ha detectado que esta función tiene un alt y un source,
y aquí en cambio solo estamos pasando un source.
Entonces le dice, oye, te está faltando la prop type del alt, ¿no?
Y no me has dicho ni que sea opcional, ni tiene un valor por defecto.
¿Qué está pasando aquí?
Entonces, en cuanto se la pasemos,
creo que user a display name.
A ver, creo que en client...
Username.
Vale.
Username.
Ah, de hecho, de hecho lo tengo justo debajo.
Yo también.
Vale.
Ahora sí que utilizamos el avatar.
Ahora sí que se ve que esto está así.
Pero bueno, ya puedes ver que se ve un poco raro, ¿no?
Porque esto no está bien alineado y tal.
Lo que vamos a hacer es ponerle aquí un div,
porque vamos a hacer, además, este texto que teníamos aquí,
este strong, lo vamos a mover.
Lo vamos a mover aquí dentro.
Lo que pasa es que esto de que sea username no va a ser tan claro
como username, sino que esto tendrá que ser un text.
Y este text se vendrá con las props.
Estoy pensando que a veces el avatar lo vamos a querer utilizar con y sin.
O sea, puede ser que tenga texto o no.
Entonces, por un lado, vamos a hacer que le pasemos un texto o que sea el alt, ¿no?
Por defecto, que sea un texto o el alt.
Porque vamos a controlar que se tenga que mostrar el avatar con un texto
si le pasamos una prop que sea...
Ay, with avatar no, with text.
Entonces, si tenemos la prop with text, vamos a renderizar esto.
Vamos a renderizar esto.
Vale.
Guardamos los cambios.
Ahora ha hecho algo, ha habido algún cambio porque ahora esto está en un div
y por eso está saltando el texto.
Pero este texto todavía no se lo estamos pasando como prop.
Así que volvemos aquí y esto lo vamos a borrar.
Y de esta forma, bueno, ahora se queja, aunque esto es un tema de TypeScript
que creo que podríamos arreglar con jsdoc incluso.
Pero, bueno, por ahora se está quejando porque no tenemos el text.
Podríamos arreglarlo diciéndolo que el text es justamente user.username.
Pero como hemos hecho que el alt sea igual que el text y ya está.
Y le decimos que esto es with text.
Porque de esta forma, pues nada, ya lo mete dentro.
Ahora sí que lo está metiendo dentro.
Lo que nos faltaría, claro, es tener aquí un class name para el contenedor.
Container.
Así que en los estilos estos del módulo, lo que vamos a tener aquí es un container.
Container.
Y aquí vamos a poner display flex.
Dice, en lugar de usar text, no se podía hacer text.
Ahora te lo explico.
Pupi.
Sí, se podría hacer así, pero me dice por aquí Pupi, en lugar de usar with text, no se podría hacer text and strong.
Sí, se podría hacer, pero a ver, podríamos hacerlo, no hay ningún problema.
¿Qué pasa?
Que quería utilizar el alt por si acaso.
A ver.
Y entonces, ¿qué pasa?
Si utilizamos el alt, pues ya.
Pero, bueno, si quieres lo hacemos así.
O sea, vosotros sois los que mandáis.
Si vosotros lo queréis hacer así, lo hacemos así.
Está bien.
También podríamos hacerlo así.
Si solo tiene el texto, si sí que le pasamos un texto, pues entonces sí muestra esto.
¿Vale?
Me había parecido interesante que el alt pudiera ser utilizado también si le pasamos una prop boleana.
Porque, no sé, porque me había parecido interesante.
Pero ya está.
Lo podemos hacer así, ¿no?
Que si tiene el texto que sea justamente ese, pues se podría hacer así, perfectamente.
Y así lo vamos a dejar.
Vale.
Veo que, claro, hay un, bueno, un problema no, pero que esto está muy pegado.
Y esto que esté muy pegado tendría que tener un margen solo en el caso de que realmente
tuviésemos un strong al lado.
Entonces, podemos hacer dos cosas.
A ver, la más fácil entiendo que podría ser hacer esto, ¿no?
No sé, me imagino que esto, sí.
Esto sería lo más fácil, ¿no?
Básicamente es decir, vale, cuando el avatar está acompañado de una etiqueta strong,
que en este caso el más, es básicamente es como mi hermano.
Es como el selector es de mi hermano.
Es como el que tengo al lado.
Si el que tengo al lado, ¿no?
Si el avatar está al lado de un strong, o sea, si el strong está al lado de un avatar,
mejor dicho, ¿no?
Porque el selector es sobre el strong, le pongo un margen hacia la izquierda de 8 píxeles.
De esta forma, cuando no tenga un strong, pues no tendrá ese margen porque no lo necesitará, ¿no?
Y solo se lo ponemos al strong.
Que también directamente se lo podríamos poner al strong.
También se ha dicho.
Ay, no le ha gustado esto.
Ay, no, claro, porque tiene que ser...
Claro, sí, sí, sí.
No, no, tenemos que hacerlo así.
Porque estaba pensando en CSS.
Estaba pensando en CSS normal y corriente.
No, no, esto no es CSS normal y corriente, ¿vale?
Esto es más...
Claro, esto tiene que tener el scope dentro del componente y tiene que saber dónde te estás refiriendo dentro del componente a qué elemento en concreto.
Así que lo tengo que dejar así, que ya funciona, ¿vale?
Entonces, dice Bautista, si quieres usar el alt, haz esto.
Sí, pero bueno, como ves, ya es un poco...
O sea, me gusta más que sean más de...
No tan mágicos, ¿no?
O sea, si le paso una prop, que haga lo que tenga que hacer y tal, suficientemente mágico ya me parecía lo otro.
Pero bueno, que si queréis utilizarlo así, también me parece buena idea.
¿Podrías explicar cómo configurar el JSConfig JSON en los proyectos?
A ver, sí.
Y me parece muy interesante, ya que le habíamos dejado a medias esto también, ¿no?
Porque...
Y se lo comento un poco, ¿vale?
Alexander, que me parece muy buena idea.
Gracias por recordármelo.
Vale.
A ver, el tema.
Hay un JSConfig que tú puedes poner en tus proyectos para mejorar el cómo tratas ese proyecto.
Por ejemplo, en Next.js, pues tienes el TSConfig, que se da para TypeScript, y tienes el JSConfig.json.
Entonces, tú aquí puedes mejorar la forma de hacer, por ejemplo, los imports o cómo tiene que buscar los paths cuando tú haces un import, poner algún alias y cosas así.
A mí me gusta mucho.
Esto es algo que es totalmente compatible.
Hicimos en otro proyecto de React.
Esto es compatible con Create React App y con Next.js.
Y está muy bien.
O sea, que si utilizáis Next.js o tenéis un proyecto con Create React App, tenéis que hacer esto porque es la gloria.
Os pongo un ejemplo, ¿vale?
Vamos a buscar un componente, por ejemplo, aquí en Pages, en el Index.
Aquí, en el Index, tenemos estos imports que empiezan a ser un poco...
Bueno, a mí no me gustan, ¿no?
Porque es punto, punto, barra, punto, punto, barra.
De hecho, si empezamos a buscar en componentes...
No, esto por aquí, yo creo que por ahora lo más raro que tenemos es eso, ¿no?
Sí, por ahora lo más raro que tenemos es eso.
Punto, punto, barra, punto, punto, barra.
¿Qué pasa con los punto, punto, barra?
En este caso no es muy problemático porque entendemos que este Index solo tiene que saltar un nivel para estar en la raíz y acceder ahí, ¿no?
Pero imaginemos que estamos dentro de components, dentro de un anidamiento muy grande, ¿no?
Lo que podemos hacer, básicamente, es crear un JSConfig.
De esta forma, le podemos decir desde dónde tiene que empezar a detectar nuestros imports.
Y además está muy bien porque el JSConfig.json, lo que damos en la raíz, es totalmente compatible con Visual Studio Code y con todos los editores, por supuesto, y va a poder hacer todavía el autocompletado.
O sea, esto que hacemos aquí, punto, punto, barra, aquí nos autocompleta, barra, applyout.
Esto va a seguir funcionando de la forma que lo vamos a hacer.
Así que creamos el JSConfig y aquí, básicamente, tenemos el compiler options o el compile on save, que eso está más pensado para, sobre todo, para TypeScript.
Podemos hacer compiler options y aquí podemos utilizar el base URL.
El base URL es como decirle desde dónde tienes que tirar cuando tú tengas un import absoluto, desde dónde tienes que empezar a mirar, ¿no?
Y de esta forma aquí le podemos decir punto.
¿Por qué?
Porque va a ser el punto, es como esta carpeta.
Y esta carpeta es la carpeta donde está este archivo que es la raíz.
De esta forma, si ahora guardamos los cambios, este punto, punto, barra, punto, punto, barra, todo esto, lo podemos eliminar.
Y guardando los cambios, esto, bueno, ahora va a petar seguramente, me imagino que tendremos que reiniciar el servidor.
Vamos a hacerlo, de hecho, voy a eliminar esto y vamos a ver si ahora funciona, ¿vale?
Pero esto debería funcionar bien y nos debería permitir poder hacer este tipo de imports, ¿vale?
Estamos diciendo, vale, la URL base es, mira, ahora ya funciona, tenemos que refrescar, ¿vale?
Y de esta forma te queda así de bonito, components, barra, apply out.
Y esto tú no tienes ningún problema de seguir utilizando tus módulos de NodeModules.
O sea, puedes seguir utilizando sin ningún problema.
Ahora, imaginemos que quieres ir más allá, que dices, no, no, a ver, esto está muy bien, pero me gustaría tener un alias, ¿no?
Porque esto de escribir components, uff, es que soy como tú, mi dudev, es muy perezoso.
Cuanto menos escriba mejor, cuanto menos escriba mejor.
Vale, pues bueno, solo para enseñaros que esto sigue funcionando, ¿eh?
Si pongo components, ahí puedes ver que la primera es la carpeta, o sea, que el autocompletado funciona exactamente igual.
Y está muy bien porque esto hace que ya no tengas que preocuparte tanto de los niveles relativos, ¿no?
De decir, ah, ¿cuántas carpetas estoy? Punto, punto, barra, punto, punto, barra, punto, punto, barra.
Sino que directamente vas más al grano.
Dices, vale, la raíz está a components, components, barra, layout, styles, barra, no sé qué.
Vale, pongamos que dices, no, es que, uff, esto de escribir tanto a mí no me gusta.
Esto estoy escribiendo mucho.
Bueno, a ver, tienes también los paths.
Los paths son como unos alias que tú puedes crear para referirte a ciertas carpetas o archivos con un alias, ¿no?
Y por ejemplo, hay uno que es muy famoso, que aquí veo que no lo están utilizando, pero vamos a probar.
Por ejemplo, aquí, en el jsconfig, vamos a añadir otra opción que va a ser paths.
Y aquí vamos a añadir un path que sea, barra c, o arroba c, barra todo, ¿vale?
Y aquí le decimos dónde tiene que buscar esto.
Pues debería ser en components, barra.
Ahora, si refrescamos aquí, lo que deberíamos ser capaces ahora es hacer arroba c, barra, y debería ser a play out.
Entonces, cuando tenemos el components, en lugar de referirnos a components, podemos hacer arroba c, directamente, arroba c.
Bueno, en este caso, a mí particularmente, o es mi opinión, no me resulta, entiendo que se escribe menos, y yo soy todo por escribir menos,
pero creo que en este caso tampoco vale tanto la pena.
Creo que se pierde ya la, no sé, creo que se pierde el texto que te explica correctamente qué es lo que hay ahí.
Además, a mí me gusta ordenar los imports donde tengo todos los componentes, todo lo que son de fuera, porque es más fácil de ver.
Por ejemplo, yo esto lo dejaría así.
Además, cada uno lo ordenaría alfabéticamente, ¿vale?
Así que tendría los imports de los 9 modules, tendría los imports de los componentes, lo que sean estilos y lo que sean Firebase Client.
O sea, lo que sea otra cosa.
Los agruparía, básicamente.
Yo haría eso.
Entonces, no veo tanta necesidad de hacer el barra c, y menos porque a la hora de escribir, si escribimos uno, con que le pongas una c, ya te sale, lo primero que te sale es compones.
Entonces, no lo escribe, le das a la internet y ya está.
Aquí en gustos, bueno, una cosa, ¿para qué puede servir esto?
A ver, puede servir, por ejemplo, si sobre todo hay algo que es muy extraño, la gente no tiene por qué acordarse de cómo se llama y te gustaría simplificarlo.
O, por ejemplo, para referirte a un archivo en concreto que es muy especial y está en algún sitio muy raro.
No sé, pues tienes un megastiles, megastiles, ¿no?
Y esto pues tiene que estar de un sitio en concreto.
Y los megastiles están muy escondidos.
No sé, no soy muy fan, la verdad, de utilizar los paths.
No he tenido muchas veces la necesidad, pero ahí está por si lo necesitáis, que lo sepáis.
Esto sería básicamente lo que...
Oye, ¿qué le pasa a esto que se queja?
Not found of...
Ah, vale.
Sí, eso es un error interesante, pero no tiene nada que ver con nosotros.
De hecho, ¿lo hemos dejado todo funcionando?
Sí, vale.
Ya tenemos el avatar, tenemos todo el tema del components.
Creo que esto te ha solucionado bastante la pregunta que tenías.
No me acuerdo ahora quién eras.
Esto funciona, de nuevo, con Create React App y con Next.js.
Si tú creas un proyecto así desde cero y utilizas Webpack, vas a tener que configurarlo para que funcione.
Se puede llegar a hacer que funcione, aunque en Webpack tendrían los aliases que tú mismo deberías crear.
Pero bueno, que ten en cuenta que, no sé, yo creo que vale más la pena mantenerlo sencillo, hacer solo el del base URL, que en eso yo soy súper fan, soy súper fan, a mí me encanta ese del base URL, más que el de Paz, ¿vale?
Pero eso.
A ver, voy a leeros, voy a leeros por aquí.
Adrián Benavente, consulta, ¿por qué está usando la extensión JS y no JSX?
¿Cuál sería el criterio?
Vale, Adrián, mira, el primer criterio sería que no use JSX, ¿vale?
Esto no lo digo yo, sino que esto en realidad es que está deprecada.
La extensión, el utilizar la extensión JSX está deprecada por el equipo de React.
No lo recomienda.
De hecho, bueno, no sé, alguien puede decir, te lo estás inventando.
Pero no sé si lo podemos encontrar rápidamente, ¿vale?
Pero esto hace unos años es verdad que se utilizaba, ¿vale?
Y se utilizaba y tal.
Pero ya no tiene sentido hacer esta distinción.
Ya no, estoy buscándolo, ¿eh?
Mientras lo comento.
Ya no tiene sentido hacer esta distinción, aunque se soportan ambos, ¿vale?
¿Por qué? Pues por temas históricos se soportan ambos.
Pero el tema es que se hacía .jsx cuando los archivos tenían JSX.
¿Qué pasa?
Que en realidad la distinción no tiene tanto sentido, porque lo que estamos escribiendo realmente es JavaScript.
Y estamos utilizando Babel para que lo transpile.
Y ya está.
Entonces, no recuerdo dónde había visto y lo buscaré.
Pero básicamente la recomendación es dejar de utilizar JSX como extensión.
Si te gusta más por X motivo, porque dices, no, es que así tengo claro que ahí hay JSX.
Pues lo puedes seguir utilizando y yo creo que esto no lo van a dejar de soportar en el tiempo próximo.
Creo que para que veas que realmente esto es algo oficial, puedes ver el ejemplo de Queer Breakup,
que yo diría que los archivos que te crea, te los crea con JS.
Pero a efectos prácticos es lo mismo.
JS, JSX, no pasa absolutamente nada.
Realmente, esto es una chorrada como un templo que voy a decir,
pero lo único que tiene así que diríamos de peor, de peor, es que si utiliza JSX tienes que utilizar una extensión más en Webpack
y el resolver, el que resuelve las rutas y mira los archivos, va a tener un poquito más de trabajo.
Bueno, yo no lo utilizo, pero si JSX te va bien, aunque ya te digo que no se recomienda utilizarlo como extensión más,
pues mira, lo puedes seguir utilizando porque no vas a tener problema y lo van a seguir soportando.
No estoy seguro, de hecho lo podemos probar, seguramente si buscas información sobre esto,
verás que la gente que lo recomienda son artículos de 2018, 2017, cosas así, ¿vale?
Ten cuidado también, pero las cosas más recientes que voy leyendo y tales, no utilicéis JSX.
Pero bueno, ya te digo que esto es que cada uno lo utilice como le vea mejor.
Al final, si tú le encuentras algún tipo de utilidad, pues fantástico.
El Slinder B&B te pide usar JSX.
El Slinder B&B te pide muchas cosas y no por eso.
Pero bueno, sé que es un Slinder que gusta mucho, pero bueno, a mí no me gusta tanto.
Mira, gente que llega al directo, ¿tengo que salir? Vaya, ¿va a estar disponible para verlo?
Siempre están disponibles, siempre, siempre están disponibles.
Todos los lives siempre van a estar disponibles en YouTube, justamente después, ¿vale?
Vale, dice Nicolás que según Dan Abramov depende de uno o no más.
O sea que si tu JS no va a tener JSX, no tiene sentido JSX, claro que no tiene sentido JSX.
Al final, como veáis.
Pero ya te digo, yo estoy bastante seguro que he llegado a leer y lo buscaré, que la última recomendación es no utilizarlo.
Porque no tiene sentido, la verdad, no tiene sentido.
Ah, mira, dice React.js Legacy Factories.
A ver, no sé si esto tiene algo que ver.
Ya no puede de esta manera.
Punto JSX, extensión, no sé, ahí.
No sé, que pensaba que en esa...
Probablemente llegaste aquí, pensaba...
No sé, es que Nicolás me está poniendo por aquí enlaces y estoy intentando buscar a ver si alguno lo pone.
Porque estoy bastante seguro que...
16.13.js.
No sé si está poniendo enlaces random o realmente...
No sé, pero bueno, que estoy bastante seguro que lo leí en algún sitio.
Por si me interesa, lo buscaré.
Vale.
Pues como con esto hemos estado, el TSX Matías Caballero.
Pues sí, exactamente lo mismo, Matías.
Es que es exactamente lo mismo.
Vale lo mismo.
Que ya os digo, si esto sirve a vosotros, no lo dejéis de utilizar, por más que nadie diga, ni aunque lo diga yo.
Ni Dan Abramov, ni nada.
Pero vaya, que lo sepáis, porque al final todo esto pasa por Babel.
Entonces, ¿qué pasa?
Que ahora, de hecho, esto antes pasaba, ¿no?
Que los archivos que pasaban por Babel, había gente que los ponía .babel o .babel.js, cosas así.
Y ahora ponemos .js.
Entonces, al final no deja de ser eso JavaScript.
Es verdad que es un azucarillo sintáctico, pero no sé.
En este caso, creo que no vale tanto.
Bueno, si lo encontráis por ahí, también me lo pasáis, ¿vale?
Nicolás está...
Oye, Midus, siempre soy súper serio.
Vale.
Antes de...
Os quiero enseñar una cosa.
A ver si vamos a dar una caña.
Bueno, Ferdinand, vamos a ir a nuestro GitHub, ¿vale?
Porque antes de continuar, tengo que hacer algo.
Ya que alguien ha aportado ahí una gran cosa para nuestro proyecto.
Y le tengo que agradecer, además, a Ferdinand.
¿Ferdinand?
A ver, ¿dónde estás?
Aquí.
Ferdinand, que en realidad se llama Fernando Alejandro Yerena Ramos.
Pero bueno, Ferdinand Alexa, es como lo conocemos aquí en el chat,
que no sé si está, pero vamos a agradecerle que nos ha hecho estos tres pedazos de logos, ¿vale?
¿Por qué?
Porque os dije en el anterior live que me gustaría tener un logo que no fuese el mío, ¿no?
Porque este es mi logo.
Entonces, nos hizo este de un huevo y además se le ocurrió mucho,
porque en cada uno de ellos, pues, puso la explicación del logo, ¿no?
Pues este es un huevo por tal, esto es un búho por qué tal,
y esto es una polilla por qué tal.
Ha estado muy bien, ¿no?
Entonces, he puesto una encuesta esta tarde para saber vuestra opinión al respecto
y ha habido 153 votos, así que yo creo que esto tiene cuerpo y es una buena decisión
y ha ganado el búho, ¿vale?
Ha ganado el búho que, os lo explico, la mascota de Depter, al ser un clon de Twitter,
debe ser un equivalente nocturno.
El mochuelo común, tipo de lechuza, un búho, vaya, chiquitico,
al igual que programadores y programadoras en todo el mundo, aprovecha las noches para cazar bugs.
¡Wow! Se la curraba mucho.
Así que vamos a utilizar el búho y lo vamos a cambiar.
Como esto es un momentito, vamos a hacerlo, que debo tener por aquí, a ver, a ver, el logo.
Lo tengo aquí en SVG y veo que me ha puesto por un lado el búho y en otro este.
Pues vamos a utilizar el mochuelo.
Voy a acercar aquí el SVG y ya me lo ha transformado en un componente SVG.
Para el que no conozca esto, este es el React SVGR,
que lo que hace es que le podemos pasar un SVG y no lo convierte en componente de React, ¿vale?
Y la verdad es que normalmente hace buen trabajo.
Así que ahora que tenemos esto, cada vez que te lo copias te dice,
¡Dame dinero! ¡Dame dinero!
¿Qué? No entiendo.
Vale, entonces, tenemos iconos, vamos a poner aquí el logo.
Vamos a pegar lo que nos ha creado este.
Mira, ahí podéis ver el import ese que os comentaba antes, ¿eh?
Vale.
Depter, bueno, logo, total, logo.
Vamos a ver si esto funciona bien.
Este dataname no sirve para nada, este export ya tampoco sirve para nada.
Y vamos a utilizar nuestro logo nuevo, nuestro logo, nuestro logo.
Importamos el logo from components, icons, logo.
Y además así vemos que funciona perfectamente lo que hemos hecho antes, ¿eh?
Vale.
Esto teníamos antes una imagen, pues esto fuera.
Ponemos directamente el logo.
Vamos a ver si a esto le gusta.
Bueno, bueno, ¿eh?
No está nada mal este logo.
Además me gusta el color ese eléctrico que le ha puesto, ¿eh?
Me gusta, me gusta bastante.
Lo que es grandecito, pero me gusta, me gusta.
De hecho, vamos, ese color que lo he visto por aquí.
¿Lo he visto por aquí?
Sí.
Vale.
Pues este color se lo vamos a poner...
Bueno, vamos a nuestro theme, ¿vale?
Vamos a nuestro theme.
Había puesto primario con mi color favorito, pero para que veáis lo que me ha gustado el logo, ¿eh?
O lo se lo pongo a poner en secundario.
No sé, ahora tengo dudas.
Ahora tengo dudas.
Bueno, creo que tiene sentido que sea así, ¿no?
O sea, el secundario, o sea, tendría sentido esto.
Lo que pasa es que vamos a tener que cambiar esto al revés.
O sea, que el secundario este sea el primario y este sea el secundario.
Y ya está.
Así que, bueno, ahí lo tenemos.
Además, podemos crecer esto un poquito más.
Igual 32.
No sé, igual es un poco bestia.
Vale.
Pues ya tenemos nuestro nuevo logo.
¡Bravo!
¡Bravo, Fernando!
Muchísimas gracias, ¿eh?
Muchísimas gracias.
Me encanta.
Me ha gustado mucho.
Muchas gracias a todos los que habéis participado en la votación.
Muchas gracias, sobre todo, de verdad, Fernando, que es que ha hecho un trabajazo aquí brutal.
Y, bueno, dice que, mira, ha podido rascar tiempo.
Ya sabéis que me encanta que participéis.
También le tengo que agradecer a Lucas y a Nicolás Santiago.
Creo que es Nicolás Santiago.
A ver si se llama.
No, Nicolás Santis.
Porque también han hecho pull requests, aunque no las ha emergeado.
Porque, por ejemplo, Lucas hablaba de añadir TypeScript.
Por ahora no lo vamos a añadir, pero no lo descarto.
Además, le había añadido Prettier, había hecho más de una cosa.
Y le agradezco un montón.
Me parece buena idea añadir TypeScript, pero todavía no lo vamos a hacer.
Así que igual más adelante lo añadimos.
Y muchas gracias a Nicolás Santis, que también había hecho una PR, que le comenté que me iría bien que le hiciese, pues, para ver cómo lo había hecho y tal.
Donde añadía el linter de Slint.
Él ha hecho una cosita diferente, y lo comento, que es utilizar Babel Slint.
Y es interesante, y quizás en algún momento lo necesitamos.
Babel Slint lo que hace en realidad es utilizar Slint, pero lo que hace es que puede soportar sintaxis que todavía no está aceptada por Slint.
Slint porque no está en el Stage 3.
Bueno, que no está cerca de acabar en el lenguaje.
Como, por ejemplo, los decoradores.
Pues, por ejemplo, los decoradores necesitaríamos utilizar Babel Slint.
Como por ahora no tenemos nada así que sea, por ejemplo, el Optional Chaining ya está aprobado.
O sea, que también está.
Hay muchos que ya están.
O sea, como no estamos utilizando ninguna sintaxis muy especial de Babel o última tecnología, no necesitamos este parser.
Pero si no necesitáramos, solo tendríamos que hacer esto.
Parser y Babel Slint.
¿Vale?
Quizás más adelante, vemos que lo necesitamos, pues lo cambiamos.
Y muchas gracias a todos los que habéis votado.
Espero que no estéis votando ahora a lo loco.
Voy a...
Vale.
A ver si estáis votando a lo loco para que salga la polilla.
Vale.
Veo que no.
Perfecto.
Bueno, pues, ¿qué más?
¿Qué más?
Creo que con esto...
Bueno, hay un par de cosas que quería arreglar también, ¿vale?
Una, como os he comentado antes, aquí hay un error.
Aunque está muy bien que ahora estoy con la sesión iniciada y lo detecta.
Si yo quito la sesión y refresco, ¿vale?
Pues peta, porque debería aquí aparecer el inicio a sesión de GitHub.
Lo vamos a arreglar, ¿vale?
Aquí tenemos el pete, que dice, no puede leer la propiedad display name de null.
Y es porque hay un error que cometí en el anterior live, que vamos a subsanar ahora.
Y os comento, en Firebase, en Client, aquí lo que hacíamos...
A ver si puedo hacer esto más chiquitito.
Vale.
Y esto quitarlo.
Perfecto.
Vale.
Lo que hacíamos es que, nada, nos lo quedábamos con GitHub y ya está.
Luego teníamos por aquí...
Ah, mira.
Estaban los puntos de coma todavía.
Lo he quitado.
Vale.
Teníamos que cuando se cambiaba el estado de si el usuario estaba autentificado o no,
pues lo que hacíamos es extraer el usuario normalizado y todo esto.
Pero esto no está bien porque a lo mejor el usuario...
O sea, esto se ejecuta cuando cambia el estado de autentificación.
Pero esto puede ser que se deslogue o que se logue.
Si se loguea sí que nos va a devolver un usuario, pero si no, nos va a devolver un null.
El usuario será un null.
Por lo tanto, no podríamos extraer del usuario la información porque no hay usuario donde
extraer la información.
Así que lo que podemos hacer, podríamos hacer esto de muchas formas, pero bueno,
he pensado que lo que podemos hacer fácilmente es esto, ¿no?
Que si tengo un usuario, pues vamos a mapear la información de usuario y si no, devuelvo null.
Null que también esto podría ser user porque creo que devuelve null también Firebase.
De esta forma, hacemos un cambio y esta información normalizada pues será null.
Ya está.
Así sí que tenemos ya de nuevo nuestro componente de login.
De esta forma, pues nada, le damos ya más creencia de que esto funciona.
De hecho, si hacemos login y ahora esto recarga, nos devolverá la página, deberíamos ver que
automáticamente aparece nuestro avatar.
Ahora sí, está funcionando como esperábamos.
Entonces, quería llegar a hacer, y a ver cuánto vamos, 1.44.
Bueno, llevamos tiempo, ¿eh?
Quería llegar a hacer un poquito más de la home.
La verdad es que me lío un montón.
Así que, a ver, vamos a hacer algo.
Vamos a hacer dos cosas rápidas, más o menos.
He visto que en Twitter, cuando te logueas, te lleva directamente a barra home, ¿vale?
Que está bastante bien, que es interesante, porque si tú intentas entrar a Twitter, te lleva
directamente a home.
Entonces, en la siguiente clase, porque en esta no nos va a dar tiempo, no lo haríamos,
o no lo vamos a hacer lo bien que me gustaría.
En la siguiente clase vamos a hacer esto, ¿no?
Que cuando estés logueado, directamente vayas a barra home.
Y cuando no estás logueado, pues estás en esa página donde te pedimos que te registres
y que te lo vas a pasar pipa.
Pero ya sabemos que vamos a necesitar un barra home.
Así que, he creado aquí una carpeta que se llama barra home, y dentro vamos a crear
nuestro index.js.
Aquí lo que vamos a hacer es crear una nueva página, que va a ser la home page.
Y por ahora, pues nada, vamos a dejar esto así.
Vamos a poner aquí esto, y esto por aquí.
Bueno, ya más que crear este h1 aquí a saco, vamos a poner un section, ¿vale?
Y lo que vamos a hacer, porque cuando esto se hace chiquitito, es que claro, como os acordáis,
vamos a hacer el mobile only este, más chiquitito, porque esto es medio chiquitito.
Es que todavía se hace más chiquitito Twitter, ¿eh?
Se comprime ahí como una cosa enana.
A ver ahora.
A ver.
Para abajo.
Vale.
Ves que deja ahí una barra, que tienes el avatar, y ya.
Vale.
Pues eso sería, pues podríamos decir que es el header, ¿no?
Que se va a quedar ahí, y luego abajo, además, tiene, aunque no, a ver, es que si cierro esto,
voy a ver si cerrando esto, y hago esto un poco más pequeño.
Vale, aquí.
Tenemos esta barra, ¿no?
Que te dice las notificaciones y tal.
Vale.
Pues esto lo vamos a poner, vamos a poner que es un lab.
Y aquí en medio, digamos que tendríamos nuestro timeline.
Entonces, así un poco, para darle un poquito de vida a esto, lo que vamos a hacer,
yo voy a continuar con StyleJSX, pero si por lo que sea preferís hacer CSS modules donde
tenga sentido, pues ya sabéis que perfecto, ¿eh?
Que no hay ningún tipo de problema como hemos visto antes.
Entonces, aquí lo que podríamos decir es el header, que tenga un position fix, porque
me imagino que es así como funcionará.
Ya os digo que el height es 49, porque es como un número mágico en Twitter, los avatares,
hay muchas cosas que tienen 49 píxeles, no sé por qué, no tengo ni idea, algún día
me enteraré.
Y esto también, pues un position fix, pero esto va a estar en el bottom, esto va a estar
arriba, ¿vale?
Por ahora, vamos a poner que tenga un border, bottom, solid.
Me los estoy inventando al cholón, ¿eh?
Estoy igual peta por todos los lados.
O sea, no es que esto me lo he diseñado yo antes, ¿eh?
No tengo ni idea cómo se va a ver esto ni nada, ¿eh?
Pero bueno, poco a poco, pues ya le vamos.
Vamos a poner por ahora esto, por aquí.
Y, vale, entonces, esto es el section.
No sé si ponerle section o poner div directamente.
Y el section, en realidad, ponerlo aquí.
Y el section, que tendríamos aquí, ya sabemos que va a tener un padding top.
¿Por qué?
Porque si te fijas, cuando vas haciendo scroll, ves que esto se queda arriba.
Pero aquí queda bien.
O sea, que esto tiene que tener ahí, no sé, 100 píxeles o algo así.
No tengo ni idea.
Vale, vamos a ver.
Vamos a poner aquí el inicio.
Y aquí, bueno, por ahora, no sé si ponerlo a mano, pero...
Bueno, vamos a poner el inicio por ahora, ¿vale?
Que ya os digo una cosa, ¿eh?
Que el título, el title, a mí me gusta mucho el poder de componentizar las cosas, ¿no?
Entonces, ya nos podemos dar cuenta que este inicio que vemos aquí
tiene como el look and feel un poco de este.
Y podríamos crear un componente de React que no solo, o sea, para crear ya una guía de estilos donde nuestros componentes de React, pues, se puedan reutilizar fácilmente, ¿no?
Así que esto puede ser una oportunidad.
Pero bueno, lo vemos ahora.
Por ahora tendríamos algo así.
Vamos a ver.
Si yo voy a Barra Home a ver esto que le pasa y que le gusta.
Vale, esto, o sea, me ha creado ahí.
Inicio ha quedado fatal.
Ha hecho todo lo contrario de lo que esperaba.
Bueno, el tema es que dijimos que el layout, el layout ese que habíamos creado, lo teníamos en un componente aparte, ¿no?
Y que por lo tanto teníamos que envolver nuestros componentes con este app layout.
Por ahora lo vamos a hacer así, aunque cuando lo hicimos ya os comenté que una de las posibilidades que había era precisamente,
mira, y podemos quitar el, era utilizar el app, ¿no?
Pues para tener esto de envoltorio.
Y seguramente lo vamos a hacer así, ¿eh?
Lo moveremos al nuevo app.
Este sobra.
Lo moveremos a app en lugar de tenerlo aquí en todos los sitios.
Vale, app layout, from, y como tenemos lo de components, pues, fantástico.
Porque si no aquí, fijaos, aquí ya tenemos que tener punto, punto, barra, punto, punto, barra, ¿no?
Y ya tenemos ahí el app layout.
Vale.
Vamos a ver qué le pasa a esto, porque no le ha gustado nada.
Vale, ¿qué pasa?
Que seguramente esto no tiene un position relative y tal.
Una cosa que podríamos hacer, ya que estamos, ese app layout que habíamos creado aquí en components,
pues igual le podríamos añadir el, ah, mira, le habíamos hecho un styles aquí.
Este es el main.
Bien, pues igual aquí le deberíamos poner el relative.
A ver si esto le gusta un poco más.
La chorada.
La chorada.
Vamos a ver los estilos.
Vamos a abrir esto un poco.
A ver qué no le está gustando de todo esto.
Vale.
Tenemos el main.
Tenemos el position relative.
Tenemos el header.
Bueno, esto ya vemos que...
Esto debería ser así.
Claro, con el width al 100%.
A esto le pasará un poco lo mismo, con el width al 100%.
Ah, mira.
Y con eso ya tendríamos esas dos cositas.
No está mal.
Luego el section, claro.
Flex, block.
Pero...
¿Dónde he puesto el inicio?
Ah, que lo he puesto dentro.
Claro, claro.
Ya os digo, ¿dónde está el inicio?
No tiene sentido.
Vale.
No, el inicio está bien.
Va dentro del header.
Lo que pasa es que un h1 igual es demasiado.
Vale.
Entonces, venga.
Esto ya pinta mejor en un momentito.
Vale.
Esto, el width al 100%.
Que ya se está viendo que tanto el header como el nav comparten muchas cosas.
Pero, bueno, eso lo podemos arreglar después.
Vale.
Pues ya tenemos eso.
El h1 este que habíamos puesto, pues ya le ponemos un h2.
Un poquito menos.
Bueno, el h2 está bien.
Y, de hecho, el header podría ser flex, line, item, center.
A ver esto cómo queda.
Vale.
Ya hemos centrado verticalmente el inicio.
A ver, sé que todavía nos queda lo nuestro.
De hecho, el h2 este es como muy negrita, ¿no?
Es como muy, muy, muy bestia.
Me encanta lo rápido, lo rápido que es el fast refresh este porque es instantáneo.
Vale.
Y es un pelín más pequeñito.
No sé, no sé cuál será el...
Vamos a poner que es 24 o...
No, 24 es exactamente lo mismo.
21.
Bueno, se parece.
Se parece mucho.
Vale.
O sea que ya nos faltaría un poco poner el avatar del usuario que esté logueado en ese momento.
Y ya estaría.
Por ahora, lo que podríamos hacer es intentar estilar muy por encima el timeline para avanzar y ver más cosas, ¿vale?
Por ahora lo vamos a dejar así, que más o menos se parece un poco.
Ya tenemos el header y tenemos la botonera de abajo.
La botonera de abajo, ya os digo que buscaremos iconos por ahí que se parezcan mucho para que parezca que es exactamente Twitter.
Y el timeline, lo que podemos hacer rápidamente es crear una carpeta API, ¿vale?
En Next.js, y esto lo volvemos a explicar porque vamos a hacer muchas APIs, vamos a hacer un montón de endpoints, ¿vale?
En Next.js puedes crear dentro de la carpeta Pages, puedes crear una carpeta API.
Y esto lo que puedes hacer es crear endpoints con la ruta de archivos que vas a hacer.
Por ejemplo, si yo aquí creo pepito.js, pues aquí ya tengo la posibilidad de tener un endpoint.
Y esto teníamos que hacer un export default.
Esto no me acuerdo si era así o era...
No.
No.
Era...
Sí, de hecho creo que...
No, es así.
Vale.
Tenemos por un lado la request que nos llega y por otro lado la response.
Pero por, no sé, siempre se va a hacer rec y res.
¿Vale?
Y aquí ya lo único que deberíamos hacer es devolver, uno, el status code, que por estos 200.
Luego lo que podríamos hacer es el header para decirle qué tipo de contenido vamos a devolver.
O sea, el content type y decirle que esto es application barra JSON.
Y finalmente la información que queremos devolver.
O sea, que JSON.stringify y aquí devolveríamos eso.
El name, pepito.
Esto por un lado.
Bueno, ya veis que me lo ha formateado con las comillas dobles.
Esto es un tema de...
De...
De Prettier.
Vale.
Entonces, en localhost, api, pepito.
Vale.
Ha apretado porque no es localhost.
Es en localhost 3000, que es donde tenemos ahora mismo el servidor.
¿Vale?
Y cerramos esto.
Vale.
Pues ya podéis ver que tenemos este pepito que hemos puesto.
Que así que aquí puedo poner lo que quiera.
Entonces, como lo que queremos es que le parezca mucho a Twitter, me he fijado de cuáles son los endpoints que utiliza Twitter.
Y uno de los que utiliza sería barra...
O sea, api barra estatuses.
Home timeline.
¿Vale?
Y dentro vamos a crear un index.js.
Porque esto es importante.
Podemos empezar a crear carpetas o podemos crear directamente el archivo.
O sea, es lo mismo que creemos la carpeta pepito y dentro el index.js que crear directamente pepito.js.
Pero bueno, creo que alguien lo dijo el otro día.
Creo que puede estar bien crear las carpetas por si esto crece mal, ¿no?
Y por lo que sea, necesitamos más de un archivo para ese endpoint.
Así que, adiós, pepito.
Vamos a crear este.
Tengo...
A ver, ¿por dónde tengo esto?
Tú, tú, tú.
Pa, pa, pa.
A ver, espera.
Que estoy buscando aquí entre mis carpetas.
Debo tener un array que he hecho antes rápidamente.
Aquí.
Vale, ya la tengo.
He creado este array.
Es un array con tres tweets, básicamente.
¿Vale?
Entonces, bueno, ya...
Esto, claro, está lleno de errores porque esto es JavaScript y no le gusta que peguemos un array ahí directamente.
Así que vamos a crear esto timeline.
Vamos a llamarle por ahora.
Y este timeline ahora hay que utilizarlo.
Como estamos creando este endpoint, pues lo mismo.
Lo podría haber reutilizado pepito ahora que lo pienso.
Pero, bueno, da igual.
Así lo volvemos a practicar.
¿Vale?
Export default.
Esto recibe la request y la response.
¿Vale?
Y aquí le tenemos que decir, por un lado, el status code.
Por otro lado, tenemos que setear el header para decirle el content type de este contenido que estamos devolviendo,
que es application.json.
Esto, básicamente, es porque si no, el navegador puede intentar formatear la respuesta con otra cosa.
Puede decir, ah, no, esto es JavaScript o un texto plano o bytecode o lo que sea.
¿Vale?
Entonces, es importante decirle el header, el content type.
¿Vale?
Le estamos diciendo, no, no, el contenido que estoy enviando, porque claro, tú al final lo que envías en realidad es texto.
Que sepa o no que esto es un JSON, se lo está diciendo tú con el header del content type.
¿Vale?
Entonces, luego, res punto, ahora no sé si he leído send.
Ah, dice, user01 decía send, res punto send.
Creo que el res punto send, no sé si, yo creo que debería funcionar sin ningún problema.
Al final el send es porque puedes enviar información y el n es porque envías la información y cierras la conexión.
Es como decirle, te envío esto y esto es lo último que va a ocurrir en este endpoint.
Con el send, no sé cómo funcionan exactamente los endpoints en Next.js, pero lo que puedes llegar a hacer en Express es hacer un send de dos cosas.
O sea, puedes enviar un trozo de la información que quieres, ir haciendo más cosas y hacer otro res punto send.
Esto se le llama, básicamente, hacer una transmisión por chunks, ¿no?
Por trozos y esto es muy útil cuando hay una API, por ejemplo, que tiene cierta información, que la ha recuperado de una base de datos, ¿no?
Y dice, ah, pues voy a hacer, voy a recuperar esto de la base de datos.
Te lo envío, pero todavía tengo más cosas que hacer.
Vale, pues mientras estás haciendo otras cosas, te he enviado esto para que al menos puedas recibir información.
Y mientras voy terminando y te hago otro send más tarde cuando tenga toda la información, ¿vale?
Y luego terminar la conexión con res punto en, pero sin enviarle nada.
Ya harías un res en así, básicamente.
Lo podemos, lo vamos a probar.
A ver, a ver qué pasa.
Stringify y aquí lo que deberíamos decirle que tenemos que hacer Stringify es del timeline.
Esto debería ser así.
Y ahora, pues vamos a API, statuses, home timeline y ya tenemos aquí justamente lo que queríamos.
Ya tenemos el JSON que, a ver, está preparado, pero este es el JSON que crearemos y recuperaremos de Firebase, ¿vale?
Seguramente con más información porque le falta mucha información, pero quería que me sirviese más para ir empezando a hacer estilos en nuestra home, ¿vale?
Nuestro timeline.
Así que, por cierto, que he cerrado Twitter y me iría bien tenerlo como para chivar, ¿vale?
Mira, JSON Miller, más majo.
Vale.
Vale, pues nada, ya tenemos un endpoint donde recibimos esta información.
Por ahora, lo que vamos a hacer en nuestra home es tener, vamos a hacer un fetch directamente para tenerlo y ya está.
Vale.
Ahí, voy a hacer un import.
Bueno, claro, el import del useState y el useEffect.
Que esto lo mejoraremos.
Esto es una primera iteración de hacia dónde queremos llegar y al menos, pues vamos quitándonos estilos y cosas que queremos hacer, ¿vale?
Ahí, un buchito.
Vale.
Vale, entonces, vamos a hacer esto, me sabe mal porque esto, o sea, me gustaría que ahora pudiera hacer que vosotros escribáis esto, que alguien escriba esto, ¿vale?
Para ver si lo hacéis bien, de a ver si hemos aprendido algo con todo esto y realmente, porque es una llamada a una API, es súper típico, entonces me gustaría a ver si así de esta forma, pues podemos seguir practicando, ¿no?
Pero es que, claro, yo esto ya me lo sé casi que de memoria.
Así que vamos a poner timeline, set timeline.
Ya os digo que esto no va a quedar así porque vamos a hacer otras cosas, ¿vale?
Pero hoy, como quiero que avancemos, por ahora vamos a hacerlo así.
Y como todavía no hemos deployado esto, vamos a ir muy a saco, por ejemplo, haciendo esto.
Pero esto va a cambiar totalmente, ¿vale?
Esto no lo vamos a dejar así, no lo vamos a hacer así, ¿vale?
Que os quede claro.
Así que hacemos un fetch, hacemos un fetch al endpoint que hemos creado.
Aquí alguien me decía, ¿por qué siempre pones la ruta entera?
¿Vale?
Esto no es que yo ponga la ruta entera, ¿vale?
Sino que cuando utilizamos, que lo hablamos en la primera clase, ¿vale?
Cuando utilizamos el getInitialProps o el getStaticProps o lo que sea, el fetch sí que necesita la ruta entera
porque esos métodos se ejecutan, no se ejecutan en el cliente, se ejecutan o en el servidor y tal.
¿Y qué pasa?
Que tú en el servidor no sabes en qué ruta estás, o sea, no sabes como relativo a qué.
Entonces, lo que se hace es que tú tienes que poner la ruta entera.
En este caso en concreto, sí que podemos aquí, sí que deberíamos ser capaces de hacer esto, ¿vale?
Lo vamos a ver.
Pero aquí, si es un efecto, que estás en el cliente y por lo tanto ya tienes una ruta, no vas a tener ningún problema.
Pero cuando es en el getInitialProps, esto no funciona, ¿vale?
Tienes que ponerle la ruta completa.
Eso es importante.
Así que, vale, vamos a tener esto.
Y lo que vamos a hacer por aquí, pues nada, esto debería tener un timeline.
Vamos a hacer el map.
Esto hemos dicho que era un debit, ¿no?
Bueno, dijimos que nuestros tweets se iban a llamar debits, ¿vale?
Así que por ahora vamos a poner, estos serán articles y a ver qué es lo que nos enseña Twitter.
Pues por un lado tiene el avatar, ¿no?
El avatar, que esto lo tenemos en nuestro endpoint en avatar, o sea, debit.avatar.
Y luego el alt será el debit.username, ¿vale?
Esto lo dejamos así por ahora.
Ah, vale.
Esto podemos hacer aquí un return, claro, porque si no, no le gusta.
Devolvemos esto.
Y luego, vale, ¿qué es lo que me gusta?
Ah, la key, claro.
Ah, y mira, claro, es que no le he puesto index a nuestros debits.
Anda que yo también no le he puesto ideas.
Entonces, esto debería tener una idea.
Key de 0, por ejemplo.
La idea no será 0.
Esto nos lo va a crear.
¿Qué pasa?
Esto nos lo creará Firebase, ¿vale?
Esto, estas ideas las generará Firebase cada vez que añadamos uno.
¿Qué es lo que vamos a hacer en el siguiente?
En el siguiente vamos a crear el formulario.
Pondremos el formulario con el botón.
Le daremos al botón.
Se mostrará el formulario.
Y lo que haremos es crear ese debit en la base de datos de Firebase.
Y luego lo que haremos es recuperarlos, ¿vale?
O sea, que haremos las dos cosas.
Y eso será en el siguiente vídeo.
Así que ya lo sabes.
Debit.id, ¿vale?
Esta de id es la que justamente he añadido.
Avatar se queja porque no lo he importado.
Así que lo importamos.
Avatar from components barra avatar.
Perfecto.
Vamos a ver por dónde van los tiros aquí.
Vale.
Bueno, a ver.
No es exactamente, pero nos estamos acercando.
El tema de esto, a ver.
Esto es que justo debajo tiene esto.
Vale.
Justo debajo veo que hay ahí una cosa.
Bueno, lo primero es que aquí hay un padding como enorme, ¿no?
Que me pasa a otros pueblos.
Vamos a ver exactamente cuánto es.
No sé si se ve bien, ¿eh?
Pero si no se ve, me comentáis.
Vale.
Tengo aquí este section.
Y le he puesto aquí un padding como enorme.
Entonces esto tiene que quedar como por abajo, pero tampoco...
Mira, 56.
Ahí lo tenemos.
Así que vamos a ponerle el padding a este de 56.
Luego, el article.
Esto sí que parece que está bastante bien.
Lo que tiene un padding por abajo, ¿no?
Podemos hacer que lo tenga por abajo y por arriba.
Claro.
Podríamos hacer que esto fuese 49 exactamente, que es lo que tiene.
Y que en realidad fuese...
Esto lo separaremos luego en componentes, ¿eh?
Tampoco no os preocupéis.
Que luego, si no, la gente...
No, pero ¿cómo no lo separas en componentes?
Sí, lo separaremos en componentes.
Vamos a ver qué espacio hay aquí.
10.
Vale.
Pues esto vamos a poner que tenga un padding de 10.
Esto es arriba y abajo.
Y derecha, izquierda...
Vamos a ver cuánto tiene, más o menos.
Esto es...
¡Buah!
Es interesante porque utilizan CSS de este hasheado.
La gente de Twitter, ¿vale?
Que se ve claramente.
Porque aquí tenéis...
Es como los hashes que hemos visto nosotros que te crea CSS modules y tal.
Mira, aquí tenemos padding-right 15.
Puede ser 15.
¡Ay!
Lo he quitado del...
Vale.
Pues...
10 por arriba y por abajo, 15 derecha e izquierda, ¿vale?
Así que...
Vamos a...
¡Uy!
Aquí no es donde quería dar.
Aquí sí.
Vale.
Para seguir copiándome.
Mira, aquí está mi colega Esparragus.
Vale.
Bueno.
Ya va...
Va saliendo.
Ahora, el article como tal, esto ya os digo, ¿eh?
Esto lo estoy haciendo sobre la marcha.
Así que si hago muchas burradas.
Así que si hago muchas burradas, es normal.
Dentro del header...
Del article, perdón.
Vamos a tener un div.
Y por un lado, viendo esto, tenemos aquí...
Bueno, tenemos más información porque tenemos el handler y tenemos el tiempo y aquí una barrita.
Pero por ahora vamos a fijarnos en el display name y el texto, ¿vale?
Y con eso, yo estaría bastante contento si más o menos hacemos que esto quede bien.
Vale.
Entonces, ¿dónde tenemos el texto?
Vamos al endpoint y tenemos el mensaje.
Así que debit.message.
Y por otro lado, vamos a poner...
¿Qué era lo otro?
Ah, el display name, ¿no?
El username.
Aquí le he llamado username.
Tendríamos que asegurarnos si le llamamos así en todos los sitios.
O sea, vamos a unificar bien los nombres.
Es importante que todos los sitios le llamamos de la misma forma.
Vale.
Aquí el problema, además, es que ya me está centrando las cosas.
Y esto para nosotros no es necesario.
Esto es porque aquí, en este...
En este he puesto esto.
Claro, este es el avatar.
Claro, como he puesto aquí directamente el avatar, esto lo está centrando.
Y eso, en realidad, no es necesario.
O sea, a ver si...
Aquí ya empezamos a tener problema de...
Estás haciendo demasiadas cosas en el mismo componente.
Entonces, vamos a hacer algo.
Vamos a crear un debit, ¿vale?
Para tener aquí...
Ah, y os enseñé otro día un trucazo.
Y voy y no lo uso.
Hay que ver, yo también.
Vale.
Vamos a mover todo esto, ¿vale?
A ver si aquí es por default, function, debit.
Y el debit, pues aquí tenemos bastante claro lo que es la ID.
De hecho, nos podemos copiar, ¿no?
De todo lo que tenemos en el endpoint.
Porque, total, tenemos el avatar, tenemos el username, tenemos el message.
Y tenemos la ID.
¿No?
ID, sí.
Aunque la ID, como tal, un, dos, tres, cuatro.
La ID aquí...
Bueno, luego, para hacer el link, para hacer el link sí que lo vamos a facilitar.
Vale.
Así que lo dejamos ahí.
Pero aquí, aquí lo que haremos es debit...
Que mira, lo voy a importar ya.
La key, seguiremos utilizando esto.
A ver, aquí...
Esto lo he comentado unas cuantas veces.
Y ahora os lo explico.
A ver, ¿por qué prefiero hacer esto?
O ¿por qué debería hacer esto?
En lugar de...
Message, debit.message y la ID, debit.id.
Vale.
Aquí mucha gente diría, ostras, pues si tienes que pasar eso, ¿por qué no haces esto?
¿No?
Y esto lo que haría sería enviar todas las propiedades de debit, ¿no?
Pero, ¿qué pasa con esto?
Que si hacemos esto, cada vez que se renderice este componente, el componente de la homepage, por lo que sea,
lo que estamos haciendo aquí es crear nuevas props.
Y además que le estamos enviando props que no estamos controlando.
Y si, por ejemplo, tuviésemos un memo, no sabríamos con exactitud que le está llegando.
Imaginemos que en la API no solo tenemos estas cuatro, sino que tenemos un montón y que tendremos más.
Pues, claro, no estaría muy bien como lo estábamos controlando y le estaríamos enviando información.
Y aunque esas props nosotros no las vemos al componente, puede inicializar un render sin que nosotros lo controlemos.
Lo que podemos hacer, si esto es bastante molesto, por ejemplo, pues sería hacer aquí la desestructuración del avatar, del message y el id.
Y en lugar de utilizar el debit, pues tenerla así.
La verdad es que sí que...
Ay, lo he hecho ahí de la he puesto dos veces.
Esta podría ser una.
Aquí ordenamos los props y nada, todo fantástico.
De hecho, esto lo podemos quitar.
Al menos por ahora.
No sé si para adelante nos puede dar algún problema.
Esto así.
Y así se queda como más mejor.
De hecho, esto lo sacaremos también.
Esto es ahora que estamos haciendo esto un poco como para adelantar, ¿vale?
Para adelantar.
Así que, una vez que hemos extraído esto, sacamos esto del fragment.
También, si utilizamos esta JSX, siempre no, pero casi siempre lo vamos a tener que hacer.
Una cosa que me gusta mucho de cuando sacamos esto del import es que ahora esto te lo puedes copiar y te lo puedes llevar directamente sin preocuparte de los imports relativos y tal.
Así que esto es maravilloso.
Esto, todo este debit a la sobra.
Y aquí ahora vamos a traer el JSX que teníamos aquí.
Aquí teníamos el header, lo vamos a dejar.
El article, este es el que nos tenemos que traer.
De hecho, solo tenía aquí el article.
O sea, solo he destilado el article por ahora.
Bueno, está bien.
Vale.
Entonces, este section, porque aquí...
Bueno, vamos a poner aquí el div, ¿vale?
Vamos a poner aquí el div.
Y en lo que es el contenido lo vamos a dejar con un section y seguramente le pondremos algún área y tal.
Ahora este div.
Esto es una de las cosas que a mí me gusta mucho del tema del style JSX.
El hecho de no necesitar pensar en, por ejemplo, ningún tipo de class name, ningún tipo de nombre.
O sea, este aquí sobra también.
Que me lo ha archivado ahí Nicolás Santis, que está súper atento.
No me he fijado muy bien en cuál es el espacio que hay aquí.
Y hay 10.
Vale.
Pues le he puesto 8.
Está o cerca.
Vale.
Más o menos.
Y esto...
Esto es porque la P, que es el párrafo, pues...
O sea, a lo mejor deberíamos también copiarnos aquí a saco linehaze.
En linehaze...
Y...
Bueno.
Por ahora vamos a copiarnos esto.
Vale.
El tema es que ya va tomando forma.
Además, aquí en nuestro article, creo que esto tiene aquí como dos píxeles de algo.
Parece como un color, como un azul.
A ver.
No sé si...
A ver, lo voy a poner y...
Ahora lo arreglo, ¿eh?
Este es mi color que me gusta, pero ahora lo arreglo.
Aquí vamos a poder mirar.
Esto no sé si lo sabíais, pero es la bomba, ¿eh?
Le podéis dar a este cuadrito con el color y entonces os sale...
Ay, ahora no le doy.
Aquí.
Y os sale esto para...
Creo que es un azul como muy clarito.
Es una cosa como así.
No sé.
Así.
Vale.
Ese...
Ese está bien.
Si no, ya lo cambiaremos.
Y ya lo añadiremos.
Bueno.
A ver.
Todavía nos queda, ¿vale?
Todavía nos queda.
Ay, claro.
Esto...
Esto lo tenemos que arreglar.
Claro, cuando está en modo...
Cuando esto está en modo tal, muy bien.
Pero esto...
Esto es porque el...
Seguramente el relative...
Eso lo tendremos que arreglar.
Porque el relative...
O no lo he...
Sí, sí, lo he puesto ahí.
Sí que lo he puesto ahí.
Pero...
O sea, a eso se le va.
Se le va.
Se le va.
Vamos, que sí se le va.
Ay, que es súper raro, ¿no?
O sea, a ver.
Si el relative está aquí.
Y el fix...
Bueno, si lo veis, me lo comentáis, ¿eh?
A ver.
Mientras os voy a ir leyendo.
A ver que me comentáis, ¿vale?
¿Se puede usar este JSX con React o es solo cosa en XDS?
Se puede utilizar este JSX con React, pero tienes que instalarlo, ¿vale?
O sea, y tienes que configurarlo y tal.
A ver.
Yo no lo recomendaría.
En el sentido de que tienes que instalarlo, tendrías que instalar un plugin de Babel, ¿vale?
Un plugin de Babel.
Y ya utilizarlo en tus componentes de React.
Y eso al final te generaría el CSS y todo esto.
Pero creo que está bien en Next.js porque ya viene fuera de la caja.
Pero no sé hasta qué punto vale tanto la pena en un proyecto que estés empezando.
Yo seguramente utilizaría en un proyecto que estoy empezando Style Components.
Que ya lo vimos en un vídeo anterior, ¿vale?
Pero este soy yo.
Este soy yo.
Si lo quieres probar, lo puedes probar.
De hecho, mira.
He abierto aquí el...
He abierto el Style JSX en GitHub.
Y aquí lo tendrías, ¿vale?
Y aquí tienes Started.
Solo es instalarlo.
Aquí añadirías el tema de Babel y ya lo utilizarías.
Claro, aquí esto parece como súper fácil.
Pero, ¿qué pasa?
Que si luego quieres todo el tema de Serversal Rendering y tal, no lo pone aquí.
O me sorprende que no ponga absolutamente nada.
Render...
Ah, claro.
Tienes que hacer más trabajo, ¿vale?
O sea, no es difícil dentro de los paradigmas dentro de CSS en JS.
Y de hecho está bastante bien resuelto.
Pero tienen que hacer más cosas, ¿vale?
En NextDS esto lo tienes resuelto fuera de la caja.
Pero ten en cuenta si quieres tener Serversal Rendering, que tienes que hacer esto y que otras cosas hay que tener en cuenta, ¿vale?
Yo seguramente por ese esfuerzo ya tiraría por el Style Components, que a mí me gusta bastante más la API.
Klaus.
Muchas gracias.
Buena forma de explicar.
Saludos desde Ecuador.
Es verdad.
El Position Fix es relativo al Viewport, dice Ferdinand.
Efectivamente.
Efectivamente.
Es que no he puesto un Position Absolute.
Muy buena esa.
Claro.
Es que...
Es que...
Claro, digo...
Irrelative y tal.
Muy bien.
Efectivamente.
Lo que podríamos intentar utilizar...
No sé si podría.
Pero no sé si lo conocéis.
Es el Position Sticky.
Si no, tendremos que ver qué hacemos con esto.
Claro.
Cuando es súper pequeñito queda bien porque todo el Viewport es el que es, ¿no?
Y no hay nada.
Entonces, una cosa que podríamos intentar, a ver si funciona, ¿vale?
Es el Position Sticky.
Vamos a probar eso antes de irnos a la casa.
Vamos a ver.
En Home, ¿no?
Lo tenemos aquí.
Vamos a probar, vamos a probar.
Position, todo, todo.
En lugar de Fix, vamos a poner Sticky.
A ver si tenemos suerte.
Y esto funciona.
Vale.
Sí, sí.
Sí que funciona.
Ah, no.
Bueno.
Funciona.
Ah, bueno.
Pero esto ya es otro tema, ¿no?
Este es otro tema porque esté Sticky.
Claro.
El Section como tal tendría que tener todo el alto.
Esto tenemos que ver cómo lo arreglamos.
Pero todavía no se queda donde lo queremos.
El de arriba, sí.
El de arriba ya lo tendríamos arreglado con el Position Sticky, que además está muy bien.
En este caso, sí, cuando seguimos bajando, sigue estando.
Vale.
Pues este podría ser una solución.
También es verdad que cuando llegamos a este punto, el hecho que esté ahí, bueno, lo podemos arreglar.
Pero con este, con el Sticky, aquí sí que lo solucionaría.
Tendríamos que mirar el de abajo, que el de abajo no lo ha hecho, no lo ha solucionado.
Pero esto, si eso lo miramos para...
Ah, que, Position Sticky, Position Sticky, el Bottom.
Además, el problema que tiene el Position Sticky, que es súper interesante, porque es parecido a un Fix.
Lo que pasa es que si el Padre Overflow Hidden, no funciona.
Si esto y lo otro, no funciona.
Es bastante puñetero.
Pero bueno, por ahora vamos a centrarnos en este y veremos a ver cómo solucionamos esto del Position Sticky
para el inicio de la siguiente clase.
Y así lo dejamos aquí con un problema que, además, os dejo de deberes.
Porque si encontráis una solución para maquetarlo bien, se aceptan PRs.
Y si tenéis una solución que vaya bien con esto, para dejar esto fino fino,
pues ya sabéis que os recomiendo, o bueno, os recomiendo no, os invito a que vayáis aquí a GitHub.
¿Vale?
Me podéis buscar como Midudev y me podéis seguir para estar informados de cada vez que voy haciendo cositas.
¿Vale?
Así que aquí.
Me podéis encontrar aquí como Midudev.
¿Vale?
Si me podéis seguir y tal, le dais aquí, creo que está por aquí el follow.
Y si no, pues podéis ir directamente al curso Next Yes Twitter Clone.
Y aquí, pues ya sabéis, os bajáis la rama en la que estamos.
Esta va a ser la 03.
Añadiré aquí la clase, el código y tal.
Y podéis, pues nada, enviar vuestra solución para este reto que nos deja la clase de hoy,
que ha sido bastante interesante.
Al final, dos horas y cuarto, ¿eh?
Hemos estado, y estamos 142.
Madre mía.
Si no estás suscrito, de estos 142 valientes y que están aquí, pues estoicamente,
pues si todavía no estás suscrito o suscrita y estás viendo el canal, te invito a que te suscribas,
le des, por supuesto, un like muy grande, así, más o menos, así, bueno, espera que no se ve en pantalla,
así de grande, ¿vale?
Que le des like, que lo compartas con tus amigos, que dejes un comentario de,
oye, gracias, Midu, me ha encantado.
Que espero que lo paséis muy bien.
Yo me voy mañana de vacaciones a disfrutar de la playa.
Espero venir un poquito más oscuro, ¿vale?
Que estoy muy, muy blanquito.
Y os agradezco de corazón a todos y a todas que habéis estado por aquí un ratito,
aunque haya sido un ratito, aunque sea para saludar, ¿vale?
Os lo agradezco de corazón, como siempre.
Así que voy a saludaros, así que si queréis ir diciendo adiós en el chat,
os voy diciendo.
Muchas gracias, Ferdinand, por tu ayuda, por el logo, ¿vale?
Gracias, Crack.
Dice David, dice David Iguita que cree que el position fix puede variar
si algún padre tiene alguna transformación.
En este caso es lo que dice Ferdinand, ¿eh?
El position fix es relativo al viewport.
Hay que encontrar otra solución para hacer fijo eso.
O no hacerlo fijo.
Puede ser otra solución, ¿eh?
Si vemos que se complica, no lo hacemos fijo.
Y ya está.
Lo hacemos ahí con un position absolute.
Cuando está en ese viewport, y ya está.
Tampoco nos volvamos locos.
Si la gracia está en que en móvil sí que te sigue.
O a lo mejor podemos hacer que la barra de abajo se ponga a la izquierda,
que eso creo que lo hace Twitter, ¿vale?
No nos preocupemos.
Vamos a encontrar solución.
Todo tiene solución en esta vida.
Fernando, que dice, ¿cómo estás, Messi en Frontend?
Tienes que hacer vídeos sobre Cypress.
Fernando, haremos vídeos sobre Cypress.
Y vamos a hacerlo en esta serie de vídeos, ¿vale?
¿Te parece?
Vamos a hacer test en tu end con Cypress para al final,
cuando ya tengamos nuestra aplicación, para probar nuestras cositas.
Cristian, sois crack.
Excelente manera de explicar.
Gracias.
Gracias a ti, Cristian, por pasarte.
Cristian del CIR, gracias maestro, me dice.
Gracias a ti, hombre.
Daniel Soto, adiós, adiós.
Adiós, Daniel Soto, Jaimes.
Disfruta las vacaciones, Sergio.
Gracias, y gracias por tu superchat también otra vez, Joan Rueda.
Adiós, adiós.
Adiós, Juan, adiós.
Muchas gracias por pasarte.
La semana que viene hay directo.
Sí, el viernes de la semana que viene hay directo.
Y vamos a hacer ya el...
Bueno, arreglaremos esto del sticky.
Ya veremos cómo lo hacemos.
Va a ser un momentito.
Ya veréis.
Porque, como os digo, si por lo que sea nos da mucha guerra,
lo que hacemos es que cuando no sea el viewport,
movemos el nap bar, lo movemos a la izquierda y ya está.
Y la parte de arriba desaparece.
Y punto.
Tampoco hay que volverse loco.
Así que no nos preocupemos.
Nicolás Antic, gracias.
Midu, Michael Soro, gracias.
Disfruta mañana.
Suárez, me dice Nicolás.
Adiós y gracias, Tony.
Gracias a ti.
Gracias, superfien.
Dice Josep Romero.
Adiós, Miguel.
Gracias, Josep.
No falles al siguiente.
Espero que estén muy bien.
Increíble clase.
Gracias.
Disfruta de vacaciones.
Gracias, Ferdinand.
Presente desde la DIP.
Omar Arturo.
Linux.
Pues, ya vamos.
Madre mía.
Gracias, Frontender.
El mejor, Cristian.
Frontender sois todos.
Todos somos Frontender.
¿Vale?
Pues muchísimas gracias a todos.
Gracias, Enrique Fioritzi.
Nos vemos.
Fernando, gracias por la clase.
Klaus, gracias a ti.
Llegué tarde para una consulta.
Siempre hay tiempo para una consulta.
Hacer unit test.
En realidad, que es para un reto, una oferta de trabajo.
Se puede hacer unit test.
Y, de hecho, tienes vídeos en mi canal para hacer unit test con React Testing Library.
Así que te recomiendo que busques React Testing Library, MiduDev, y vas a verlo.
¿Vale?
Muchas gracias a todos por estar aquí.
Nos vemos en las redes.
Y estamos en Twitter, en Instagram, que voy a poner fotos de la playa y del mojito que os debo.
Muchas gracias de corazón.
Cuidaos mucho.
Y nos vemos el viernes que viene con más Frontend.
Aquí, en MiduDev.
Hasta la semana que viene.
Chao, adiós, adiós, adiós, adiós.