Vamos a hacer una cosa que está muy chula, porque muchas veces mucha gente me dice
quiero ser senior, estas típicas cosas que me dicen, y hay una cosa que la gente no sabe
de cómo crear errores, cómo crear errores en condiciones, quiero decir, claro, o sea,
porque imagínate que tienes un error, mira, errores como un prop, bueno, ha ganado el error como un prop,
vamos a hacer esto, ¿no? Imaginad que tenemos aquí un validate user, yo qué sé,
y aquí tenemos el name, el age, el email, ¿ok? Y tenemos if name y la gente hace este,
throw new error, name is required, por ejemplo, ¿no? Si no tenemos nombre, si no tenemos el age,
throw new error, age is required. Y no está mal, o sea, no está mal, porque al menos
estás haciendo un throw del error, o sea, no está mal, no está mal, ¿no?
Pero os voy a enseñar cómo hacerlas como un pro, cómo hacerlas bien, porque muchas veces
esta es la forma como más, bah, hago un error de cualquier forma, que no está mal, ¿eh?
De nuevo, no está mal, no está mal, pero se puede mejorar. Por ejemplo, ¿qué se puede hacer aquí?
¿Por qué? Porque si yo hago el validate user, ¿vale? Yo hago el validate user,
y vamos a ponerle aquí que por defecto tiene esto, ¿vale? Validate user.
Dice, error name is required. Claro, si tú por lo que sea quieres hacer aquí un try catch de esto,
un try catch o lo que sea, ¿eh? Pero imaginad que queréis hacer esto, queréis controlar el error,
queréis controlar el error. Claro, type of, error name is required. Si miráis el instance of,
esto va a decir, hostia, instance of, ¿esto no es así? Instance, ah, ¿es así? No, ¿cómo es el instance of?
Ah, no me sale. Un expected token, la madre que me trajo, ¿no era así? Instance of, ¿en JavaScript?
Ah, pues sí lo he puesto. Ay, es que no es así. Ay, es que es, es que esto es el type of,
esto es como funciona el type of, la madre que me trajo. No, el instance of, lo que tienes que hacerlo
es así, ¿no? Tienes que decir, instance of, y aquí decirle de qué es la instancia, ¿no?
Entonces, aquí vamos a tener que es de error. Nos va a decir, el error este es una instancia
del tipo error. Nos va a decir que es true. Pero fijaos que no da mucha información, ¿no?
No nos dice, por ejemplo, oye, yo qué sé, no es muy útil. No es un error muy útil.
Muy útil a muchos niveles. Entonces, una cosa que es bastante básica en JavaScript,
y en JavaScript y muy poca gente conoce, es el hecho de que en realidad puedes crear
tus propios errores en JavaScript. Y lo puedes hacer bastante fácil dentro de lo que cabe.
Porque lo único que tienes que hacer, y esto es importante, mira, mucha gente me dice
Clean Architecture y tal. Pues mira, en Clean Architecture podrías hacer este tipo de cosas.
Puedes hacer este tipo de cosas. Lo que puedes hacer es crear una clase.
Y le puedes, class, vamos a poner aquí validation error, por decir algo.
Y extendemos el error. El error ya es una clase que está disponible
y que ya la podemos extender. Podemos ponerle aquí el constructor
y le podríamos pasar un montón de cosas, pero le puedo pasar el mensaje, ¿no?
Y llamamos a super, que super es para llamar al constructor
de la clase de la que estamos extendiendo, del error.
¿Vale? Y aquí podemos poner, yo qué sé, this name,
y le cambiamos el nombre del error. Vamos a poner aquí validation error,
el mismo nombre que le estamos poniendo.
Y aquí es que al final puedes hacer un montón de cosas,
pero es que solo con esto, solo con esto, ya lo que podemos hacer aquí
es, en lugar de hacer el new error, ya podemos tener el validation error.
Aquí ya es un error diferente. Y además lo que podéis hacer es
instance of validation error, o sea, podríamos empezar a chequear mejor
este tipo de error. O sea, decir, bueno, si es un error de validación,
mira, validation error, ¿ves? Validation error, name is required.
O sea, ya te está dando una información extra.
Oh, es el nombre de validation error. Imagínate que también el validate user,
tenemos también aquí, llamar a la base de datos para guardar el usuario, ¿no?
Imagínate que aquí, por lo que sea, pues no funciona.
No nos, no, hacemos un throw new, podemos poner connection error,
connection error. Database is not available, ¿no?
Y tendríamos este mismo, claro, esto lo podéis exportar,
luego podéis tener un fichero errores, que tengáis ahí todos los errores,
pero podéis tener aquí connection error, connection error.
¿Y por qué esto es importante? Ahora lo vas a entender.
¿Por qué esto es importante e interesante? Imagínate que tienes dos aquí, ¿no?
Y ya tenemos el connection error y el validation error.
Claro, imagínate que yo aquí, digo, hago un try-catch.
Y esto, sobre todo, suele ser muy útil para código asíncrono.
Porque así puedes saber por qué ha fallado y dependiendo de por qué ha fallado,
pues hace diferentes cosas.
Validate, joder, déjame. Vale.
Tú una vez que haces esto aquí, puedes hacer diferentes cosas.
Puedes. Uno, podrías decir, vale, si el error name,
no, el error name, sí, era el error name.
A ver, sí, el error name.
Uno, puedes utilizar esto.
Podrías utilizar esto, ¿no?
Si es connection error, pues podrías decir, yo qué sé,
pues podrías hacer un retry, por ejemplo.
Retry, por decir algo.
Retry porque ha sido de la base de datos.
Entonces, tiene sentido que hagas un retry validate user.
Yo qué sé.
O intentas, podrías hacer aquí, retry after a few seconds.
Entonces, no sé, para que te hagas a la idea de por qué es importante.
Y dices, vale, vamos a hacer el validate user con la misma información,
name, yo qué sé, age, email.
Vamos a hacerlo con la misma información que lo hemos hecho aquí arriba.
¿Por qué?
Porque en realidad el error que hemos tenido no ha sido porque estaban mal los datos.
Ha sido porque hemos tenido un connection error.
Y aquí podríamos decir, bueno, si ha sido por la validación del usuario,
¿no?
La validación del usuario, entonces, pues, oye, vamos a mostrar show UI modal validation,
¿no?
Haríamos otra cosa totalmente distinta.
Porque una es, oye, ha fallado la validación de los datos y otra sería la del connection error.
Esta es una forma de hacerlo con el e.name.
Obviamente, el e.name es un string y ya sabes lo que pasa con los strings.
¿Ves?
Ah, no, me ha dado un reference error.
¿Por qué?
Ah, porque le he pasado aquí el name, age y eso está mal, ¿vale?
O sea, como les he pasado estos, name, esto, name, esto, o sea, midu, age, vamos a poner
aquí 27, que es mi edad real, y miduga, arroba, hotmail.com, ¿vale?
Bueno.
¿Ves?
Dice, vale, connection error.
¿Por qué?
Porque el validation sí que lo ha pasado.
Los datos que hemos pasado de validación están bien.
Vale, perfecto.
Si le hubiera pasado aquí el null, pues me hubiera dicho validation error.
O sea, al menos, esto es súper importante por dos cosas, por dos motivos.
Y espero que esto os ayude para que entendáis bien esto.
Uno, lo primero es que no estamos permitiendo, esto es súper, es que esto es súper importante.
A ver, os voy a explicar una cosa, ¿vale?
¿Tú quieres ser buen programador?
¿Tú quieres ser buen programador?
Pues entiende, abre tus orejas ahora mismo, ¿vale?
Ábrelas.
Mira, muchas veces, sobre todo en JavaScript, porque en JavaScript no se le pone hincapié
a esto, hay una muy mala práctica que ocurre en mucho lenguaje de programación, pero especialmente
en JavaScript.
Y es el hecho de permitir que los errores de infraestructura lleguen al cliente.
¿Qué quiere decir esto?
Lo que quiere decir es que tú imagínate que tienes un error en el que no funciona la base
de datos, ¿vale?
Esta base de datos.
Esto de aquí, ¿no?
Imagínate que aquí hacemos un try-catch y tú tienes aquí una base de datos, llámale
MongoDB, llámale como tú quieras.
MongoDB, ¿no?
MongoDB, connect, no sé qué, no sé cuánto, ¿vale?
Haces un try-catch, esto te da un error y haces esto.
Haces o un return del error o haces un console del error.
Haces algo así, ¿ok?
Esto es una mala práctica porque realmente lo que estamos haciendo aquí es escupir el error
de infraestructura y pueden pasar miles de cosas.
Lo primero es que puede tener, obviamente, graves problemas de seguridad.
O sea, estamos diciendo, no, ha sido un error de MongoDB que un usuario o un cliente pueda llegar a ver
que ha habido un problema de nuestra base de datos y que le ponga claramente la base de datos, ¿sabes?
Eso es un error de seguridad muy grave.
Y es que, además, tampoco lo necesitas saber.
Tampoco lo necesitas saber, saber todas las entrañas, saber todo.
No lo necesitas saber.
Entonces, lo que hay que hacer en este caso es, este error lo podríamos enviar,
enviar traza original a un servicio nuestro o lo que sea, ¿vale?
Lo que sea.
Pero, ¿sabes?
Send, beacon, error, e, ¿vale?
Pero a un sitio que sea nuestro.
Nunca jamás lo vamos a enviar ni al cliente.
Y a la consola, en el cliente tampoco tiene sentido, ¿vale?
En la consola tampoco tiene sentido.
Eso por ahí.
Y luego, también tiene sentido que lo que hagamos es tratar los errores mejor.
En lugar de tratar con un error que, claro, hago este catch, hago otra vez,
throw e, throw e, ¿sabes?
Envío otra vez el error, esto tampoco tiene mucho sentido.
Lo que tenemos que hacer es decir, ostras, este error, ojo, lo manejo,
lo manejo, lo encapsulo para yo entenderlo.
Le digo, vale, este error que tengo es un error de conexión.
Y ahora, cuando tú trates esto, lo que vas a decir es, vale,
pues ahora, si el error es de conexión, hago algo.
Si el error es de validación, hago otra cosa.
Como os decía, el e.name es un contrato débil.
¿Por qué los contratos son débiles?
Porque son strings, que luego veremos con TypeScript, a lo mejor puede tener sentido.
Pero lo mejor que podéis hacer sería algo así.
A ver, midufest.com, vamos a poner esto por aquí,
para que veáis más o menos con un proyecto real cómo sería el tema, ¿vale?
Imaginad que aquí en source, pues tenemos, yo qué sé, UI.js, por decir algo.
Vale, vale.
Bueno, es que claro, esto ahora me va a poner aquí un millón de historias de problemas y tal.
Pero bueno, no pasa nada.
Tenemos ahí la UI, tenemos aquí los errors.
Vale, quitamos esto.
Export.
Esto hago ejemplos reales, ¿eh?
No está mal, ¿eh?
Vamos a hacer ejemplos reales un momento.
Vale, tenemos los errores.
Tenemos la UI, que sería esta parte de aquí.
Y tenemos aquí validations, por decir algo.
Validations, creo que lo he hecho bien.
Vale, y aquí exportamos esto.
¿Cómo funcionaría esto?
Lo que funcionaría es que donde tú tengas este método,
tú lo que haces es importar aquí el validation error, ¿vale?
Y lo importaríamos así.
Bueno, esto lo vamos a comentar.
¿Vale?
Tú ya podrías traerte el error y decir,
InvalidationError o InvalidationError.
Tú ya tendrías como una colección de errores aquí.
Que en este caso sería así.
Puedes incluso hacer una factoría de errores.
Vais a aprender mucho en un momento, ¿eh?
O sea, podéis crear una factoría de errores,
porque a lo mejor esto es un poco complicado.
Pero podéis crear, por ejemplo,
Create, o sea,
CreateErrorFactory.
Le podéis pasar el nombre,
el nombre
y el mensaje, ¿no?
Teníamos...
Es que podéis hacerlo de dos formas.
Estoy pensando, ¿eh?
CreateErrorFactory.
Bueno, vamos a hacer como me dice XHACOPAIL, ¿vale?
Y aquí lo que podrías hacer es poner
este class, no sé qué, no sé cuánto.
Esto por aquí.
ConnectionError.
Aquí le ponéis
CustomSizeError o...
Bueno, vamos a poner así.
Vale.
Y aquí el CreateErrorFactory
podrías hacer
ExportConstConnectionError.
Y así podríais empezar
a crear errores mucho más fácil.
Y ya lo tendríais.
Podrías hacer algo así.
Podrías hacer
CreateConnectionError.
CreateValidationError.
Y así, pues, lo que podéis hacer
es decir, vale,
cuando quieras crear un error,
pues le pones aquí el error, lo que sea, ¿vale?
Ah, mira, BusinessError.
Me gusta ese nombre.
BusinessError.
Pues podéis hacer esto, ¿vale?
O si no, es que a ver,
esto tampoco tiene mucho sentido.
O sea, esto
solo podemos quitar de aquí.
Le hacemos esto,
que devuelva directamente la clase.
Y aquí le dejamos esto
y ya está.
Y es que así vais a hacer
el ThrowError
perfectamente,
sin ningún problema, ¿vale?
Y, claro,
el problema es el this.
O sea, que aquí
necesitamos utilizar el function, ¿vale?
Pero bueno,
ya está.
Sería así.
Vale.
Con esto,
es que, claro,
si no alguien me dice,
bueno, pero voy a tener que poner,
crear una clase para crear error.
Bueno, no hace falta.
Creas esto,
dices, vale,
ConnectionError,
ValidationError.
Y con esto,
pues, ya podrías empezar a hacer esto
y utilizar el name.
Esta podría ser una forma, ¿vale?
Utilizarlo con el,
bueno, aquí,
esto sería el name, ¿vale?
Ya está.
Esta podría ser una forma,
pero bueno,
no pasa nada
a veces por repetir el código.
No pasa nada,
que es que hay gente
que a veces le da un poco
de, ah, Dios,
repetir el código.
No pasa nada.
Esta podría ser una forma,
pero también podríais
dejarlo como estaba, ¿vale?
Que no le pasa nada.
Imaginad que tenemos esto, ¿no?
Además, aquí tendríais
la instancia justamente
con el nombre perfecto.
O sea, que estaría bastante bien.
Lo que podéis hacer con esto,
una vez que tenéis aquí
las validaciones
y además que lo importáis así
directamente,
lo que podéis hacer aquí,
ya ves,
aquí os traéis por un lado
los errores,
el validation error
y además el,
aquí exportamos esta
validate user
y ya está.
Entonces,
cuando tengamos aquí
el name midu,
el age 30,
cabrón,
el email
y aquí lo dejamos vacío,
por ejemplo.
Bueno,
pues aquí tenemos el problema
del validation error
porque el email es vacío.
Y aquí,
en lugar de utilizar
el string,
como podemos traernos
la instancia,
o sea,
la clase,
no la instancia,
la clase,
aquí lo que podemos preguntar
en lugar de utilizar el string,
si importamos el error,
es decir,
si
instance of
connection error
y puede quedar bastante mejor
porque así lo que estáis haciendo
es,
os vais a asegurar
que el nombre que utilizáis
es exactamente,
exactamente el correcto.
Entonces,
no tenéis que,
no tenéis que preocuparos
de un string
o lo que sea.
Así lo teníais,
así lo teníais,
lo tendríais,
vamos.
Estáis manejando bien los errores.
¿Por qué?
Porque los errores tienen nombre,
tienen entidad,
tienen sentido,
o sea,
tienen un montón de cosas.
De hecho,
una cosa bastante chula aquí
en los errores,
porque los errores al final
también se le pueden poner
un montón de cosas.
Por ejemplo,
imagínate que el validation error,
por lo que sea,
no quieres que tenga stack.
Podrías poner
this.stack
y aquí le podrías poner
vacío,
¿sabes?
Para sobreescribir
que ponga el error
con el stack.
Así lo podéis quitar,
le podríais quitar el stack.
El stack es
cuando hay un error
que te sale
todos los errores
ahí en la línea.
Te dice la línea y todo,
pues lo podríais evitar,
podríais decirla,
vale,
pues este stack lo quitamos.
Como veis,
es bastante útil
y tiene un montón de cosas.
¿No sería una instancia
de business error?
Bueno,
en este caso no,
porque lo hemos cambiado,
le hemos tirado para atrás
todo el código.
Por eso decía,
lo vamos a quitar
para utilizarlo en la instancia.
¿Midu,
en caso de tener varios casos,
¿no sería mejor un switch?
Podría ser.
En este caso,
yo he utilizado solo dos,
pero si...
A mí,
yo la verdad,
no soy muy fan de los switch.
Es una construcción
que no me gusta.
Prefiero utilizar
if que no los switch.
Eso soy yo,
porque no me gustan.
Y si tuviese que utilizar
un switch,
al final lo que llegaría
es utilizar un objeto.
¿Por qué?
Porque aquí lo que podrías decir
es
errors,
errors map
o handling.
Haría esto,
vale,
cuando es un connection error,
pues vamos a hacer
un set timeout.
Haría básicamente esto.
Y aquí le pasaría...
Le podría pasar
todos los...
Bueno,
le vamos a poner
name,
age,
email.
O sea,
que podríamos hacer algo así.
Cuando tengo el error handling,
pues nada,
le pasamos el...
El...
Ah,
claro,
porque tendríamos que hacer el...
Bueno,
claro,
esto sería con el nombre,
por ejemplo.
Esto sería con el nombre.
Pero con el nombre
podríamos pasar esto
y ya lo harías todo en una
y ya lo tendrías,
¿eh?
¿No sería mejor
hacer un object.set prototype
this.error prototype?
No,
joder,
no.
O sea,
tú lo que quieres
es crear un error,
no crear,
no cambiarle una propiedad
del error.prototype.
O sea,
no tiene sentido,
no hagáis esas cosas,
tío.
O sea,
es que además
no toquéis los prototypes,
nunca toquéis los prototypes.
Es una de las cosas
más guarras
que se pueden hacer
en JavaScript
y es verdad
que eso es culpa
de JavaScript
de que te lo permite hacer
pero no lo hagáis
porque al final
si lo podéis extender
y con un código
que se entiende,
o sea,
no tendréis ningún problema.
Mido,
en caso de app movible
¿cómo manejar esos logs?
Guardarlos en archivos planos
o una tabla.
Como tú quieras,
lo puedes enviar
a un proyecto
y ya está.
Joder,
ha sido lo que he preguntado
el Switch
y la opción que has dado
me parece cojón una,
gracias.
Bueno,
a ver,
que si queréis utilizar Switch
me parece fantástico,
¿eh?
No pasa nada.
Si queréis utilizar Switch,
pero bueno,
los diccionarios
a mí me suelen gustar bastante.
Te quita todo esto,
quitas todos los if
y queda como mucho
más declarativo.
Incluso puedes hacer
que tenga un caso
por defecto.
O sea,
si el ename
no sé qué,
no sé cuánto,
puedes hacer
mira,
handler,
que tiene sentido,
haces esto.
Si dices
handler,
si tienes handler
pues lo utilizas
con el name,
el each,
email
y si no,
pues pones default handler
o no hacen nada.
Haces un null.
Pero puedes tener un default
si quisieras,
¿vale?
Bloquear los protetimes
es otra cosa
que puede ir a
Stricted Mode.
Totalmente de acuerdo.
El contenido que haces
es genial,
pero apenas estoy empezando
en RIA
que me pierdo
al ver muchas cosas.
Bueno,
pero no te preocupes
porque lo importante,
lo importante,
lo único importante
que tienes que tener en cuenta
es esto.
Lo importante es
que puedes,
que no lo sabe mucha gente,
extender del error
en JavaScript.
Esto lo puedes hacer.
que siempre que podáis
en lugar de hacer esto,
throw new error,
bla, bla, bla,
lo que tenéis que hacer
es throw new error,
o sea,
throw new validation error,
ta, ta, ta.
Ya está.
Ya está.
Hombre,
a ver,
no toca los protetimes.
Si es por no complicarse,
vale,
pero ECMA hace básicamente
eso por debajo.
JavaScript se basa en prototypes
y lo de ECMA es magia.
Si quieres conocer
JavaScript en profundidad,
conocer y tocar los protetimes,
es sanísimo.
A ver,
hace eso por debajo.
A ver,
no hace exactamente,
no toca el prototype
por debajo exactamente.
Lo que hace es extender,
o sea,
por ejemplo,
aquí cuando creas una clase,
lo podemos mirar,
usa los prototypes,
pero no modifica
el prototype de error,
que es lo que estamos hablando.
Vale,
son dos cosas diferentes.
En realidad,
las clases son azúcar sintáctico
para utilizar los prototypes,
porque ya sabéis
que JavaScript está basado
en prototipos
y no orientación de objetos.
Pero,
pero,
una cosa es tocar los prototypes
como vamos a crear y extender
a modificar los que ya existen.
No hagáis eso.
O sea,
de eso se trata,
de evitar tocar los prototypes
a ese nivel.
Yo inicie a seguir a Midu en mayo
y no entendía nada de React,
pero después,
estudiando con el tiempo
poco a poco,
va tomando sentido.
Bueno,
me alegro.
Sería buena idea
añadir un campo en la clase
que indique qué campo
ha dado error de validación.
Claro,
eso lo puedes hacer
sin ningún problema.
Puedes hacer lo que te dé la gana aquí.
O sea,
podrías tener aquí,
por ejemplo,
GetFieldName.
Podrías empezar a extender
lo que te dé la gana.
Eso lo puedes hacer
sin ningún tipo de problema.
Así que,
por eso se dice
que JavaScript no tiene clases.
A ver,
es que esto,
esto que veis aquí,
mira,
lo vais a ver muy claro.
Vape.
Menos mal que no ha salido
nada raro.
Menos mal que no ha salido
nada raro.
Babel Playground,
no Vape.
No sé qué estaba pensando,
perdón.
Vale.
Esto lo podéis ver muy claro
aquí,
si ponéis IE11.
¿Vale?
Hostia.
Igual se ha pasado.
Igual se ha pasado
en la manera que lo pareo.
Pero aquí lo podéis ver
más o menos.
Que aquí lo que está haciendo,
¿ves?
Es que está creando un super...
Es que claro,
es que es difícil
porque create class...
Pero bueno,
al crear una clase
lo que está utilizando
es el prototype.
Está utilizando el prototype,
definir todos los métodos
que tiene el prototipo
y tal
y extender de la clase
que le has dicho.
Esto es lo que hace
por debajo
parecido
JavaScript.
A la hora de crear una clase
en realidad
no tiene el concepto de clase,
tiene el concepto de prototipos.
Y por eso aquí por debajo
estaría haciendo algo parecido
que no exactamente igual
a lo que veis aquí
en todo este código.
Y eso sería la idea.
Esta vez lo he puesto
en Internet Explorer 11
para que haga la transformación
porque si ya lo soporta
pues no va a tener soporte.
A ver si...
45...
Pero bueno,
ya veis aquí.
Define properties.
Entonces ya lo hace
pero no estamos tocando
el prototipo de error
que es lo que me refiero
que sería mala idea.
¿Vale?
Vi el vídeo de que usar
en lugar de switch
pero en lugar de cada case
lleva código de más
de una línea
como en tu ejemplo.
No sé cómo hacerlo.
Pero a lo que me refería
era hacer...
De esa manera
asignarías a tu clase
la instancia.
Pero es que tampoco
le veo ninguna necesidad
y va a...
Pero a lo que me refería
era
oje.septprotective
of this
myerror.prototile.
De esa manera
asignarías a tu clase
la instancia.
Pero es que no entiendo
cuál es la necesidad
que tienes
si lo creas así.
O sea,
tú haces esto.
¿Sabes?
O sea,
es que me parece
mucho mejor
hacerlo así
que el hecho
de tener que hacer
object.septprototype.
Es que me parece
mucho más legible
en mi opinión,
la verdad.
Que si te gusta
hacerlo con
object.septprototype
y tal,
pero claro,
myerror.prototype
de esa manera
asignarías a tu clase
la instancia.
Es que no le veo
la verdad.
O sea,
no entiendo muy bien
qué ventaja
le ve respecto a esto.
Porque es en una línea,
a lo mejor.
Midu,
¿podemos dar de nuevo
el código del try-catch?
Por favor,
por favor.
Sí, hombre,
te lo puedo enseñar.
¿El try-catch cuál?
¿Este?
¿Este, por ejemplo,
el del throw new y tal?
Porque en vez de validar
la string,
validas una instancia.
Pero es que estamos
validando ya la instancia,
¿no?
O sea,
aquí estamos validando.
Bueno,
aquí no,
porque este código
lo hemos hecho así,
pero aquí ya estamos
validando la instancia.
Bueno,
es que esto todo
lo he tirado para atrás.
Pero aquí ya lo podríamos
hacer con la instancia,
¿no?
Y ya está.
O te refieres
a hacerlo
en el errors handling
y meterle el disk.
Si es así,
tampoco lo haría.
Porque ya sabes
que el concepto
de disk
le cuesta mucho
a la gente
se volver loca
y, o sea,
de hecho,
aquí la gente se va.
Hoy estuve en stream
intentando entender
fetch, promises
y asing away.
Me estoy ayudando
bastante con tus vídeos.
Ah, mira,
sí que quería darte las gracias.
Nada, un placer.