subir/Curso de Fundamentos de JavaScript/06-Asincronía en JavaScript/03-Uso de AsyncAwait para Promesas Asíncronas en JavaScript.vtt

WEBVTT

00:00.000 --> 00:04.200
Hay que otra forma de poder trabajar
promesas asíncronas,

00:04.200 --> 00:06.360
que sería
SYNC-N-AWAIT.

00:06.360 --> 00:09.400
Aquí tenemos ya nuestro proyecto, un HTML
en blanco,

00:09.400 --> 00:13.800
lo que queremos es utilizar el JavaScript
para poder ver aquí en consola el resultado.

00:13.800 --> 00:20.900
Pero vamos a estar hablando de algo que se
llama SYNC-N-AWAIT.

00:20.900 --> 00:25.320
Que esto es otra forma de poder trabajar
código de forma asíncrono.

00:25.320 --> 00:28.640
El SYNC-N-AWAIT devuelve una promesa,

00:28.640 --> 00:33.240
entonces el resultado es lo mismo, el
código que esté en el SYNC-N-AWAIT

00:33.240 --> 00:35.720
se va a pasar a la sección de Web API,

00:35.720 --> 00:40.960
en esa sección va a trabajar para poder
resolver

00:40.960 --> 00:43.160
lo que es esa función como una promesa,

00:43.160 --> 00:46.720
y ya que esté resuelta, no las va a poder
regresar con el EVENLOOP

00:46.720 --> 00:49.040
directamente al call
stack,

00:49.040 --> 00:52.840
para que se pueda ejecutar la respuesta de
esa promesa, ese callback.

00:52.840 --> 00:57.360
Las promesas existieron después de los
callbacks,

00:57.360 --> 00:59.600
así que ese es el beneficio que tenemos,

00:59.600 --> 01:03.040
que nos ayuda a que esto genera que
nuestro código

01:03.040 --> 01:06.440
pase de ser código síncrono en nuestro
call stack,

01:06.440 --> 01:08.240
a código
asíncrono,

01:08.240 --> 01:11.840
y se puedan ir resolviendo diferentes
tareas de forma síncrona.

01:11.840 --> 01:15.840
Ahora, el SYNC-N-AWAIT, la diferencia que
tiene con las promesas

01:15.840 --> 01:19.080
es que es una forma un poco más
legible

01:19.080 --> 01:22.040
de poder leer los pasos, qué es lo que
está pasando.

01:22.040 --> 01:25.200
Lo que vamos a hacer ahorita, que es un
pequeño ejercicio,

01:25.200 --> 01:28.640
vamos a consumir una API, una API pública,

01:28.640 --> 01:30.880
para poder utilizar el
FETCH.

01:30.880 --> 01:33.160
Ese FETCH lo que nos va a ayudar es,

01:33.160 --> 01:35.080
FETCH en particular es otra web
API

01:35.080 --> 01:36.880
que también nos regresa una promesa,

01:36.880 --> 01:39.680
trabaja por su cuenta, y una vez que esté
resultado,

01:39.680 --> 01:41.360
simplemente lo regresa al call
stack

01:41.360 --> 01:44.280
para que nosotros podamos tener el
resultado

01:44.280 --> 01:46.200
de si la promesa se cumplió o
no.

01:46.200 --> 01:48.400
Y vamos a hacer el mismo
ejercicio,

01:48.400 --> 01:50.880
pero utilizando
SYNC-N-AWAIT.

01:50.880 --> 01:54.680
Entonces aquí vamos a conseguir una
pequeña función

01:54.680 --> 01:59.680
que se va a llamar
FETCHDATA.

02:03.320 --> 02:05.600
Esta función no va a recibir ningún parámetro,

02:05.600 --> 02:09.440
entonces adentro de esta función
utilizamos el web API

02:09.440 --> 02:12.040
que se llama
FETCH.

02:12.040 --> 02:14.440
Y aquí vamos directamente al
FETCH,

02:14.440 --> 02:16.880
tenemos que poner la URL del
API

02:16.880 --> 02:20.320
a la que estamos intentando hacer como la
petición.

02:20.320 --> 02:22.240
Yo tengo aquí algunas APIs abiertas,

02:22.240 --> 02:24.280
existen diferentes APIs
públicas,

02:24.280 --> 02:26.680
tú puedes utilizar el API que tú quieras,

02:26.680 --> 02:27.960
te las pongo aquí de
referencia

02:27.960 --> 02:29.920
para que tú puedas ver la documentación,

02:29.920 --> 02:32.480
está una de Pokémon, está una de Star Wars,

02:32.480 --> 02:35.760
o la que yo voy a utilizar es la de Rick
and Morty.

02:35.760 --> 02:38.920
Entonces voy a utilizar
particularmente

02:38.920 --> 02:40.880
esta parte del
API

02:40.880 --> 02:44.080
que me regresa a los personajes de Rick
and Morty.

02:44.080 --> 02:49.080
Entonces venimos aquí, colocamos aquí
nuestra API,

02:49.320 --> 02:50.480
y ya que
está,

02:50.480 --> 02:53.080
venimos y ponemos el
THEN,

02:53.080 --> 02:55.520
que recordemos que el THEN es lo que se va
a ejecutar

02:55.520 --> 02:57.480
una vez que nuestra
promesa

02:57.480 --> 02:59.680
se resuelve de forma
satisfactoria.

03:00.520 --> 03:01.520
Ya que venimos
aquí,

03:01.520 --> 03:03.840
queremos que nos traiga la respuesta,

03:06.520 --> 03:11.520
y queremos que esa respuesta la pueda
pasar a JSON.

03:14.680 --> 03:18.680
Y listo, ya que tengamos esa respuesta en
JSON,

03:18.680 --> 03:20.680
necesitamos otro
THEN

03:20.680 --> 03:22.520
para que entonces esa
respuesta

03:23.920 --> 03:27.920
se convierte en nuestra data que vamos a
utilizar,

03:27.920 --> 03:30.880
y lo que le vamos a pedir es que de
inicio

03:33.280 --> 03:36.120
nos imprima qué nos
devuelve,

03:36.120 --> 03:38.040
cuáles son los datos que nos devuelve.

03:39.120 --> 03:42.520
Si algo sale mal, queremos el catch,

03:43.480 --> 03:45.520
para que el catch
sea

03:45.520 --> 03:48.880
que nos imprima el
error.

03:48.880 --> 03:51.880
Aquí es un que pueda tomar el error,

03:51.880 --> 03:53.880
y aquí le vamos a pedir nada más
que

03:55.280 --> 03:58.680
pues nos imprima cuál fue el
error.

04:00.680 --> 04:03.280
Perfecto, y aquí tenemos nuestra primera
promesa.

04:03.280 --> 04:05.680
Tenemos fetch que nos está regresando,

04:05.680 --> 04:09.680
más bien, fetch que va a hacer una
petición a esta API.

04:09.680 --> 04:11.680
Si esa petición
funciona,

04:11.680 --> 04:14.680
queremos que esa respuesta la pase en JSON,

04:14.680 --> 04:17.680
si esto se termina de resolver de forma
exitosa,

04:17.680 --> 04:20.680
queremos que esta respuesta la convierta
en datos,

04:20.680 --> 04:24.680
la pase directamente a datos, y nos
imprima estos datos.

04:24.680 --> 04:26.680
Si esto no
funciona,

04:26.680 --> 04:30.680
queremos ver cuál fue el error que nos
está regresando,

04:30.680 --> 04:32.680
¿no? ¿Qué fue lo que no
salió?

04:34.680 --> 04:36.680
Perfecto, entonces vamos a guardar aquí,

04:37.680 --> 04:39.680
y ahora venimos a nuestro
navegador

04:39.680 --> 04:44.680
y mandamos llamar nuestra opción, fetch data.

04:48.680 --> 04:51.680
Y podemos ver que tenemos ya una respuesta.

04:52.680 --> 04:55.680
Si abrimos esta respuesta, tenemos aquí
los resultados,

04:55.680 --> 04:58.680
y de los resultados ya nos está trayendo,

04:58.680 --> 05:01.680
de inicio, los primeros 20 personajes,

05:01.680 --> 05:02.680
que en la documentación del
API,

05:02.680 --> 05:04.680
posiblemente es la forma en la que te va a
decir,

05:04.680 --> 05:06.680
te va a regresar como grupos de
20,

05:06.680 --> 05:09.680
y aquí podemos ver que son personajes de
Rick and Morty.

05:09.680 --> 05:13.680
Bien, aquí es la forma en cómo utilizamos
un fetch,

05:13.680 --> 05:17.680
que es una promesa, con sus den y sus catch.

05:17.680 --> 05:21.680
Ahora, ¿cómo podemos hacer que esta
función

05:21.680 --> 05:23.680
la pasemos a sink and
await?

05:23.680 --> 05:25.680
Vamos para
allá.

05:25.680 --> 05:28.680
Entonces venimos aquí, esto lo voy a comentar,

05:28.680 --> 05:30.680
para que se quede como
referencia,

05:30.680 --> 05:32.680
porque voy a construir una función nueva,

05:32.680 --> 05:34.680
que también se va a llamar fetch data,

05:34.680 --> 05:36.680
que esa función va a ser una
sink.

05:38.680 --> 05:44.680
Entonces va a ser function fetch data,

05:44.680 --> 05:47.680
pero como es un sink and
await,

05:47.680 --> 05:51.680
nuestras funciones que queremos que se
conviertan en promesas,

05:51.680 --> 05:55.680
tendrían que empezar con un sink, al inicio.

05:55.680 --> 05:57.680
Entonces esto va a hacer que esta función,

05:57.680 --> 06:01.680
esta misma función, ya nos regrese una
promesa,

06:01.680 --> 06:04.680
o que esté esperando que sea una promesa.

06:04.680 --> 06:06.680
Entonces aquí comenzamos nuestra función,

06:06.680 --> 06:08.680
no vamos a tener ningún
parámetro,

06:08.680 --> 06:11.680
y vamos a empezar con un
try.

06:11.680 --> 06:15.680
A sink and await tiene try y
catch.

06:15.680 --> 06:19.680
El try y catch, que sería esto, y catch,

06:19.680 --> 06:23.680
que el catch es muy similar al catch que
tenemos acá,

06:23.680 --> 06:26.680
el try y el catch es lo que nos va a permitir,

06:26.680 --> 06:28.680
entonces, hacer el manejo de los
errores

06:28.680 --> 06:31.680
desde la sink y en el
await.

06:31.680 --> 06:37.680
El try es prácticamente el código que
tiene que pasar,

06:37.680 --> 06:40.680
y si eso no funciona, entonces el
catch

06:40.680 --> 06:44.680
nos va a regresar el error de lo que no
está funcionando.

06:45.680 --> 06:47.680
Así que empezamos con el
try,

06:47.680 --> 06:50.680
esta es la sintaxis de poder utilizar un try,

06:50.680 --> 06:56.680
y después ocuparíamos el catch para poder
manejar el error.

06:56.680 --> 07:00.680
Y el catch aquí se manejaría con error.

07:01.680 --> 07:04.680
Esta sería la sintaxis de poder utilizar
un try-catch

07:04.680 --> 07:07.680
adentro de un async, una función que es async.

07:07.680 --> 07:11.680
Ahora, estando acá, vamos a generar una
variable

07:11.680 --> 07:14.680
que se va a llamar
response,

07:14.680 --> 07:18.680
y esa variable va a ser igual a un fetch,

07:18.680 --> 07:22.680
que el fetch es la misma web API que vamos
a hacer

07:22.680 --> 07:24.680
para poder hacer una petición del API.

07:24.680 --> 07:28.680
Y vamos a utilizar la misma
URL.

07:30.680 --> 07:33.680
Pero, como estamos utilizando sink and await,

07:33.680 --> 07:36.680
esta es una promesa, y entonces esperamos,

07:36.680 --> 07:39.680
y aquí es donde viene,
await.

07:42.680 --> 07:47.680
Await indica que este código espera que se
resuelva la promesa,

07:47.680 --> 07:48.680
que es
esto.

07:48.680 --> 07:51.680
Nuestra función aquí es una
async,

07:51.680 --> 07:54.680
y entonces en la wait esperamos que
esto

07:54.680 --> 07:58.680
sea el código que espera que se resuelva
la promesa,

07:58.680 --> 08:01.680
que es como aquí cuando estábamos iniciando,

08:01.680 --> 08:03.680
nosotros estábamos con el
fetch.

08:03.680 --> 08:05.680
Entonces, el await va a esperar que este
código

08:05.680 --> 08:07.680
resuelva el tema de la
promesa.

08:07.680 --> 08:11.680
Si esto funciona, entonces aquí generamos
otra variable

08:11.680 --> 08:13.680
que se va a llamar
data,

08:13.680 --> 08:21.680
que va a ser igual a await response.json.

08:23.680 --> 08:25.680
Y si esto se termina de
resolver,

08:25.680 --> 08:31.680
entonces queremos que simplemente nos
devuelva

08:31.680 --> 08:33.680
cuál es la data que nos
trae.

08:33.680 --> 08:37.680
Entonces, si esta promesa se resuelve,

08:37.680 --> 08:40.680
lo siguiente es que esta
respuesta,

08:40.680 --> 08:44.680
como lo que traiga el fetch, se va a
guardar en respuesta,

08:44.680 --> 08:47.680
entonces queremos que esta respuesta
puesto json,

08:47.680 --> 08:49.680
que es que nos quede en un json, se guarde
en data,

08:49.680 --> 08:52.680
y que nosotros podamos
imprimir

08:52.680 --> 08:54.680
qué es lo que trae esta
data.

08:54.680 --> 08:58.680
Si esto no sucede por algo, simplemente
queremos

08:58.680 --> 09:03.680
que nos imprima de momento el error que
nos trae.

09:06.680 --> 09:07.680
Y
listo.

09:07.680 --> 09:11.680
Ya con eso, guardamos, venimos a nuestro
navegador,

09:11.680 --> 09:15.680
y si ponemos fetch
data,

09:17.680 --> 09:19.680
nos trae de igual forma la petición,

09:19.680 --> 09:21.680
vemos aquí que es una
promesa,

09:21.680 --> 09:25.680
y si la abrimos, podemos ver que nos trae
el resultado,

09:25.680 --> 09:27.680
igual con 20
personajes,

09:27.680 --> 09:32.680
y es la misma respuesta que teníamos en la
promesa arriba.

09:32.680 --> 09:35.680
Nos trae prácticamente los mismos personajes.

09:35.680 --> 09:37.680
Y estamos viendo que es una promesa.

09:37.680 --> 09:39.680
Prácticamente, a Sink and
Away,

09:39.680 --> 09:42.680
nos está regresando una promesa que ya se
terminó de hacer,

09:42.680 --> 09:45.680
es una promesa que se completó de forma
exitosa,

09:45.680 --> 09:47.680
y es por eso que en la parte de
abajo

09:47.680 --> 10:05.680
ya tenemos la respuesta exitosa de la promesa.