#100DaysOfCode _ #Day58
Lo prometido es deuda …Promesas (I)
Ayer dije que dedicaría el artículo de hoy del reto a las “promesas” de JavaScript, pues bien, tras resistirme un par de días: aquí voy.
Antes de nada, me gustaría hacer referencia a los artículos que he dejado a pie de la entrada, publicados en la mayoría por freecodecamp y MDN, y al vídeo de Wes Bos que incluyo en el artículo. Verdaderas joyas para entender en condiciones cómo funcionan.
Debo decir que mi principal fuente de aprendizaje viene, como ya he comentado en más de una ocasión, de Codecademy, de la lectura de aquella información que encuentro navegando y de los consejos que me prestan desinteresadamente aquellos a los que considero mentores.
Y recalco que todavía sigo siendo un aprendiz (y lo seguiré siendo eternamente) por lo que a pesar de publicar este artículo, no soy ni me considero un experto en esto. Al igual que con las otras publicaciones. La idea principal de estos es que me sirvan a mi mismo para repasar lo aprendido y a otros a los que les interese para que se puedan introducir en la materia.
Es mi manera “egoista” de ayudar a otros nuevos desarrolladores como yo.
Sin más, ¡vamos a ello!
¿Asincronismo? … ¡ eso lo será su padre !
En la mayoría de las ocasiones, no trabajamos con un entorno cerrado de programación, es decir, nuestro código depende y recoge datos de otras API’s, de bases de datos externas, de servidores, por lo que continuamente estaremos haciendo peticiones externas que requieren de la devolución (o no) de ciertos datos para ser usados en nuestra aplicación.
Si tenemos en cuenta que JavaScript ejecuta las tareas ubicadas en su pila de tareas (call Stack) de 1 en 1 y que las nuevas se van añadiendo al final de la pila para ser procesadas…¿cómo podemos hacer que no se paralice la ejecución del código mientras nos llegan datos externos?
Para ello JS tiene la capacidad de “delegar” la ejecución de ciertas funciones a otros procesos o API’s externas (DOM, AJAX, Timeout…), que están dentro del navegador pero no pertenecen estrictamente a JavaScript.
Operación asíncrona: es aquella que se realiza mientras permanece a la espera de la culminación de otra.
¡ Espera !, no te vayas aún que ahora empieza el código.
Si abres la consola y copias y pegas lo siguiente… ¿qué nos devuelve?
console.log('Primer texto introducido');
setTimeout(function(){
console.log('Segundo texto introducido');
},2000);
console.log('Tercer texto introducido');Sí, esto ya lo habrás visto en más de una ocasión, pero, ¿realmente te has percatado del “por qué”?
Si hemos dicho que JS ejecuta las tareas apiladas en su call stack de una en una, ¿qué ocurre con setTimeout?
Hagamos un paréntesis…
Un simil casero
Me gustan las analogías tontas, porque muchas veces se entienden mejor.
Y esta mañana tras el estudio, he dedicado un rato a las tareas de casa y he tenido una “iluminación”:
Imagina una pila enorme (realmente enorme) de ropa para planchar (call stack).
Preparas la mesa de la plancha, te pones la música y vas cogiendo 1 por 1 las prendas que hay en la parte superior de la pila.
Al mismo tiempo hay alguien que te va añadiendo ropa a la pila, en su parte inferior (nuevas funciones a ejecutar), que plancharás cuando les llegue su turno.
De pronto la siguiente camiseta que vas a planchar resulta que está sucia, así que a tu compañer@ le pides que, por favor, la meta en la lavadora (web api) para dejarla limpia.
¿Te vas a quedar esperando a que termine la lavadora para seguir planchando? Evidentemente no: continúas con tu tarea mientras se lava la camiseta.
Lo mismo te ocurre al cabo de un rato con un pantalón que te encuentras roído: pides que por favor te lo arreglen mientras sigues a lo tuyo. Concentrado.
Y seguimos con el proceso (event loop) hasta pasado un rato, en el que la lavadora (express) ha terminado y el pantalón ha sido arreglado.
Meter ambas prendas en tu cola de procesos hace que tu código (plancha) sea impredecible, ya que realmente no sabrías de antemano cuándo se van a ejecutar, así que pides, por favor, que te lo dejen en otro montón llamado callback queue, al que prestarás atención una vez que hayas terminado tu pila inicial de ropa por planchar.
Si entiendes esta analogía, estás preparado para entender las promesas….
Volviendo al ejercicio…
Vemos que JS ha ejecutado las funciones que tenía en su call stack y que, una vez que ha culminado estas y la API externa ha procesado la orden, pone su atención a los procesos del callback queue (console.log(‘Segundo texto…’)) para lanzar su ejecución.
¿Y todo esto qué tiene que ver con las promesas?
En el ejemplo mostrado, ninguna de las funciones dependen de otra y mucho menos de una tercera de la cual vamos a obtener sus datos de forma externa.
¿Pero qué ocurre si hacemos una petición a un servidor externo y necesitamos esos datos para continuar la ejecución de nuestro código?
Para eso tenemos las promesas.
Otro ejemplo para abrir boca:
No podemos mostrar en la consola el resultado del último “console.log” porque cuando se hace la llamada al mismo, no hemos obtenido aún el resultado de getName().
Esto mismo es lo que puede producirse con una petición de datos a un servidor, por ejemplo.
Para prevenir este error… tenemos las promesas…
Pero la parte más práctica la reservo para mañana que ya está quedando un poco larga la entrada. Mañana más y mejor…
Yo me voy a seguir con mis ejercicios de #JavaScript30…
Te recomiendo encarecidamente que eches un ojo a la recopilación de artículos que he dejado a continuación…
Keep Coding !
