Amigos, nueva sintaxis para JavaScript, una nueva sintaxis salvaje.
Os comento esta nueva sintaxis, ¿sabes?
Nueva sintaxis propuesta.
Esta sería la sintaxis, const error response, ¿vale?
Aquí con esta asignación.
Aquí tendríamos un nuevo operador, await fetch barra products.
Esta sería la nueva sintaxis.
Lo que sería equivalente a día de hoy sería esto.
¿Cómo se haría ahora?
Claro, tendríamos que tener aquí la respuesta y el error en un let.
Intentaríamos recuperar la respuesta haciendo el await con el fetch.
Y si no, el catch, el error, lo guardaríamos aquí en el error, ¿vale?
Entonces, la forma de hacer ahora esto, lo hacemos así.
Esto es una cosa que sí que funciona a día de hoy y esta es la nueva sintaxis propuesta.
Es una propuesta, ¿vale?
Es una propuesta.
Que ten en cuenta, no está cerrado, no hay una fecha en la que vaya a funcionar.
Esta desestructuración es la desestructuración que ya conocemos.
Básicamente, si tenemos aquí first second y aquí lo que tenemos es un array hola y mundo.
Si hacemos un console log de first, aquí tendríamos hola.
Y si hacemos un console log de second, aquí tendríamos mundo, ¿vale?
Esto es como funcionaría ahora.
Esta es la desestructuración de los arrays.
Así que esta parte de aquí, esto no es nuevo, solo que lo que estaría haciendo este await fetch con este operador es que estaría devolviéndote un array de dos posiciones.
Donde la primera posición sería el error, si es que hay, y la segunda posición sería la respuesta en el caso de que haya ido bien.
Por eso sería algo parecido a esto de aquí.
Tendríamos la variable let, response y error.
Si ha ido bien, guardaríamos el response en response y el error en error, ¿vale?
Por eso esta sintaxis ya la tendríamos.
Ahora, la novedad, ¿dónde estaría?
Estaría en este nuevo operador con este interrogante.
¿Qué es lo que haría este interrogante?
Este interrogante lo que haría sería como preguntar si ha ido bien la promesa que tengo a la derecha, entonces quiero saber si ha habido un error o si ha habido una respuesta.
Lo que deberíamos, ¿cómo funcionaría esto?
Esto funcionaría, para que nos hagamos un poco la idea, funcionaría así, ¿vale?
Si tengo un error, pues aquí vamos a poner console error, pero a lo mejor aquí return false, por decir algo.
Y si no tienes un error, pues aquí ya tendríamos la respuesta, console log de la response.
Y podríamos hacer un response.map, lo que sea, ¿no?
Aquí ya podríamos hacer lo que nos dé la gana.
Esto es como funcionaría, claro, a día de hoy hacer esto es un poco más complejo, hay que hacer un try-catch, si quieres utilizar la wait.
La idea de esto, uy, perdón, he puesto error y esto es error, ¿vale?
Para que nadie se equivoque.
La idea de esto es simplificar la sintaxis, ¿no?
Porque ya veis que a día de hoy tendríamos que hacer todo esto para sacar correctamente el código.
Y ahora, pues con solo un operador, ya lo tendríamos y además podríamos poner que sea una constante directamente.
Se parece mucho al optional chaining, se parece también mucho a este operador que sí que existe, este operador de aquí.
Por ejemplo, let a hola.
Y ya podemos hacer mundo, ¿no?
Este operador ya existe.
Este operador es el del nullish assignment operator.
Lo que va a hacer esto es que solo en el caso que a sea null va a hacer esta asignación.
Por ejemplo, ahora no está haciendo la asignación, la está ignorando.
¿Por qué?
Porque ya tenía hola.
Pero si pongo null vais a ver que ahora pone aquí mundo.
¿Por qué?
Porque como a es null, esto lo que hace es asignarlo de la derecha.
Lo que hace este operador es chequear que si el valor de la variable es null,
entonces asigna el valor que le hemos puesto a la derecha.
Este sería nuevo porque solo es uno, no son dos, solo es uno.
Y serviría como para preguntar si realmente esto de aquí ha funcionado y no lo pasaría en un array.
Ahora la pregunta del millón, que mucha gente se hace,
¿por qué un array y por qué el error sale el primero?
Esto en realidad es un patrón que existe ya en Golan.
Es un patrón que ya existe en Golan, que ahora no me acordaré cómo se llama.
Es una pena porque aquí no lo vamos a ver.
No lo vamos a ver.
Pero bueno, es un patrón muy típico donde se hace esto para asegurarse que vas a manejar el error.
Porque tened en cuenta que este error está sin manejar y por lo tanto hay que manejarlo de alguna forma
para evitar que esto reviente.
Si por lo que sea no manejas el error, pues aquí vas a ver que te va a petar
porque esto puede ser que sea el response, puede ser null y en el error vas a tener el error.
Entonces, el hecho de hacerlo como un array y que sea la primera posición,
de alguna forma te obliga a tener que chequearlo para obligarte a manejar los horrores.
Efectivamente, eso sería error first pattern.
Vale, así se llama.
Esa sería un poco la idea.
Esta propuesta la tenéis totalmente documentada con un montón de información.
Sería el save assignment operator.
Ha tenido ya bastante movimiento.
Esto, de nuevo, está todavía en desarrollo.
Está en fase cero.
O sea, está todavía muy verde.
No hay ningún tipo de avance de que realmente vaya a llegarse o no.
Aquí tenemos más ejemplos.
¿Veis?
Aquí tendríamos un ejemplo para primero hacer la request, luego para hacer el parseo, luego la validación.
Y tendríamos aquí las razones de por qué lo están haciendo así.
De hecho, lo comentan.
También se podría utilizar con funciones.
¿Veis?
Aquí tenemos una función donde lo está utilizando.
Lo podríamos también utilizar con objetos perfectamente.
Lo podríamos utilizar en un montón de sitios.
También con promesas.
Que esta sea la idea principal de utilizarlo en promesas para simplificar el código.
Y habría también por aquí, te explica por qué el try-catch no es suficiente.
Te dice que el try está utilizado de forma no es tan típico.
¿Vale?
Porque el problema que tiene el try-catch.
Una vez que lo utilizamos.
Fijaos, aquí hay un try-catch que encima está anidado.
Que lo hace bastante más complicado.
El otro problema que tiene el try-catch es esto.
Que para poder, de alguna forma, acceder al file-content después del try-catch, te obliga a crear la variable fuera.
Porque claro, si la utilizas dentro, el scope hará que esa variable solo la puedas utilizar dentro.
En cambio, si la quieres utilizar fuera, aquí tendríamos que hacer que el let esté fuera, a try-catch y luego try-catch.
Y queda mucho, mucho más verboso el código.
Aquí explican por qué el data no es lo primero, por qué para evitar ignorar los errores, un montón de cosas.
Comparaciones de diferentes formas de arreglarlo.
Entonces, ¿qué?
¿Os gusta o no os gusta?
Esto es mucho mejor que un try-catch.
Hombre, yo creo que es mejor, pero también es más peligroso.
¿Vale?
O sea, yo veo como que la gente...
Es verdad que la gente no hace mucho try-catch.
O sea, la gente, muchas veces, de las cosas que dicen, por ejemplo, cuando tú tienes un fetch, api, pokemon, .com y haces esto, mucha gente siempre, siempre, siempre, siempre, lo primero que te pregunta es, ¿pero por qué no utilizas...?
No, haces esto.
Y mucha gente siempre dice, ah, pero qué feo, ¿por qué no utilizas el Async Await, no?
Siempre te dicen, ¿pero por qué no utilizas el Async Await?
Y tienen razón, pero el problema que tendríamos con este del Async Await es que mucha gente se cree que la Async Await sería esto, ¿no?
O sea, mucha gente dice, vale, pues haces esto aquí, esto sería el api, pokemon.com, esta es la respuesta, aquí tendríamos el JSON, ¿no?
Y la gente se cree que estas dos cosas son equivalentes, cuando no lo son.
Estas dos cosas no son equivalentes porque te faltaría el catch.
Y para que sea más equivalente, ya no queda más corto, de hecho queda más complicado, porque ya tendrías que hacer esto, tendrías que hacer un try-catch, tendrías que manejar el error, y aquí tendrías el error.
Claro, aquí ya empieza como a no ser tampoco tan, tan, tan bonito, porque tienes una anidación más, tienes que poner un try-catch, el try ya se ve feo, ¿no?
El try es como que algo malo está pasando, mucha gente no hace esto, empiezan los problemas y entonces se lía parda.
Además de que aquí muchas veces no revisan bien el error, porque esto los dos estarían mal, porque una cosa que habría que hacer aquí sería revisar si realmente, si la respuesta está ok, entonces devolvemos esto,
y si no podríamos devolver un nuevo error, que sea lo que sea, ¿no? El res error, me parece, no me acuerdo si error o el status, bueno, podemos poner status text mismo, ¿vale?
Entonces ya haríamos esto, que esto sí que tendría, pero esto lo complica aquí todavía más, porque habría que ponerme así, final, no sé qué, igual soy team try, bueno, puede ser, yo me acostumbre, pero es cierto que la palabra try no es la mejor.
Sí, es que suena como muy, algo muy malo va a ocurrir, ¿no? Y peor cuando en el catch no hay nada. Bueno, claro, eso también lo he visto, ¿no? Que ponen el try-catch vacío.
Encima ahora, el try-catch puedes quitar el error, entonces muchas veces lo que veo es esto, que la gente hace esto, try, intenta esto, y si no, catch, y hacen esto.
En sintaxis está bien, pero el problema es que la lía es pardísima con esto, ¿no? Y es del palo, sí, intenta esto, pero si pasa algo malo, bueno, pues que, bueno, pues que le den por saco.
Me desentiendo, lo desentiendo. Bueno, pero así no te enteras de los errores. Ya, ya, pues eso lo he visto yo en código. En código y en pruebas técnicas también lo he visto, ¿eh?
Lo cual es bastante, bastante bestia. Hazlo, no lo hagas, pero no lo intentes. Eso decía el maestro Yoda, ¿no? No, no, there is no try, there is no try, totalmente.
Aparte de JavaScript, TypeScript, ¿cuál sería tu segundo lenguaje de programación favorito? Mi segundo lenguaje yo creo que sería PHP. Me encanta PHP.
Me encanta PHP porque el hecho de que no tengas que compilarlo, ¿sabes? De que no tenga un paso de compilación, que se compila como al vuelo cada vez que lo haces, me gusta muchísimo, me gusta un montón.
Luego, me gusta mucho Rust, me gusta mucho, mucho, mucho. Python también, que lo utilicé durante una temporada muy para temas de datos, me gustó también bastante.
Y C Sharp. C Sharp me parece, me parece un muy buen lenguaje de programación.
¿Se cayó un ídolo? Bueno, me importa tres pepinos. O sea, me importa un pepino, la verdad. Me importa un pepino que la gente me, ¿sabes?
Porque diga PHP, no, que PHP no es un lenguaje, que te calles, que te calles, que PHP le ha dado de comer a más gente que vamos, que cualquier lenguaje que te guste a ti un poquito, amigo.
PHP sigue siendo el lenguaje rey, te guste o no. Como si quieres ser una mierda, pues eso es una mierda que da dinero.
O sea, que acéptalo, acéptalo. Así son las cosas y así te las hemos contado.
Rust100.de. Oye, pues me lo voy a pensar, ¿eh?