Protocolos de Iteración en JavaScript

Así que, gracias por la introducción. Sé que acabamos de almorzar, pero espero que podamos olvidarnos de eso por un segundo y comenzar una nueva aventura juntos. Esta es básicamente la historia. Acabamos de empezar a trabajar en una nueva empresa, es una startup, y este es nuestro primer día en esta startup. Y lo primero que sucede es que el CTO se acerca a nosotros preguntando, ¿pueden ayudarme con la resolución de un problema que tengo? Resulta que es un problema real en producción. Y el CTO está revisando algunos registros e intenta averiguar qué clientes se ven afectados por estos registros. Y la forma en que podemos ayudar al CTO es ayudándole a analizar algunos archivos de registro, donde queremos contar cuántos están FCKD, no sé qué significa eso, que están en ese archivo en particular, y queremos contar cuántos de ellos ocurren para cada uno de los clientes. Entonces, si miramos el archivo de registro, se ve más o menos así. Estamos interesados en estas tres líneas aquí, en esta sección en particular, solo porque ese error en particular aparece. Y luego queremos tomar todas estas líneas y contar cuántas ocurrencias hay por cada cliente diferente. Así que esto debería ser bastante fácil, así que trabajemos juntos en una implementación para esto.

Entonces necesitamos leer archivos de registro. Lo primero que hacemos es importar la función de lectura de archivos de node.js, luego usamos esa función para leer el archivo, y esto cargará toda la información del archivo en esta variable llamada datos sin procesar. Luego queremos dividir en cada línea porque eventualmente queremos procesar cada línea individualmente.

Ahora tomamos este array de líneas, lo mapeamos para poder usar partes JSON para realmente crear objetos JSON para cada línea individual. Y en este punto podemos filtrar y simplemente decir, ok, mantén solo las líneas donde tenemos ese mensaje.error igual al error específico que estamos buscando. Y finalmente, simplemente hacemos un reduce para agrupar las cosas, en realidad para contar las cosas por clientes específicos. Y registramos el resultado de ese reduce. Y deberíamos ver algo como esto. Básicamente, vemos un objeto donde las claves son los IDs de los clientes y los valores son el número de veces que ese error en particular ocurrió para cada cliente individual.

Entonces le damos este script al CTO, el CTO está realmente feliz y nos dice, buen trabajo, gran primer día, espero verte mañana. Experiencia más más. Muy bien. Al día siguiente, el CTO nos dice, bueno, ¿sabes ese script que me diste ayer? En realidad, ahora hay un problema. Estoy viendo este error llamado error de rango, longitud de cadena no válida. Ahora voy a mostrarte el código nuevamente. ¿Alguien puede decirme en qué línea tenemos un problema? Vamos, no seas tímido. Ok, alguien dice la número tres. Buena suposición. ¿Por qué es esto un problema? El problema está ahí porque básicamente estamos cargando todo el contenido del archivo en memoria. Simplemente decimos toma todos esos datos y almacénalo en una variable como una cadena. Y si el archivo comienza a ser relativamente grande, estamos hablando del orden de gigabytes, puedes comenzar a ver ese problema en particular. O si es más de dos gigabytes, verás otro problema, que es muy similar. Entonces, el problema conceptual aquí es que estamos precargando toda la información en memoria, lo cual para archivos grandes no es algo que vaya a funcionar. Entonces, ¿cuál es un enfoque ideal en su lugar? El mejor enfoque sería, ok, ¿por qué no pasar este archivo línea por línea? Al final del día, solo nos importa leer una línea a la vez. No necesitamos precargar todo en memoria. Entonces, una implementación ideal se vería así. Simplemente cargamos esta línea, la pasamos, la filtramos y comenzamos a agregar el resultado. Obtenemos la siguiente línea y en este caso, cuando intentamos filtrar, nos damos cuenta de que no nos importa esta línea, así que simplemente la descartamos. Pasamos a la siguiente línea, nuevamente pasamos, filtramos y agregamos. Y nuevamente, solo para mostrarte otro ejemplo, pasamos, filtramos, agregamos y en este caso encontramos nuevamente al primer cliente, así que simplemente incrementamos el contador a 2.

En este caso, puedes ver que el estado actual es algo que sigue evolucionando con cada línea, y al final, cuando no quedan más líneas por leer, el estado actual será nuestro resultado final. Podemos implementar todo esto con iteradores. Así que hoy vamos a aprender un poco más sobre eso.

Antes de entrar en esto, déjame presentarme. Mi nombre es Luciano. Soy un Héroe de AWS Serverless y un Microsoft MVP. Trabajo como arquitecto senior para una empresa llamada For Theorem. Si crees que mi nombre te resulta familiar, tal vez te hayas encontrado con este libro llamado Node.js Design Patterns. Si no lo has hecho, por favor échale un vistazo. Estoy realmente curioso por escuchar tu opinión. Y puedes conectarte conmigo, soy muy amigable, podemos seguir charlando más tarde en línea. Estos son algunos de mis contactos, pero debería ser fácil encontrarme en línea.

Ahora, muy rápidamente sobre For Theorem. Somos una empresa de consultoría especializada en AWS y serverless, por lo que la mayor parte de nuestro trabajo es básicamente ayudar a otras empresas a implementar u optimizar soluciones serverless y AWS. Si todo eso suena interesante, nuevamente, estoy muy abierto a charlar, así que definitivamente contáctame más tarde.

Ahora, ¿por qué nos importan los iteradores? Los iteradores son una abstracción perezosa que nos permite representar el concepto de repetición en lenguajes de programación. Y lo genial de esto es que básicamente nos permite procesar cosas, uno por uno, de una colección específica. Lo aún más genial es que podemos procesar conjuntos de datos más grandes o incluso infinitos. Imagina que tenemos un sensor que está leyendo datos, tal vez, no sé, temperatura, y está enviándonos constantemente datos. Siempre recibiremos más y más datos. ¿Cómo procesamos eso, si no es de manera perezosa, obteniendo fragmentos de datos uno a la vez?

Así que hay buenas noticias para JavaScript, que el concepto de iteradores ya existe en JavaScript, y eso ha sido cierto desde ECMAScript 2015. Hace ya algunos años que tenemos acceso a iteradores en JavaScript. Y vamos a refrescar un poco la sintaxis con la que es posible que ya estés familiarizado, y vamos a tratar de aprender más, comenzando con algunos ejemplos. Veamos este código. Tenemos un array, y hacemos un for-of en este array, e imprimimos cada elemento usando este bucle. Ahora, la salida es bastante obvia. Simplemente vemos foo, bar y baz. Lo genial aquí es que estamos usando esta sintaxis particular, for-of, que nos da fácilmente acceso a una repetición de todos los valores en este array. Pero podrías preguntarte, ¿podemos hacer esto solo con arrays? ¿Podemos hacerlo con otros tipos de objetos? Intentémoslo con cadenas. Lo que sucede aquí es que obtienes, en cada iteración, un carácter de la cadena original.

Entonces, de alguna manera, esto también funciona para cadenas, la sintaxis for-of. Ahora, ¿qué sucede si intentamos esto con objetos como objetos JavaScript simples? En este caso, en realidad obtenemos un error, lo cual es un poco sorprendente. Pero lo interesante de este error es que nos está diciendo que este concepto, objeto, no es iterable. Por lo tanto, podemos ver que ya existe un concepto de lo que significa ser iterable. Entonces podemos intentar descubrirlo mirando la documentación de MDN. Lo siento, esto es muy brillante, me doy cuenta ahora.

Lo interesante de esta página es que nos dice que for-of funciona con cualquier objeto iterable, pero también, si miramos más abajo, también podemos ver que también funciona con iterables definidos por el usuario. Entonces eso ya nos da una forma de crear nuestros propios iterables personalizados si queremos. Ahora, otra pieza rápida de sintaxis que es posible que hayas visto, esta es la sintaxis spread. Puedes usarla, por ejemplo, para pasar argumentos a una llamada de función, tomando uno por uno de un objeto iterable. Y nuevamente, si miramos la documentación, lo siento de nuevo por despertarte, lo que podemos ver es que nos dice que esto funciona en objetos iterables. Por lo tanto, cualquier objeto que sea iterable admitirá esta sintaxis particular. Si seguimos buscando, en realidad hay muchas APIs que admiten iterables. Es posible que hayas visto promise.all, es posible que hayas visto promise.all.settle, o incluso map y set se usaron en algunas de las charlas anteriores.

Entonces, vamos a tratar de descubrir más sobre lo que realmente significa ser iterable. Pero para hacer eso, creo que es muy útil aprender un poco más sobre los generadores, que creo que es un concepto que aún no es muy conocido en el panorama de JavaScript.

Si nunca has visto generadores, existe este concepto de funciones generadoras y objetos generadores. Una función generadora se ve como una función, pero es un poco especial. Tienes que poner un asterisco allí. Y lo que ganamos si ponemos ese asterisco es que ahora podemos usar esta palabra clave llamada yield.

Y lo que yield hace es una especie de retorno especial. Te permite devolver un valor, pero en lugar de detener la ejecución de la función en particular, va a recordar exactamente dónde nos detuvimos la última vez. Así que es más como una pausa que detener realmente la ejecución de la función. Y podemos reanudar esa ejecución desde el punto donde se dejó en la iteración anterior.

Pero ¿cómo usamos una función generadora? Bueno, podemos invocarla como una función regular, y eso nos va a devolver un objeto generador. Y en un objeto generador, podemos seguir llamando a dot next dot next, y cada vez recibiremos un objeto que contiene las claves done y value que básicamente nos dicen si hay más datos, sí o no, y este es el valor actual.

Ahora permíteme mostrarte un ejemplo más interesante donde, lo siento, tenemos varios puntos de yield. Este es un generador de frutas, así que cada instancia estamos devolviendo una nueva fruta, o estamos haciendo yield de una nueva fruta. Y cuando llamamos a dot next dot next, puedes ver que obtenemos cada vez un elemento diferente, por lo que puedes imaginar que la ejecución se pausa cuando hacemos yield. Y cuando llamamos a dot next de nuevo, va a continuar desde la línea donde pausamos la última vez.

Lo interesante es que también podemos usar for of, y si usamos for of en objetos generadores, obtenemos acceso directo a los valores. Ya no tenemos que pensar en ese objeto envolvente, y el bucle se detendrá automáticamente cuando lleguemos a done igual a true.

Ahora finalmente podemos hablar de los iteradores y los iterables. Estos son dos conceptos diferentes, muy similares, que a menudo se confunden, así que intentemos entender cuáles son las diferencias entre los dos. Me gusta pensar en los objetos iteradores como un cursor en una colección de datos. Así que puedes imaginar que esa flecha amarilla es un objeto iterador. Lo único que podemos hacer con él es decir, dame el valor actual o muévete al siguiente valor.

Mientras que un objeto iterable es un concepto ligeramente más genérico, es más la idea de que tienes una colección y esta colección es de alguna manera iterable, y la forma en que puedes iterar sobre ella es obtener un iterador de esa colección. Así que nuevamente, puedes imaginar el iterador como el cursor, el iterable como la idea de una colección de la que puedes obtener un cursor.

Ahora, si queremos entender qué considera JavaScript como iterable e iterador, necesitamos mirar esos protocolos de iteración, y el primer protocolo es el protocolo del iterador, que nos dice, voy a considerar un objeto si cumple con esta definición, y la definición dice que el objeto debe tener un método llamado next, y este método, cada vez que lo llames, debe devolver un objeto con las claves done y value.

Ahora, solo para mostrarte un ejemplo muy rápido, aquí tenemos una función de fábrica que nos permite crear un iterador que representa una cuenta regresiva, así que si llamamos a esta función, por ejemplo, con 3, va a crear un iterador que nos dará los valores 3, 2, 1, 0, ¿verdad? Así que queremos implementar este iterador, así que necesitamos cumplir con la definición del protocolo de iteración. Así que necesitamos tener un objeto que tenga un método next, que devuelva objetos con las claves done y value. Así que básicamente esta es una función de fábrica que crea un iterador para nosotros. Y una vez que lo hacemos, podemos instanciarlo, count down es un iterador.

Podemos seguir llamando a dot next dot next para obtener todos los valores hasta que done sea true. Ahora, una cosa interesante que no es muy conocida, y esta es la razón por la que introduje los generadores, es que si sabes cómo escribir generadores, todo el código que ves aquí es prácticamente equivalente a este código aquí. Porque los generadores implementan el protocolo del iterador detrás de escena para nosotros. Así que si estás familiarizado con los generadores, es mucho más agradable leer y escribir este tipo de código.

Ahora, veamos el protocolo del iterable. ¿Cómo dice JavaScript que un objeto es iterable? En realidad es bastante simple. Solo necesitas implementar una función especial llamada symbol dot iterator. Y esa función debe devolver un objeto iterador. Básicamente, se está marcando a sí mismo como, si necesitas un iterador para mí, simplemente llama a symbol dot iterator. Y podemos implementar fácilmente ese ejemplo de cuenta regresiva como antes para hacerlo iterable. Esta vez, cuando creamos una cuenta regresiva, será un objeto iterable. Así que necesita tener symbol dot iterator, que devuelve un iterador. Y este es exactamente el mismo código que antes, porque antes creamos un iterador. Así que puedes ver que solo estamos agregando una capa adicional de envoltura.

Ahora, lo interesante es que cuando un objeto es iterable, puedes usar la sintaxis for-of. Esto generalmente es mucho más agradable como una interfaz para dar a tus usuarios, porque tienen más control. Pueden simplemente llamar a dot next manualmente en el iterador, o pueden usar for-of. Pero si conoces los generadores, como deberíamos saber en este punto, básicamente puedes tomar todo este código y reescribirlo de esta manera. ¿Cuántos de ustedes se dan cuenta de que este es exactamente el mismo código que antes para el iterador también? Y sé que esto puede ser un poco confuso y también sorprendente. Pero el truco genial es que básicamente los dos protocolos no son mutuamente excluyentes. Aquí, podemos implementar un iterador iterable, por lo que un objeto que es tanto iterable como un iterador. La primera parte aquí es implementar el protocolo del iterador, mientras que la segunda parte es implementar el protocolo del iterador. Al decir simplemente return this, básicamente porque en sí mismo es un iterador, está diciendo que si necesitas un iterador de mí, ya soy un iterador. Y esto es exactamente lo que sucede detrás de escena cuando usas generadores, y es por eso que, si usas una función generadora, tus objetos serán tanto iteradores como iterables.

Ahora, todo lo que acabo de decir podría ser un poco extraño si empiezas a pensar, espera, me mostraste un ejemplo que involucraba leer de un archivo. Esa es una operación asíncrona. Me mostraste protocolos que no tienen en cuenta las promesas o lo asíncrono, entonces, ¿qué hacemos en ese caso? Bueno, resulta que los iteradores e iterables también tienen un equivalente asíncrono, y voy a mostrarte rápidamente la diferencia en sus protocolos. Entonces, para el protocolo del iterador asíncrono, es prácticamente la misma historia, excepto que en lugar de devolver un objeto con done-in-value, devolvemos una promesa que eventualmente va a resolver a un objeto con las claves done-in-value. Y la forma más fácil de hacerlo es simplemente hacer que la función next sea asíncrona, si solo quieres un atajo. Muy similar, el protocolo del iterable asíncrono, es prácticamente la misma historia, excepto que esta vez tenemos que usar symbol.asyncIterator, y tenemos que devolver un iterador asíncrono, por supuesto.

No es sorprendente, podemos usar generadores, y lo interesante es que nada nos impide hacer que una función sea tanto asíncrona como generadora, y obtienes ambas superpotencias allí. Obtienes tanto la superpotencia de await como la de yield. Y cuando haces eso, sorpresa, se implementa tanto el async-iterator como el async-iterable para ti.

Una vez que hacemos eso, podemos usar la sintaxis for-await-of, y en este caso estoy creando una cuenta regresiva donde espero un segundo antes de que se resuelva la promesa. Básicamente, puedes ver en la animación que lleva un poco de tiempo antes de ver el siguiente elemento, y este bucle for-await-of se encarga de esperar la promesa antes de pasar a la siguiente iteración. Esto es algo realmente útil, por ejemplo, si estás procesando un conjunto de datos paginados y necesitas hacer una solicitud para obtener la siguiente página.

Ahora que sabemos todo esto, muy rápidamente intentemos reescribir nuestro ejemplo original para aprovechar los iteradores. Lo primero que debemos hacer es pensar en la mejor manera de consumir un archivo en fragmentos en lugar de leer todo de una vez. Con Node.js hay diferentes formas, pero la que más me gusta son los streams, y no te preocupes demasiado si no conoces los streams. Voy a tratar de simplificarlo un poco. La idea es que podemos importar esta función, crear un stream de lectura, que nos brinda un stream legible que podemos usar para crear una instancia que nos permite consumir fragmentos de información de un archivo.

Ahora, como en Node.js los streams legibles son async iterables, podemos simplemente usar for-await-of, y vamos a leer una parte del archivo a la vez, a la que aquí llamamos fragmento. Pero hay un pequeño problema aquí. Un fragmento es una cantidad arbitraria de datos. Por defecto, creo que son alrededor de 4 kilobytes. Es algo que se puede configurar, pero eso no necesariamente va a coincidir con una línea. Tal vez tengamos una línea muy larga que supere los 4 kilobytes, tal vez tengamos varias líneas y en algún punto se rompa una línea en el medio. Así que esto no es muy conveniente.

Por lo tanto, podemos crear una función aquí. No voy a entrar en demasiados detalles en la implementación, pero esta función toma un AsyncIterable de cualquier tipo y te devuelve un nuevo AsyncIterable que devuelve cada línea individual del AsyncIterable original. Así que estamos envolviendo nuestro iterable en uno nuevo que es un poco más especializado. En este punto, tenemos todos los ingredientes que necesitamos para cumplir nuestra tarea. Podemos importar nuestro createReadStream, podemos importar nuestra utilidad byline, podemos inicializar el stream legible desde el archivo de registro. En este punto, inicializamos nuestro estado, al principio no conocemos a ningún cliente, así que simplemente será un diccionario vacío. Y ahora lo que podemos hacer es esto: forAwaitLine byline readable. Esto puede ser un poco intimidante, pero lo que realmente significa es usar este stream legible, usar la utilidad byline, en este punto tenemos un objeto AsyncIterable y queremos obtener cada valor individual en un bucle. Así que en este punto estamos básicamente haciendo iteraciones, y en cada iteración estamos procesando una línea del archivo fuente original. Todo el código dentro de aquí es exactamente el mismo que antes, así que simplemente estamos analizando como JSON, filtrando y luego acumulando los datos por cliente. Una vez que se completa toda esa iteración, simplemente registramos el estado resultante. Ahora le damos este archivo al CTO, el CTO está impresionado, está probando archivos que son de varios gigabytes y funciona sin problemas, así que todos están contentos, buen trabajo, hemos completado el segundo día con mucho éxito.

Ahora podrías tener una pregunta. En la implementación original, utilizamos map, filter y reduce, mientras que en esta implementación solo usamos un bucle for. No sé, tal vez prefieras usar map, filter y reduce, la mayoría de las personas encontrarán eso un poco más expresivo, ¿por qué no lo hice? Bueno, el problema es que aún no es 100% posible hacerlo. En realidad, hay dos propuestas en el TC39 para agregar este tipo de funciones de utilidad en iteradores y async iterators. Así que hasta que esas dos propuestas se fusionen, tenemos que hacer otras cosas.

Y una de las cosas que podemos hacer, en realidad podemos poly-fill esta implementación usando core.js. Y si tienes curiosidad, en realidad tengo una implementación de esta solución en particular usando core.js y usando map, filter y reduce. Ahora, puedes encontrar esa implementación en el enlace de código allí abajo.

Y también tengo dos cosas extra para ti, tengo dos masterclass gratuitas. Una sobre protocolos de iteración, que profundiza mucho más. Puedes ir a GitHub y hacer los ejercicios tú mismo, totalmente gratis. Y la otra es sobre flujos de Node.js, si tienes más curiosidad sobre esto en particular cosa. Veo a mucha gente tomando fotos, así que voy a ir a la última diapositiva, donde tienes un código QR, puedes obtener todas las diapositivas y luego tomar todos los enlaces desde allí. Muchas gracias.

Bueno, primero, por supuesto, todos queremos saber qué le pasó al protagonista de tu pequeña historia. ¿Recibieron un aumento después de hacer todo esto? Adquirieron más experiencia, así que eventualmente subirán de nivel y decidirán cómo gastar sus puntos. Muy bien. Perfecto. Me encantaría tener más preguntas. No hay muchas preguntas y no creo que no haya preguntas. También podemos hablar de Final Fantasy. Entonces una de las preguntas es, asumo que la solución final llevará, simplemente voy a aprobar eso. Está todo en vivo. Está todo en vivo. ¿Cuáles son buenos casos de uso para los generadores? Hay algunos casos de uso que se utilizan en producción y que creo que son realmente geniales. Uno de ellos, como mencioné en mi charla, es cuando tienes que procesar conjuntos de datosdata paginados, tal vez estás obteniendo información de una API y quieres leer varias páginas de esa API. Usar generadores o el concepto de iterables asíncronos en general, creo que es una buena solución elegante y te dará un código muy limpio desde el lado del consumidor. Otro caso de uso es cuando quieres implementar como un consumidor Q, así que cuando quieres obtener tareas para hacer de una cola, nuevamente puedes implementarlo de la misma manera. Así que creo que estos son buenos casos de uso.

Sí, esta es una pregunta que también tenía, así que simplemente la voy a hacer aunque no sea la pregunta principal. ¿Cómo generaste esta presentación? ¿Cómo hiciste estas diapositivas? Usé slides.com pero, sí, creo que es como reveal.js pero un poco más involucrado, sí. Correcto. Así que es JavaScript HTML CSS. Gracias. Quería que lo supieras también.

Así que gracias a quien haya hecho esa pregunta. Otra pregunta. Déjame ver. No sé si quiero hacer esta pregunta. Oh, esperaba esa pregunta. Bueno, en ese caso, por favor. ¿Cuál es tu Final Fantasy favorito? Estoy un poco indeciso entre Final Fantasy VII y VIII. Me quedo con el Ocho solo porque todos los demás dirían VII, solo para ser diferente. No eres el único. Eso es bueno. Tienes community aquí. Es muy bueno. Entonces, ¿quién es mi personaje favorito de Final Fantasy? ¿Cómo puedes controlar el tamaño de fragmento de ReadStream? Espera, creo que esto podría ser para la otra charla. Solo estoy leyendo desde mi pantalla, así que voluntarios, por favor ayúdenme. ¿Las funciones generadoras son compatibles en todos los navegadores? Creo que en este punto sí. Debería ser fácil verificar la compatibilidad del navegador, pero han estado disponibles desde EcmaScript 2015, así que esperaría que estén bastante disponibles en estos días. Increíble. ¿Quieres hacer una pregunta más mientras se preparan las charlas relámpago? ¿Y la gente puede encontrarte más tarde en el pasillo, verdad? La gente puede encontrarme más tarde o en línea, así que ahorra la siguiente pregunta. ¿Se pueden usar flujos o generadores para solucionar el límite de memoria de JsonParse? El límite de memoria de JsonParse... supongo que técnicamente se podría, pero creo que necesitarías reimplementar una especie de JsonParse que se pueda transmitir en secuencias y también si alguien te está dando un objeto enorme en ese Json que estás analizando, aún estás acumulando todo en memoria, así que no sé. Creo que es posible, pero creo que seguirá habiendo limitaciones. Nos queda un minuto, así que eso significa una pregunta. ¿Es fácil implementar automáticamente funciones de colección funcional en los iteradores, como map, reduce, etc.? No veo eso... ¿Quieres leerlo desde mi pantalla? ¿Es fácil implementar automáticamente funciones de colección funcional en los iteradores? Esto parece... Oh, como map y reduce. Sí, puedes verificar la implementación en Core.js porque ellos lo hicieron, pero esto es parte de la propuesta TC39, y creo que también tienen una implementación de muestra en la propia propuesta. Así que básicamente es solo que el objeto iterador, en lugar de tener solo .next, también expone map, reduce y filter. Muy bien. Muchas gracias por responder todas las preguntas. Por favor, un aplauso más antes de comenzar con nuestras charlas relámpago.