haré esto un poco más grande. Este es el repositorio que compartí con ustedes. Tiene algunas ramas. En caso de que algo, técnicamente hablando, salga mal, etc., hay tres ramas, una de cada escenario que vamos a abordar. Pero si algo sucede que puede suceder, inesperado, aquí siempre tienes algunos commits. Tenemos un commit de inicio, un commit final y un commit alternativo final. Te explicaré exactamente qué es y por qué se llama así. Lo mismo para el escenario dos. Tienes los commits de inicio, final y agregar, y lo mismo para el tercer escenario. Así que les sugiero que comiencen con el escenario en vivo uno porque esto solo tiene los archivos de inicio. Son exactamente lo que necesitas para comenzar a trabajar conmigo. Por cierto, si tienen alguna pregunta, por favor interrúmpame. Digan algo y yo haré todo lo posible para responder en el momento. ¿Correcto? Así que todo claro aquí? Supondré que sí. Minimiza esto. Así puedo tener una imagen clara de ustedes. De acuerdo. Comencemos. ¿Qué vamos a hacer hoy? Hay tres escenarios. Como pueden ver, hay tres ramas. Cada rama es para uno de esos escenarios. Comenzarán con este inicio porque no quiero que me vean <a href="/tags/code">code</a> algo en el momento para poder comenzar. Esto es algo que ya tienen. Entonces, el primer escenario, nuevamente, este aquí, el escenario en vivo uno de inicio, tendrá todos los archivos que necesitan, todos los componentes, todo. Debes clonarlo, debes instalar las dependencias. Esto utiliza bytes, o bits, no sé cómo pronunciarlo. Así que deberían estar listos para comenzar. Pero, ¿qué tenemos aquí, si alguien tiene algún problema, por favor díganme. ¿De acuerdo? Pero, ¿qué es esto? En mi experiencia trabajando con composables, y las personas que trabajan con composables, todavía hay muchas personas que siguen utilizando la API de opciones dentro de <a href="/tags/vue-3">Vue 3</a>, y todavía están utilizando mixins dentro de <a href="/tags/vue-3">Vue 3</a>. Preparé este escenario solo para imitar eso. Antes de eso, veamos los mixins porque no sé si saben que en la documentación de <a href="/tags/vue-3">Vue</a>, se especifica específicamente que ya no se deben usar mixins debido a algunos problemas conocidos. Para <a href="/tags/scalability">scalability</a>, se superponen e involuntariamente, ese es el problema, ¿verdad? Y compartes todo, ¿verdad? Es como un componente. Entonces no puedes decir, hey, solo quiero exponer esto, pero quiero obtener o conservar esto como privado, por así decirlo. Esto es de la pasa un ID de usuario, estos datos de usuario utilizan dos mixins para obtener información de la API, de la <a href="/tags/database">database</a>. Algunos álbumes y algunas publicaciones. Entonces, cuando los obtienen, nuevamente los pasan, utilizando props, a cada componente. Entonces, los datos de usuario son un componente hijo para la aplicación, y los álbumes de usuario y las publicaciones de usuario,

Ambos son componentes secundarios de user <a href="/tags/data">data</a>. Así que veamos el código aquí. Voy a intentar hacerlo, ¿es lo suficientemente grande? ¿Leíste mi código? Espero que sí. De acuerdo. Nuevamente, si algo no está claro, si algo no funciona o lo que sea, por favor interrúmpeme, ¿de acuerdo? No sé si podemos chatear. Sí, intentaré abrir esto también aquí. De acuerdo, intentaré ponerlo aquí, para poder ver sus caras y también el chat. De acuerdo. De acuerdo, empecemos. Bueno, un recorrido súper, súper rápido. Como dije en el diagrama, estamos utilizando la API de opciones. Digamos que este ID de usuario uno proviene de algún tipo de autorización, de un token, de una cookie. No importa. Pero nuestro ID de usuario es el ID de usuario uno. Luego enviamos este ID de usuario a user <a href="/tags/data">data</a> como compartí en el diagrama, ¿verdad? Pasamos las props hacia abajo. Entonces, si abro user <a href="/tags/data">data</a>, está aquí, por cierto. Lo que estamos haciendo es recolectar y utilizar dos mixins. Esos dos mixins están aquí y son casi iguales. Obtenemos la prop, tenemos algunos estados reactivos, publicaciones, algunas transformaciones, algunas mutaciones. Y cuando todo está listo, si tenemos un ID de usuario en este caso, porque necesitamos el ID de usuario para obtener la información, para filtrar la colección, luego lanzamos FetchPost. Y si miras FetchAlbums, es exactamente lo mismo. Y la forma en que lo he usado, por ejemplo, solo ten en cuenta esto. Si quisiera llamar a esto use o fetch... No, lo siento, esto no es... Este. En lugar de FetchAlbums, FetchData y hago lo mismo en los otros mixins. Dado que lo estamos consumiendo al mismo tiempo, ocurrirá cierta superposición, ¿verdad? Este es un problema común de los mixins. No tenemos esto con Compostables, ¿verdad? Como verán muy pronto. Entonces obtenemos los datos y los pasamos hacia abajo. UserAlbums y UserPosts, como dije. Obtenemos los datos, el mixin de publicaciones, el mixin de álbumes, vuelve y pasamos hacia abajo. Nuevamente, estamos haciendo lo mismo. Y si abrimos esta información, estos componentes, nuevamente, API de opciones. Es una iteración súper simple. Porque para mí, la clave aquí no es la composición del componente. Es la API de composición y los Compostables. Así que creo... Espero que esto esté claro. Entonces, ¿cómo van a abordar esto? ¿Qué van a hacer? Bueno, esto es lo primero que vamos a hacer. Vamos a cambiar estos mixins por un Compostable. Pero el resto en este punto, será lo mismo. Serán solo props. Y nuevamente, no hay nada malo con las props. Pero son alternativas. Y este es el uno, este Compostable de usuario o veremos. Nos conectamos a la base de datos. Y devolvemos un estado que podemos eliminar de forma segura de la aplicación, del mixin, etc. Entonces esto es lo primero que vamos a hacer. ¿Cómo hacer esto, verdad? Porque estamos utilizando la API de opciones. Y en primer lugar, puedes usar un Compostable con la API de opciones. Tal vez podamos implementar esto más tarde. Pero como verás, no es la forma más clara de hacerlo. Así que vamos aquí. Y creemos en Compostables useUserData. Hay un patrón común que precede el nombre con use. Algo así como use lo que sea. En este masterclass, crearás cuatro o cinco use lo que sea. Específicos para cada situación, ¿verdad? Dado que estamos tratando con user <a href="/tags/data">data</a> aquí, para publicaciones, álbumes, lo que sea, creo que este es un nombre lo suficientemente bueno. Así que lo tenemos aquí. ¿Qué hace un Compostable, verdad? Exponen algo. Esperan algo y exponen algo. Entonces, ¿cómo abordar esto, verdad? ¿Cómo comenzar a mover todo esto aquí desde la API de opciones a algo que vive en Compostables que utiliza la API de composición? Muy fácil. Hay tres pasos que puedes anotar si quieres. Si alguno de ustedes nunca ha trabajado con Compostables, este es un patrón súper fácil de entender para probar. Veamos el estado reactivo. ¿Qué quiero decir con estado reactivo? Algo que utiliza las API de reactividad de <a href="/tags/vue-3">Vue</a>. Entonces, por ejemplo, el estado no reactivo podría ser algo como esto. No sé. Clave de almacenamiento igual a usuario, por ejemplo. Esto no cambiará. Es un estado. Es local a este componente. Pero no es un estado reactivo. Así que no nos importa porque no vamos a reaccionar. Tal vez como un efecto secundario, lo necesitemos en cualquier situación. Pero no me enfocaré en esto al principio. Estamos buscando estado reactivo. Entonces, ¿qué estado reactivo? Bueno, tenemos el ID de usuario, pero en este caso, no sé si es reactivo o no, pero tal vez lo necesitemos. Aquí es reactivo porque es <a href="/tags/data">data</a>. Es como una referencia reactiva. Y tenemos, por supuesto, si vamos a los mixins, tenemos el estado reactivo de los álbumes. Estado reactivo, bueno, esto es una transformación para mí. Y tenemos algunas mutaciones. Entonces, busca estado reactivo. Lo tenemos aquí. En el otro mixin, son las publicaciones. Entonces, busca cualquier transformación. Una propiedad computada transforma esta pieza de estado de alguna manera. Así que esto

Los álbumes del usuario, transformación. User pause es otra transformación. Y por último, busca a alguien que intente mutar este estado. Lo tenemos aquí. Fetch albums, obtén los álbumes de la API y muta el estado. Así que esto es, espero, muy claro. Y lo mismo con pause. Así que en un orden específico, intentemos construir este compostable. Entonces, espera, veremos, pero comencemos con la función de exportación y use user <a href="/tags/data">data</a>. Entonces, lo que espera esto. Creo que espera el ID de usuario, ¿verdad? Cuando llamamos a use user <a href="/tags/data">data</a>, podemos tener el ID de usuario aquí, por ejemplo. ¿Correcto? Así que user ID, es un número. Así que esperamos el ID de usuario. Y lo que quiero buscar, lo siento, y obtener todos los pilotos es lo suficientemente inteligente como para decir que necesitamos usar user albums y fetch albums y user post y fetch post. Así que solo necesitamos componer esto, crear esto. Y es más fácil de lo que piensas. Así que comencemos con user albums. ¿Correcto? No quiero este tipo de autocompletado ahora. Así que los álbumes están aquí. Creemos la cosa de los álbumes. Y esos álbumes, tienes que pensar si quieres que vivan dentro del compostable o fuera. Si los colocas fuera, será como un singleton, ¿verdad? Será común para cada implementación de este compostable. Pero hay veces, y veremos al final, veremos algunos casos en los que no quieres que eso suceda. Quieres mantenerlos privados para cada implementación. Pero en este caso, creo que los álbumes y las publicaciones pueden ser comunes a todas las implementaciones. Así que creémoslos. Const albums. Y esto será una referencia reactiva. Así que tenemos que usar ref. API Reactiva. Y necesito algunas interfaces. Así que tomaré user album y también user post. Tenemos dos. Así que albums. Ref de user albums. Es igual. Lo mismo podemos hacer para las publicaciones. Así que posts. Es user posts. Y creo que esto es suficiente para comenzar a construir el interior de la función. Así que traigamos esto exactamente. Comencemos con el álbum. Lo siento. Porque este es el estado reactivo. Lidiaremos con la transformación. Pero ahora estamos lidiando con las mutaciones. Las acciones que mutan el estado. Así que el primero es fetch albums. Así que lo vamos a poner tal como está ahora. Y será albums value <a href="/tags/data">data</a>. Y como puedes ver, es exactamente como estaba en la versión de la API de opciones. Así que tenemos fetch albums. Y necesitamos fetch posts. Así que vamos al mixin fetch post, y hacemos lo mismo. Así que necesito una nueva función fetch posts. No tenemos este contexto aquí. Lo que tenemos, pero no es lo que esperamos. Es post value igual a <a href="/tags/data">data</a>. Y lo expondremos. Y esta es otra diferencia crítica con un mixin. En un mixin, todo es público. Las props, los datos, las propiedades computadas, los métodos. Todo es consumible desde el exterior. A veces esto es lo que queremos. Si el ID de usuario cambia, sí, será reactivo. En nuestro caso, lo siento, ahora veo esta pregunta. Lo siento, pero en este caso, si esto es reactivo, y esto es reactivo porque estamos usando <a href="/tags/data">data</a>, ¿verdad? Si esto cambia, por ejemplo, en esta propiedad computada que tenemos en el mixin, esta propiedad computada, user albums, tiene en cuenta el ID de usuario. Así que si este ID de usuario cambia, esto se reevaluará. Porque la propiedad computada. Y lo mismo ocurre en los otros mixins, porque las publicaciones de usuario se filtran, ¿verdad? Es una colección de publicaciones, pero solo me interesan las del usuario. Así que si cambia, sí, lo reevaluaremos. Como mencioné, con un mixin, expones todo. No hay otra forma. Pero con un compostable, devuelves lo que realmente necesitas devolver. Así que en este caso, son fetch albums y fetch posts. Así que tenemos una forma de mutar. Pero no quiero devolver. Sí, entiendo tu frustración. Probaremos un poco los compostables. Sí. Hasta donde sé, nunca he usado un compostable en el que la función principal no devuelva nada. Lo que he estado usando, como verás, es un compostable que también expone algo fuera de la función. Algo adyacente. Algo agradable de tener. Que no es esencial, o algo opcional. Pero en mi experiencia, lo siento, nunca he usado un compostable que no devuelva nada. Creo que es simplemente el patrón en sí mismo, ¿sabes? Lo siento, me perdí en mi,

ah sí, tenemos estos álbumes y publicaciones. No necesitamos exponer esto. Porque esos son todos los álbumes y todas las publicaciones. Y solo necesitamos los álbumes y las publicaciones del usuario, ¿verdad? Así que no necesito exponer esto. Pero por otro lado, quiero poner eso dentro de la función. Porque entonces, cada vez que ejecutemos estos datos de usuario, crearemos una nueva versión de los álbumes y las publicaciones. Y no queremos eso. Queremos que sean globales pero privados. Así que no los devolvemos. ¿Qué devolvemos? Sí, las transformaciones, ¿verdad? Así que tenemos la primera aquí, en los álbumes del usuario. Entonces, hay dos formas de hacer esto. Si esta propiedad computada, porque al final, es una propiedad computada ¿verdad? Así que computada. Si esta propiedad computada va a ser consumida dentro del compostable, deberíamos declararla como una propiedad computada canónica. Pero si esto va a ser consumido desde el exterior, podemos hacerlo en línea. Sé que esto no es tan legible. Y puedes copiar esto de nuevo. Eso es todo para mí. Pero puedes devolver específicamente una propiedad computada en línea. Así que no necesitas agregar nada dentro del cuerpo de la función. Pero nuevamente, si necesitas esta propiedad dentro, entonces puedes hacer referencia a ella. Así que hagámoslo de ambas formas. Tenemos los álbumes del usuario. Hagamos lo mismo para las publicaciones del usuario. Así que const user posts es lo mismo. Permíteme corregir la escritura porque estos retornos, sí, se asemejan estrechamente al tipo, pero no es exactamente el tipo. Así que pasemos el argumento de tipo genérico porque esta es una colección de publicaciones de usuario. Y podemos hacer lo mismo aquí, ¿verdad? Esto será una colección de álbumes de usuario. Así que ahora tenemos todo listo y podemos devolverlo. Sí, publicaciones del usuario. Así que estamos devolviendo todo lo que necesitamos y también esperamos todo lo que necesitamos aquí en este número de ID de usuario. Creo que esto es lo suficientemente bueno para comenzar a intentar trabajar con esto. Entonces, nuevamente, por última vez, ¿verdad? O tal vez no por última vez, pero creo que esto es necesario para que te quede claro si estás comenzando con este patrón. Busquemos algún estado reactivo. Esto es estado reactivo porque quieres <a href="/tags/react-components">react</a> cuando alguien o algo mute este estado. Así que viene aquí. A continuación, busca algunas transformaciones. Y cuando pienso en transformaciones, pienso en propiedades computadas, la mayoría de las veces. Así que tenemos una aquí y tenemos otra aquí. Así que se asemejan estrechamente aquí en el mundo de los compostables. Y por último, busquemos algunas mutaciones, ¿verdad? Algunas acciones que mutan estos estados reactivos del primer punto. Y tenemos fetch albums y tenemos fetch posts que también están aquí. Y a veces tienes que buscar algunos efectos secundarios, ¿verdad? Porque podemos observar aquí y hacer algunos efectos secundarios. En este caso, no lo tenemos. Así que creo que esto es lo suficientemente bueno para probar el compostable. Entonces, ¿dónde probar el compostable? No voy a tocar la aplicación. En este caso, nuevamente, solo vamos a conectarlo a los datos del usuario, ¿verdad? Así que vamos a los datos del usuario. Y cerramos esto y también esto y también esto y también esto. Movamos esto a la API de opciones. Así que solo, sé que tienes los commits y las ramas para ver el resultado de todo lo que voy a hacer. Pero dejaré esto como referencia aquí. Esto es un script setup. Y queremos traer, realmente los necesitamos, los componentes. Así que esto, realmente los necesitamos. Pero vamos a traer el compostable. Importa y usa los datos del usuario de los compostables y sí, lo que necesitamos hacer aquí es obtener el, les dije que íbamos a intentar hacer esto usando, no sé, ¿lo hacen ustedes, esta es una cosa oscura. ¿Quieren consumir el compostable desde la API de opciones? ¿Es algo valioso para que lo vean en acción? Porque esto es feo como el infierno. De acuerdo. Increíble. Entonces, ¿saben qué? Deshagámonos de esto por completo. Sí. Necesitamos escuchar esto, ¿verdad? Así que const props. Gracias, Copilots. No soy un gran fanático de Copilot, pero en este caso, estamos ahorrando segundos y segundos para que ustedes vean los detalles, ¿verdad? No yo tambaleándome con esta API todos los días. Sí, tenemos las props. Así que vamos a obtener esto. Obtenemos los álbumes del usuario que están aquí, las publicaciones del usuario que están aquí de use user <a href="/tags/data">data</a> que está pasando este ID de usuario. Eso es todo, creo. Debería funcionar, por cierto. No les mostré los resultados y, por supuesto, necesitamos obtener, ¿verdad? No estamos obteniendo aquí. Así que no solo las colecciones, también la obtención, ¿verdad? Y estábamos haciendo esto también aquí al principio, aquí en los datos del usuario. Así que también vamos a desmontar, sí. Eso obtiene los álbumes y las publicaciones. Esto funcionará. Sí. Y funciona, como puedes ver. Pero intentemos esperar esto porque esto devuelve una promesa, ¿verdad? Esto es una función. Así que podríamos usar Promise.all porque esas dos colecciones no están entrelazadas, pero solo por simplicidad, aguántame. Espera, espera. Y esto nos dará algunos otros tipos de problemas, ¿verdad? Porque esto espera suspense que solo... No sé si está listo para la API de opciones. No sé, pero pongamos esto en un bloque de suspense que básicamente esperará todo y también tiene algunas ventajas porque, por ejemplo, aquí puedes poner una plantilla. Es fallback. Sí. Gracias, Copilot. Porque no recordaba exactamente el nombre y puedes ver `cargando`. Hagámoslo muy claro. Así que ahora aquí, puedes esperar una nueva promesa que dure cuatro segundos. Así que esto, creo que también necesitamos, sí, creo que uno, dos, tres, cuatro. Bueno, tal vez conté demasiado rápido, pero como puedes ver, hay algunas posibilidades para manejar el estado de carga de cada operación. Y no solo desde el componente más interno, cada componente dentro del suspense que tiene alguna operación asíncrona o espera algo se abordará junto dentro del bloque de suspense, ¿verdad? Como puedes ver,

Cada componente dentro del bloque de suspense que tiene alguna operación asíncrona o espera algo se abordará junto dentro del bloque de suspense, ¿verdad? Como puedes ver, eliminamos todo de los <a href="/tags/data">data</a> del usuario y la cosa sigue funcionando. Para mí, esto es suficiente. ¿Por qué? Porque no estamos usando mixins. Estamos usando, permíteme abrir un mixin aquí solo para dejarlo claro. Esto es un mixin. Y nuevamente, ¿qué sucede si en el otro mixin, llamo a un método, con el mismo nombre, y estamos usando ese método dentro del mismo componente? Tenemos un problema, ¿verdad? Solo el último de esos métodos, dependerá absolutamente del orden de carga de esos mixins, ¿verdad? Y también la capacidad explosiva. Estamos exponiendo todo. Aquí, exponemos lo que realmente queremos. Y también en ese sentido, hay otra API que es de solo lectura. Entonces, porque ahora, por ejemplo, intentemos, solo por el bien de <a href="/tags/testing">testing</a>, expongamos las publicaciones, ¿verdad? No lo queremos, pero lo estamos haciendo. Entonces aquí, seleccionamos las publicaciones. Y aquí, por ejemplo, pongamos posts. Set timeout. Y no cinco segundos. Sí, cinco segundos. Posts. Value. Push. Ah, aquí está. Estamos agregando otra cosa dentro de las publicaciones. Y esto es completamente inesperado. Y esto es obvio aquí. Pero pensemos en cualquier otro punto de la aplicación, en algún lugar se está mutando el estado sin que lo sepamos, etc. No debería suceder, ¿de acuerdo? Pero puede suceder. Entonces, en este caso, si recargo, verás una nueva publicación, ¿verdad? Pop in. Sí, ahí está. ¿Verdad? Esto no es esperado. Pero podemos hacerlo de solo lectura, ¿verdad? Podemos hacer que las publicaciones, sean de solo lectura. Read, no. Read only posts. Entonces ahora, si intento, verás que, hey, esto es un objetivo de solo lectura. Muy útil. Podemos hacer lo mismo, por ejemplo, aquí en este álbum de usuario, de solo lectura. Y ahora, si verificas, sí, perdemos el tipo. Porque es una referencia de solo lectura de solo lectura, un poco incómodo. Y, por supuesto, esto está dando error ahora. Debería funcionar exactamente igual, por supuesto. Arreglemos esto, porque esto espera una cosa y estamos pasando otra, ¿verdad? Entonces, si vamos a los álbumes del usuario, lo que necesitamos aquí es indicar que, hey, hay un tipo de solo lectura profundo. Y esto es genérico. Entonces, solo lectura profundo del álbum de usuario. Ahora <a href="/tags/typescript-libraries">TypeScript</a> está contento, supongo. Sí, lo está. Y esto sigue funcionando exactamente como antes. Entonces sí, puedes configurar todo en un mixin. Incluso veo algunas cosas extrañas sucediendo en mixins con configuraciones a las que puedes pasar parámetros a la función, por lo que es aún más oscuro lo que se hace. Sí, esto es una pesadilla. Los mixins, para mí, realmente no me gustan. Entonces sí, esto funciona bien. Tenemos el suspense. Tenemos el compostable que está funcionando perfectamente. Intentemos eliminar esto. Y además, ya no expondremos las publicaciones. Sí. Solo para dejarlo claro, todavía funciona. Pero para mí, esto es suficiente. Eliminamos esta dependencia de mixin y cuando veo esto, es extremadamente claro lo que espero y lo que estoy devolviendo, sin ninguna duda al respecto. Con mixin, buena suerte. Sí, es tuyo. ¿Dónde está? ¿Dónde está? Sí. Es tuyo. Porque read-only es una API tuya. Y esto es, por cierto, como puedes ver, no está muy bien documentado. Tienes que ajustar un poco para hacer feliz a <a href="/tags/typescript-libraries">TypeScript</a>. Realmente no me gusta <a href="/tags/typescript-libraries">TypeScript</a>. Lo siento, chicos. Me gusta una herejía. Pero sí, tengo que usarlo en mi trabajo, pero realmente no me gusta trabajar con él. Pueden crucificarme. De acuerdo, último paso de este primer escenario. Tenemos esto, ¿verdad? Y ¿qué vamos a hacer aquí? Porque como dije, para mí esto es suficiente, sin ninguna duda al respecto. Porque ya no estás usando mixins, al menos. Tienes un lugar centralizado con todo el estado, todas las transformaciones, todas las mutaciones, todos los posibles efectos secundarios de estos estados en un solo lugar. Entonces para mí, y estás usando la API de Composición y también exponiendo lo que realmente necesitas e incluso yendo más allá, si realmente necesitas exponer algo, al menos puedes hacerlo inmutable. Así que hay muchas ventajas, para ser honesto. Pero podemos ir más allá, ¿verdad? Porque mantener este flujo de propiedades, ¿por qué? Porque sí, las propiedades están ahí para eso, ¿verdad? No hay ningún problema en absoluto. Pero ¿qué sucede si este post del usuario vive en cualquier otro lugar? Porque esto es una afirmación, ¿verdad? Estamos diciendo que esto debería vivir en el mismo árbol de componentes. ¿Verdad? Y eso es lo que es. ¿Está cambiado esto? Increíble. Pero ¿qué sucede si cambia? De repente, tienes que empezar a hacer algo. Así que solo como experimento, vamos a eliminar todo este flujo de propiedades y vamos a hacer que el compostable esta vez se encargue de todo, porque mutaremos el compostable estableciendo el ID de usuario. Mutaremos el compostable obteniendo y seleccionando estados de los álbumes del usuario y las publicaciones del usuario. Entonces no estamos haciendo que estos componentes sean más inteligentes de lo que eran, porque estaban seleccionando el estado de una propiedad y ahora de un compostable, para mí es lo mismo, ¿verdad? Es diferente origen, misma información. Pero este origen es ubicuo, puede estar en cualquier lugar, ¿verdad? Entonces, en mi humilde opinión, hace que este tipo de componentes sean mucho más reutilizables, ¿verdad? En tu dependencia y en el árbol de componentes de tu aplicación. Así que hagámoslo. Dado que tenemos que establecer el ID de usuario en la aplicación, aquí mismo, creo que tenemos que crear un método para ello. Tenemos que dejar de depender de la ejecución de los <a href="/tags/data">data</a> del usuario, sino en una función específica. Entonces, función set user ID, y el ID es un número, y user ID, tenemos que crear, por supuesto, tal vez aquí const user ID es una referencia de un número, y así null, y al principio, esto null. ¿Por qué no undefined? Porque si yo,

Pensé que alguien dijo algo. De acuerdo. Si no pongo esto, tal vez estés pensando, no, es una ref de null, y eso es todo. Sí, el ID de usuario es un número o undefined. Para mí, undefined es el valor de retorno específico de ambas operaciones. Así que es más fácil, es más difícil rastrear la línea, pero si especificas null en este tipo de situaciones, para mí es mucho más fácil, porque null es como algo explícito que sucede, ¿verdad? Entonces el valor del ID de usuario es igual al ID, y ¿qué sucede aquí? Valor del ID de usuario. Ref del número del ID de usuario. Ah, por supuesto, tengo que eliminarlo aquí. Sí. Tenemos que exponerlo. Entonces, tal vez al principio. De acuerdo. Establecer ID de usuario, el resto es igual, para ser honesto. Entonces, vamos aquí y movamos estas dos API de Composición, agregando un setup. Y no necesitamos esto. Ya no necesitamos nada de esto. Entonces, estamos extrayendo el compostable. Entonces, importamos use user, user <a href="/tags/data">data</a>. De composables, y establecemos un ID de usuario. Esta es una oportunidad. No sé quién estaba preguntando sobre esto, pero tal vez esta función podría vivir fuera de aquí, e importarla de manera diferente. Solo la función. Tal vez esto no es un buen candidato para esta situación, porque es necesario establecer el ID de usuario, pero te adelanto que a veces solo exporto la cosa fuera de la función, por lo que es como dos situaciones diferentes, pero sigamos con esto. Const, será establecer ID de usuario. Y composables, use user <a href="/tags/data">data</a>, use user <a href="/tags/data">data</a>. ¿Qué sucede aquí? Estaba escribiéndolo mal. Entonces, establecer ID de usuario uno, y ya no necesitamos esta propiedad. Entonces, si vamos a los datos del usuario, sí, ya no necesitamos esto tampoco. No lo necesitamos aquí. Y tampoco necesitamos las colecciones, ni las propiedades, porque vamos a obtenerlas del compostable. Entonces, sí. Y en los álbumes del usuario, y los álbumes del usuario están aquí, publicaciones. Ten en cuenta que solo estamos obteniendo las funciones de obtención de información. Entonces, nuevamente, voy a extraer esto de aquí. Y para ser honesto, no creo que necesitemos nada de esto más. Entonces, y para las publicaciones del usuario y los álbumes del usuario, solo voy a seguir con esto. Entonces, ya no vamos a necesitar esto más. Entonces, sí. Y voy a pasar esto y para las publicaciones del usuario y los álbumes del usuario, necesitamos constante álbumes del usuario. Igual a, uso de datos del usuario. Y podemos alias esto para no tocar las plantillas. Y creo que podemos hacer exactamente lo mismo en las publicaciones del usuario. Tenemos que agregar el setup. Y en este caso, son las publicaciones del usuario. Y son publicaciones. Y debería funcionar exactamente igual que antes. Hemos eliminado mucho código, para ser honesto. Es mucho más limpio para mí. Así que probémoslo. Sí, funciona. Entonces, al final, logramos este escenario, ¿verdad? Donde no solo nos deshicimos de los mixins, que en sí mismo es increíble por las razones que realmente conozco. Pero también, estamos usando un compostable que se encarga de todo, para ser honesto. Y es súper ordenado. Y gracias a este compostable, pudimos eliminar mucho datos, muchas sentencias de los componentes. Y ahora mismo, para mí, está súper claro, ¿verdad? Y nuevamente, no estamos haciendo que estos componentes sean más inteligentes de lo que eran. No estamos obteniendo los datos en el componente. Siempre me gusta que mis componentes sean lo más simples posible. Solo estamos cambiando el origen. Estamos obteniendo esto de un compostable. Es cierto que estamos acoplando esto a un compostable. Pero el compostable está en todas partes, ¿verdad? Entonces, no estamos en un lugar estricto en la aplicación. Tiene que ser un componente secundario de tal y tal, ¿verdad? Entonces esto funciona. ¿Alguna pregunta antes de continuar? Debido al await, la vista de datos del usuario no conocerá la vista de publicaciones del usuario hasta que se haya completado la obtención de publicaciones. Entonces, no tengo que lidiar con el caso en el que las publicaciones sean nulas en las publicaciones del usuario. No, no creo. Si vas a las publicaciones del usuario, sí, esto solo funcionará cuando esta cosa de las publicaciones esté hidratada, ¿verdad? Entonces, no, no creo que debas preocuparte por eso. Entonces, probemos esto, ¿verdad? Entonces, movamos estos datos del usuario aquí. Y creemos un use... Perdón, en el compostable, hay un use user <a href="/tags/data">data</a> <a href="/tags/data">data</a> spec.ts. Y todas las cosas de prueba que necesitamos. Entonces, B, expect, describe, eat. Y bueno, importaremos el resto después desde las pruebas. Entonces, ¿qué probar, verdad? Bueno, como siempre, esto no es diferente a cualquier otra prueba unitaria, ¿verdad? Estas son algunas funciones de script al final de las funciones de <a href="/tags/javascript">JavaScript</a>, en el fondo son solo funciones de <a href="/tags/javascript">JavaScript</a>. Entonces, esto no es nada especial. No debemos probar la implementación, por supuesto, porque esperamos que las API reactivas de <a href="/tags/vue-3">Vue</a> estén perfectamente probadas. Pero debemos probar el resultado. Y en este caso, por ejemplo, podríamos probar que tenemos la URL correcta cuando intentamos obtener las publicaciones o los álbumes. Y si estamos hidratando los álbumes en la publicación con la información correcta. Y también, si las transformaciones están devolviendo la publicación o los álbumes específicos del usuario y no todas las publicaciones, creo que esto es probable. Pero cualquier cosa más allá de eso es la implementación de <a href="/tags/vue-3">Vue</a>, ¿verdad? Así que no me importa eso. Sé que lo siento, definimos las refs globalmente no dentro del compostable. Encontraremos las refs globalmente no dentro del compostable. No entiendo la pregunta, lo siento. ¿Refs globalmente dentro del compostable? Definimos las refs globalmente no dentro del compostable. Sí, aquí, buena pregunta. Porque mira. Cada vez que ejecutamos los datos del usuario y en este último escenario, estamos usando los datos del usuario aquí, aquí, aquí y aquí. Cuatro veces vamos a ejecutar esta función. Si lo ponemos aquí dentro, como puedes ver, no hay error sintáctico, ¿verdad? Pero este es un compostable sin estado. Sin estado no en el sentido de que no tenemos un estado.

Tenemos un estado. Pero este estado no será único. Se recreará cada vez que ejecutemos este use user <a href="/tags/data">data</a>. Y como dije, es uno aquí, dos, tres y cuatro veces. Entonces, cuatro veces el ID de usuario, álbum y publicación se recrearán. Eso no es lo que queremos. Queremos que esto sea único para cada implementación del compostable porque puede ser hidratado y mutado desde N partes del sistema. Entonces, lo que queremos que sea único por implementación es la propiedad computada. Pero la propiedad computada se basa en valores que están fuera de la función, que son compartidos, únicos. Es como un patrón singleton, ¿verdad? Por favor, dime si respondí tus preguntas. Si esto es lo suficientemente claro, quiero decir. Ok, increíble. Entonces, déjame volver a esto porque creo que vamos a probar, vamos a probar. Probar si el fetch vocal con la URL correcta y también si obtenemos, por ejemplo, las publicaciones y los álbumes correctamente. Veamos el compostable, ¿verdad? Porque este es la fuente de verdad. Estamos filtrando aquí, sí, y los filtramos por ID de usuario. Y podríamos ir más lejos, pero empecemos solo con esto. Necesitaré alguna forma de simular cosas para las publicaciones. Comencemos con las publicaciones. Entonces, voy a ir a la API que está aquí, por cierto, esta es la API. Es extremadamente fácil de usar y perfecta para demostraciones. Estamos hablando de publicaciones, ¿verdad? Entonces, las publicaciones tienen esta morfología. Entonces, creemos una constante respuesta de publicaciones, lo que sea, será una colección de esto. Entonces, eliminemos las comillas y esto es un cuerpo. Tampoco necesitamos esto y eso y eso, sí. Creo que esto es suficientemente bueno para el ID de usuario uno. Entonces, creemos una constante ID de usuario igual a uno y copiemos y peguemos esto una vez más. Y otra vez. Y formateemos los documentos y esto será para el ID de usuario uno, pero esto será para el ID de usuario dos, ¿verdad? Entonces, aquí ID tres, ID dos, ID uno. Entonces, esta es una buena manera de probar si tenemos la información correcta. ¿Por qué estoy haciendo esto? Porque quiero simular o espiar, lo siento. No quiero cambiar la implementación de fetch porque eso es lo que estamos usando, este fetch. No quiero probar fetch. Solo quiero saber si este fetch devuelve la carga correcta, esta respuesta e hidrata mi implementación. No las implementaciones de fetch o las implementaciones de API reactivas. Entonces, creemos eso, ¿verdad? Creemos una constante espía de fetch igual a v Spy on, y por cierto, no soy experto en pruebas unitarias, como probablemente puedas ver, pero esto es global, ¿verdad? Entonces, simular valor resuelto y esto, si recuerdo correctamente, debe devolver un riesgo. Tenemos que imitar esto, ¿verdad? Entonces, tenemos que agregar este método JSON que estamos usando. Entonces, es como, eh, vamos a devolver una promesa resuelta que también tiene un método JSON. Sí, eso es esto. Pero a <a href="/tags/typescript-libraries">TypeScript</a> no le gusta. Y creo que es porque esto es una respuesta en sí misma, ¿verdad? Entonces, tal vez podamos hacerlo feliz como respuesta. No, por supuesto que no. Dios mío. Promesa resuelta. Vamos poco a poco. Sí. Entonces, necesitamos devolver una promesa resuelta algo. Y ese algo es una respuesta. Entonces, no le gusta. Promesa resuelta y esto también. Creo que esto está bien. No sé por qué. Déjame intentar con otra API, espía de fetch, porque tenemos este BSP en. En lugar de simular valor resuelto, hay algún simulacro o resolución. Lo siento, chicos. Esto es simular valor resuelto. Esto también es una promesa, ¿verdad? Entonces, podemos agregar estos métodos JSON. Sí. Increíble. No sé por qué esto no estaba funcionando. No me importa, para ser honesto. Entonces, tenemos una forma de simular y espiar el fetch. Y esto está devolviendo, ¿verdad? Devolviendo lo que necesitamos. Sí. Promesa de respuesta. Sí. Lo dejaré como una afirmación. Sé que esto es mucho más feo. Pero lo dejaré exactamente como está. Entonces, tenemos la respuesta simulada. Estamos simulando todo esto. Entonces, lo que necesitamos aquí es describir lo que vamos a probar, ¿verdad? Entonces, dije al principio que llama a fetch con la URL correcta. Entonces, lo primero que vamos a probar es que esto está pasando a fetch la URL correcta. Es esta. Entonces, si lo probamos, por supuesto, pasa. Ahora, sí. Esto es exactamente lo que esperaba. Estamos usando fetch post y user post de use user <a href="/tags/data">data</a>. Estamos esperando, obteniendo las publicaciones. Y no me gusta esto. Me gusta

este. Será exactamente esto. Entonces, si cambio esto, esto será un array con esos dos elementos. Solo el usuario uno. Esto no funcionará. ¿Por qué? Porque no hemos establecido el ID de usuario, ¿verdad? Entonces, en este punto, esto no devuelve nada. Así que permíteme comentar esto porque lo que deberíamos esperar aquí es que esto esté vacío. ¿Correcto? Entonces, ahora, si establezco el ID de usuario, no sé quién preguntó antes si esto debería reevaluarse. Vamos a probarlo. Establecer ID de usuario y ahora el ID de usuario nuevamente es 1 aquí. Esto también debería funcionar. Porque estamos obteniendo solo la publicación que tiene el ID de usuario 1. Así que hagámoslo. Y funciona. ¿Correcto? Entonces, ¿qué más podemos probar? No quiero convertir esto en un <a href="/tags/workshop">workshop</a> de pruebas, ¿verdad? Solo quiero darte una buena experiencia de lo que es probar un composable. Entonces, podemos hacer exactamente lo mismo. No lo haré para los álbumes porque es lo mismo, como puedes ver. Es exactamente lo mismo. Estamos esperando la respuesta. Lo estamos haciendo en función del ID de usuario, algún álbum de usuario. Así que creo que esto está bastante claro en mi conocimiento. No sé si quieres podemos ir al último paso. Podemos hacerlo porque ¿qué falta aquí, verdad? Para mí, supongo que necesitas probar esto cuando intentas jugar con tu código. Establecer algo como indefinido o nulo o algún tipo que sea completamente inesperado y ver si tu código se rompe. Entonces, por ejemplo, por ejemplo, establezcamos el ID de usuario. A algo que no tenemos. No tenemos el ID de usuario 3. Entonces, esto debería ser igual a un array vacío. Y lo es. Y nuevamente, podríamos ir más allá pero es una hora para este ejemplo. Así que creo que esto es suficiente para ver todo el recorrido, ¿verdad? Desde el uso de la API de opciones y no uno, sino dos mixins. Dos, usando la API de composición y confiando en un composable que ofrece estado y mutaciones. Esto es con todo. A tres, incluso más confianza en el composable para que todas las piezas de la aplicación estén completamente libres, por así decirlo, para ser colocadas en cualquier lugar. ¿Correcto? Y solucionando todos los problemas inherentes de los mixins. Entonces, antes de pasar al escenario dos, ¿tienes alguna pregunta?

Vale. ¿Deberíamos usar una propiedad computada para hacer pruebas? Si la propiedad computada no funciona correctamente, nos dará un error. No entiendo. Daniel, lo siento. ¿Deberíamos usar una propiedad computada para hacer pruebas? Bueno, estoy probando, sí, estoy probando una propiedad computada porque ahí es donde básicamente está toda la información que necesitamos, Brian, ¿probar la referencia directamente? No lo sé. Sí, podemos hacerlo, por supuesto, porque, sí, hagámoslo. Pero para mí, la fuente de verdad, te explicaré mi razonamiento, ¿de acuerdo? Y para mí esto no es bueno ni malo. ¿Qué es esto? No se trata de que estés equivocado o de que yo esté equivocado y tú tengas razón, etc. Es como, vale, podemos probar la por ejemplo, la referencia a las tareas pendientes, pero hay una forma de probar la referencia directamente. Y para mí es probar la propiedad computada porque la propiedad computada se basa en la referencia. Entonces, si la propiedad computada devuelve lo que necesitamos, algún tipo de filtro de información transformada, esto también significa que la referencia sobre él o ella también está funcionando. Así es como pienso. Pero de nuevo, sabes que las pruebas en <a href="/tags/angular">Angular</a> son como, sí, puedes hacerlo más o menos como quieras. Pero podemos hacerlo, sí, podemos. Creo que podemos hacerlo fácilmente, pero hay un problema. Ni siquiera estamos exponiendo las referencias, como puedes ver. Entonces, deberíamos exponer la referencia. Solo un experimento muy rápido, ¿de acuerdo? Publicaciones. Entonces, ahora, digamos que se hidrata las publicaciones en consecuencia o algo así. Entonces, tenemos algo asíncrono sucediendo aquí. Vale. Entonces, ¿qué necesitamos? Necesitamos un setUserId. Sí. ¿Qué tal si usamos composables, pero al final terminamos devolviendo todo? Sí. Pero no es nuestro caso. No es nuestro caso. Creo que esto es extremadamente fácil, o no extremadamente fácil. Estamos haciendo muchas cosas aquí. No es el más complejo. Te lo concedo. Pero si resolviendo un problema real, porque no quería usar los ejemplos típicos, nieto, hijo, padre. Quería que fuera algo visible, ¿verdad? Entonces, creo que este patrón resuelve muchos problemas, ¿verdad? Pero en este caso, solo estamos exponiendo cosas que no son fácilmente mutables, como una propiedad computada. Si intentas agregar algo usando push a una propiedad computada de tipo array, no se replicará. Esto no se rastreará. Entonces, puedes modificarlo, pero no recreará un proceso de renderizado. Así que creo que esto está hecho con cuidado. Pero vayamos con tu ejemplo. Sí, creo que esto es increíble. Ya no necesitamos esto. No es userPosts, es posts y posts debería devolver todo, ¿verdad? ToEqual se llama postResponse. Y necesitamos esto antes. Para ser honesto, ni siquiera necesitamos establecer el ID de usuario porque esto funcionará en otros lugares, ¿verdad? Solo necesitamos el ID de usuario cuando queremos filtrar. Entonces, está bien, solo necesitamos fetchPosts y el ID de usuario ya no es necesario. Así que esto debería funcionar y funciona. Y los tres también funcionan. Así que, sí, lo dejaré aquí, ¿de acuerdo? Como un comentario por estudiante por asistente para experimentar. Entonces, sí, pero en este caso, no necesitamos esta publicación, ¿verdad? No la necesitamos aquí porque queremos que sea completamente privada. Si no la expones aquí o, por supuesto, pones este punto, no hay forma de que puedas interferir con esto. ¿De acuerdo? Entonces, solo exponemos lo que necesitamos para este ID de usuario, solo las tareas pendientes, lo siento, los álbumes y las publicaciones que son específicamente para este ID de usuario. El resto, no me importa. Así que no lo expongo. Pero aún así, tenemos esto. ¿Hay alguna otra pregunta? ¿Podemos seguir adelante? Gracias a ustedes por sus preguntas. Así que crearé un comentario solo para decir que esto termina de todo. Así que termina. Y pasemos al segundo escenario. Que es este. Este es un escenario aún más complicado, ¿verdad? Porque lo que quería mostrarte en este pequeño masterclass son los patrones comunes o los problemas comunes que los componibles solucionan, ¿verdad? O resuelven. Uno de ellos eran los mixins, ¿verdad? Tener una única fuente central de verdad para todo lo relacionado con el dominio del usuario, mutaciones, efectos secundarios. Todo está ahí, ¿verdad? Y también solucionar los problemas típicos de los mixins. Y hay mucha gente que todavía usa la API de opciones. No porque lo quieran, sino porque no tienen el conocimiento y no lo han intentado y no han dedicado tiempo. Y lo entiendo, ¿verdad? Porque estás muy ocupado en tu trabajo, a veces no tienes tiempo para experimentar y así son las cosas, ¿verdad? Pero esto es exactamente por qué quería hacer este tipo de ejercicio. En el segundo ejercicio, asumimos que estamos usando la API de Composición, pero queremos abordar un problema diferente. El problema con el prop drilling e incluso el throttling o frothing. No lo sé, para ser honesto. Pero, ¿qué quiero decir con eso? Te mostraré el código ahora. Tenemos una aplicación. Déjame beber algo. Así que espero que esto les parezca interesante, chicos. Tenemos una aplicación que sirve el ID de usuario, como antes. Y tenemos dentro de esta aplicación el componente hijo datos de usuario. Y este también tiene dentro como un componente hijo el perfil de usuario. Y este perfil de usuario tiene las tareas pendientes del usuario, ¿verdad? Entonces, cada componente está dentro del componente superior. Y este perfil de usuario y las tareas pendientes del usuario están consultando la base de datos para obtener los datos del perfil y las tareas pendientes. Entonces, están usando estado y mutaciones para obtener esta información. Y ¿qué están haciendo? Por cierto, esto es prop drilling, ¿verdad? Desde la aplicación hasta los datos de usuario, desde los datos de usuario hasta el perfil de usuario, desde el perfil de usuario hasta el usuario hasta las tareas pendientes del usuario. La misma propiedad. Esto es muy exagerado. Esto está específicamente construido para esto. Pero en mi trabajo, vi escenarios algo similares, aunque no lo creas, ¿verdad? Pero estamos haciendo exactamente lo mismo con los eventos. Porque queremos mostrar el nombre de usuario que está mutando y cuántas tareas pendientes hay completadas en el primer componente, en los datos de usuario. Pero la obtención de datos está sucediendo aquí. Entonces, ¿qué deberíamos hacer? Entonces, vale, estamos pasando eventos. Estamos emitiendo props, de arriba hacia abajo, lo mismo. Y estamos emitiendo eventos, de abajo hacia arriba, lo mismo, una y otra vez hasta que obtenemos esto. Y si estás pensando, oye, ¿por qué no improvisas e inyectas? Sí, por supuesto en este caso, funcionará perfectamente. Pero será algo extraño pasar devoluciones de llamada y funciones de mutación a lo largo de la línea. Pero funcionará porque provide e inject necesitan el mismo árbol de componentes.

Y lo estamos. Pero ¿qué sucede si luego este perfil de usuario se mueve a un hermano de la aplicación, por ejemplo? Sí, entonces tenemos problemas, ¿verdad? Permíteme mostrarte el <a href="/tags/code">code</a>. Permíteme cerrar todo. Permíteme pasar al escenario en vivo 2. Permíteme recompilar. Solo para asegurarnos de que todo esté funcionando. Vamos a probarlo. Sí. Ahí está. Este es el perfil de usuario. Mira aquí. Porque si cambio el nombre, se actualiza. Y si cambio las tareas pendientes, el número de tareas pendientes también se actualiza en consecuencia, ¿verdad? Entonces, si cierro y abro, porque a veces esto hace cosas graciosas, tenemos la aplicación, el usuario <a href="/tags/data">data</a>, el perfil de usuario, las tareas pendientes del usuario, siempre con el mismo ID de usuario. Permíteme mostrarte el <a href="/tags/code">code</a>. Si abrimos la aplicación, nuevamente, finjamos que esto proviene de algún tipo de autorización. Lo siento, <a href="/tags/authentication">authentication</a>. Y es el número 1. Y lo estamos pasando a los datos del usuario. De acuerdo. Si abro los datos del usuario, estamos obteniendo la propiedad. Y la estamos pasando al perfil del usuario. De acuerdo. Si abro el perfil del usuario, lo obtengo, lo paso a las tareas pendientes del usuario. De acuerdo. Y finalmente lo obtenemos para hacer todas estas cosas locas aquí. Bueno, no locas, ¿verdad? Es más o menos lo mismo que hemos hecho en el pasado. Pero lo estamos haciendo en el componente, ¿verdad? No hay nada malo en esto. Pero podemos hacerlo mejor, en mi opinión. Entonces, ¿qué estamos haciendo para compartir la información hacia arriba? Estamos emitiendo eventos. Desde la parte más inferior, estamos emitiendo estas tareas pendientes completadas. Estamos escuchando aquí y emitiendo nuevamente. Entonces, al final, estamos escuchando dos eventos diferentes. Actualizar el nombre de usuario y actualizar las tareas pendientes completadas. Entonces, cuando esto sucede, abordamos estos dos callbacks. Y luego mutamos esas dos referencias reactivas. Y al final, cambiamos y reevaluamos esta parte de las plantillas. Entonces, nuevamente, esto funciona. Y funciona bien. Pero tiene algunos problemas, ¿verdad? ¿Esto está lo suficientemente claro? ¿Chicos? El problema, el escenario, todas las cosas que tenemos aquí. Lo creas o no, esto es muy exagerado, lo sé, pero esto está sucediendo en la vida real. Entonces, permíteme mostrarte lo que vamos a hacer. Bueno, nuevamente, dos pasos, ¿verdad? El primero es esto. Vamos a, sorpresa, sorpresa, usar un composable para obtener todo. Y como puedes ver, este throttling de eventos y este prop drilling se acabaron. Ya no los necesitamos, ¿verdad? Tendremos que establecer en algún lugar, en cualquier lugar, el ID de usuario. Pero una vez establecido, funciona. Y extraeremos el estado aquí, el estado único para ver este nombre y cuántas están completadas, etc. Y necesitaremos estado y mutaciones para el perfil de usuario y las tareas pendientes del usuario. Pero creo que solo con esto, esto cambia mucho mejor, como puedes ver en el diagrama. Entonces, comencemos. Y nuevamente, tenemos este proceso de tres partes, ¿verdad? Entonces, vayamos a la segunda, al lado. Creemos un <a href="/tags/react-hooks">use state</a>. Y si hay dos composables que son muy comunes en <a href="/tags/vue-3">Vue</a> e incluso en <a href="/tags/react-components">React</a>, lo que se llama hooks, creo, pero el concepto, creo, es el mismo. Es decir, usar un estado y usar sorpresa, porque es la siguiente parte que vamos a construir aquí en este escenario. Pero este estado es uno de ellos. Sirve para, como dije, recopilar el estado global de la aplicación. Entonces, tienes algún tipo de patrón de almacenamiento de <a href="/tags/data">data</a> centralizado para todo lo que haces. Solo estados. Entonces, nuevamente, tres partes, ¿verdad? Estados reactivos, transformaciones y mutaciones. Entonces, estado reactivo, ¿qué necesitamos aquí? ¿Qué tenemos que hacer? ID de usuario. De acuerdo. Sigamos la línea. Tendremos que tener esto. No necesitamos aquí un fragmento de estado. Perfil de usuario. Usuario. Completado. Esto será una transformación. Entonces, ID de usuario y usuario como estado. Estado reactivo. Completado de las tareas pendientes como una transformación. Obtener publicaciones de usuario como una mutación. Y creo que desde aquí no necesitamos nada más, ¿verdad? Bueno, abramos el perfil. Tareas pendientes como estado reactivo, tareas pendientes del usuario como una transformación. Completado de las tareas pendientes. Ya lo tenemos. Obtener tareas pendientes del usuario como una mutación. Alternar estado de las tareas pendientes como una mutación. Y creo que esto es suficiente, ¿verdad? Entonces, esto es lo que deberíamos extraer de los componentes que están dispersos. Esta lógica. Lo que quiero decir es, y esta es la magia de este patrón. No tienes que aprender nada nuevo. No tienes que agregar nada nuevo. Solo tienes que mover todas las piezas a un lugar diferente. Te lo concedo. Pero ya estás usando este tipo de estado e interacciones. Entonces, para eso, es extremadamente fácil comenzar a usarlo. Entonces, nuevamente, comencemos, ¿verdad? Exportemos

función use states. De acuerdo. ¿Qué necesitamos aquí? ¿Dónde colocamos este ID de usuario, verdad? Gracias, pero no necesito esto. No. Entonces, nuevamente, queremos mutar desde la aplicación. El ID de usuario. Entonces, necesitaremos un método, ¿verdad? Creo que esto es muy comprensible. Entonces, lo que necesitamos aquí es la forma correcta de colocar las cosas. Sigamos adelante con tener una función que espere un ID de usuario. Entonces, creémoslo. Y podemos ir a la aplicación. Como ya estamos usando la <a href="/tags/vue-composition-api">composition API</a>, vamos a traer esto. Entonces, ref. Y tenemos que poner ref. Importar ref. Permitiré algún tipo de pausa afuera cuando terminemos este escenario para que puedas tomar algo para beber, ir al baño, lo que sea. ¿De acuerdo? Entonces, es una referencia de número o nulo. Es nulo. Entonces, esto ya está aquí. Necesitamos este usuario. Hay un objeto plano. Te explicaré a qué me refiero con eso. Pero déjame extraer el objeto plano y no solo las interfaces, sino también el util. En un momento explicaré porque necesito terminar esto. Entonces, es un objeto plano. Y también necesitamos un todoist. Entonces, necesitamos un usuario todo. ¿Qué es esto del objeto plano? Bueno, el perfil de usuario de esta API viene en un objeto de varios niveles. Entonces, para facilitar la renderización y navegación de la información, creé una pequeña función que transforma cualquier objeto de varios niveles en un objeto plano. Entonces, perdemos el tipo. Podría crear un tipo específicamente para esto con todas estas propiedades en una sola, pero sigamos con esto. Tenemos un objeto plano que es un registro de una clave de propiedad que puede ser una cadena, número, símbolo y cualquier otro. Podríamos ser más restrictivos y poner un tipo conocido e intentar verificar el tipo cada vez. Pero nuevamente, esto no es un <a href="/tags/workshop">workshop</a> de <a href="/tags/typescript-libraries">TypeScript</a>. Esto es un Composable. Pero creo que entiendes el punto. Entonces, para recrear y aplanar toda la estructura, estoy usando estos métodos de aquí que es objeto plano y también este tipo, esta interfaz. Entonces, tenemos el ID de usuario, el usuario y el usuario todoist. Y como puedes ver, lo estoy usando aquí. Entonces, los <a href="/tags/data">data</a> que vienen son un perfil de usuario. Sí, pero lo que estamos mostrando dentro del usuario es la versión aplanada. De acuerdo, vamos. Entonces, tenemos esto. Entonces, creo que necesitamos, deberíamos comenzar a implementar. No creo que necesitemos devolver nada de esto. Creo que esto debería ser, nuevamente, algo que es global y compartido en todas las implementaciones de este Composable. Lo que necesito, o creo que necesitamos devolver, es la versión transformada. Entonces, vamos. Vamos con obtener las publicaciones del usuario. Aquí podemos copiar y pegar. Y lo único que es, no es lo único, esto es exactamente lo que necesitamos. No son props. Eso es cierto. Eso es el valor del ID de usuario. Pero la cosa es la misma, ¿verdad? Entonces, comencemos a exponer las cosas. Y nuevamente, esto no es muy obvio, pero esto nuevamente es un objeto de <a href="/tags/javascript">JavaScript</a>. Podemos devolver obtener publicaciones del usuario. Y en lugar de devolver exactamente la referencia al método original, podemos hacer lo que queramos aquí. Entonces, podemos calcular algo, podemos verificar algo condicionalmente. Esto es muy poderoso. Y para mí, esta es la parte increíble. La parte más increíble de este Composable es que ya tienes las habilidades y ya tienes el conocimiento porque esto es <a href="/tags/typescript-libraries">TypeScript</a> o <a href="/tags/javascript">JavaScript</a>, ¿verdad? Pero en nuestro caso, necesitamos estas publicaciones. Entonces, hagamos lo mismo para las tareas pendientes. Copiemos y peguemos aquí. Entonces, nuevamente, tareas pendientes del usuario, etcétera. Y como puedes ver, eso sucedió antes, ¿verdad? En el último ejemplo. Realmente no estamos lidiando con errores. Solo estamos mostrando una cosa en la <a href="/tags/cli">console</a>. En la siguiente parte de este escenario, vamos a lidiar con esto directamente. Pero esperemos un poco. Terminemos esta parte. Entonces, de acuerdo. Obtener las tareas pendientes del usuario y alternar el estado de las tareas pendientes. Entonces, aquí, hacer. Y esto es lo mismo. Entonces, obtener tareas pendientes del usuario, alternar el estado de las tareas pendientes. De acuerdo. Estamos esperando, estamos devolviendo, lo que necesitamos. Bueno, no todo porque tenemos las tareas pendientes completadas y las tareas pendientes del usuario. Grafiquemos las tareas pendientes completadas, por ejemplo. Pongámoslo aquí. Y como suelo trabajar, entonces, el estado del usuario es como tener todos los métodos de obtención en un composable. No todos los métodos de obtención. Bueno, en este caso, sí, creo que tienes razón. Porque, ¿qué es un estado, verdad? En nuestro trabajo diario de aplicación como front-end, cuando realizamos algún tipo de operación, es una operación asíncrona la mayoría de las veces. Nos conectamos a algún tipo de API para recuperar <a href="/tags/data">data</a>. En esta demostración, estamos usando fetch. Podrías usar Axios, cualquier implementación que desees. Pero estás obteniendo <a href="/tags/data">data</a> de algún lugar. Entonces, sí, en este estado del usuario, si la aplicación es enorme,

aquí podrían aterrizar todas las operaciones fetch. Si tienes una aplicación muy grande y no estás utilizando esta <a href="/tags/architecture">architecture</a> de componentes, sino tal vez una <a href="/tags/architecture">architecture</a> de dominio o característica, podrías tener un composable para cada característica, para cada parte de dominio. Esa sería una solución inteligente porque, de lo contrario, el composable podría volverse increíblemente grande muy rápidamente. Para esta demostración, creo que esto es suficientemente bueno. Y volví a perder el hilo. Ah, okay. Estamos haciendo esto aquí, ¿verdad? La forma en que me gusta trabajar es exponer las transformaciones primero y luego las mutaciones. Entonces, en este caso, tenemos computed para esto. Y computed number. Esto será user para esto. No es user para esto. Es para esto. Lo siento, es porque esto espera user para esto, ¿verdad? Entonces, user para esto. Ni siquiera tenemos computed en este punto. Entonces, user para esto. Esto no son props. Es el valor del ID de usuario. No te preocupes, Daniel. Disfruto mucho de tus preguntas. Realmente disfruto cuando las personas participan. No veo, veo sus caras. Es como un vacío aquí. Y realmente, realmente, realmente quiero que cada uno de ustedes tenga este pequeño conocimiento. Porque, nuevamente, esta es la tercera vez en menos de media hora. Puedes comenzar a aplicar esto hoy o mañana. Estoy muy seguro de que ya conoces <a href="/tags/vue-3">Vue</a>. Hey, esta es tal vez una forma diferente de usar esta API, por supuesto. Pero ya tengo el conocimiento, ¿verdad? Entonces, esto es como un ciclo de retroalimentación súper corto. Entonces, computed para esto. Sí, computed para esto. Lo tenemos. Entonces, el primer post del usuario está listo, listo. Creo que tenemos todo, ¿verdad? Entonces, vamos a devolver. Completado para esto. Y user para esto. Y, nuevamente, el mismo patrón. Esta parte, cuando tenemos todos los datos del usuario. Y el usuario, ¿qué? Necesitamos al usuario, ¿verdad? Sí. Esto también debería ser devuelto. También devuelto. Sí. Y no las tareas pendientes. Solo las tareas pendientes del usuario. ¿Verdad? Creo que esto es lo suficientemente claro. ¿Verdad? Entonces, creo que estamos listos, para ser honestos, chicos. Para intentar usar esto en vivo. Pero hagámoslo. Bueno, esto no está rompiendo ni nada, ¿verdad? Porque no quiero estar media hora. Sí, está bien. Entonces, no necesito esta ref anymore. No necesito esto anymore. Solo necesito el composable. Entonces, importar <a href="/tags/react-hooks">use state</a> de composable state. Y aquí, sí. Creo que es... Déjame revisar esto. No... Fetch user post, fetching post, o user <a href="/tags/data">data</a>. Sí, tal vez... Déjame revisar esto. Esto no está claro. Okay. Tenemos estas tareas pendientes del usuario. Fetch user post. Fetch user to-dos. Sí. Esto no es fetch user post. Esto es fetch user profile. Sí. Muy buen catch. No conozco el post, de dónde vino. Lo eliminaré. Espero que no haya otra referencia a post, porque no hay post aquí. Pero sospecho que si voy aquí. Sí, fetches a post. Fetch user profile. Sí. Muchas gracias. Y déjame poner esto tal como está antes. Y asegurémonos de que esto funcione. Asegurémonos de que esto funcione. Okay. Esto funciona. Oh, hay algo... Está funcionando. Increíble. Gracias. Entonces, nuevamente... Creo que esto ahora es más claro. Fetch user profile.

Obtener las tareas pendientes del usuario. Alternar el estado de las tareas pendientes. De acuerdo. Nuevamente, ya no necesito esto. Ni esto. Entonces, importemos <a href="/tags/react-hooks">use state</a>. Lo siento. <a href="/tags/react-hooks">Use state</a>. De los composables, <a href="/tags/react-hooks">use state</a>. ¿Correcto? De acuerdo. Y const set user ID. Que no tenemos, por cierto. Establecer el ID de usuario. El ID es un número. Y el usuario, un piloto. Haz tu cosa así. Y si vas aquí, establece el ID de usuario. Entonces, set user ID es igual a <a href="/tags/react-hooks">use state</a>. Entonces, set user ID uno. Y estamos haciendo lo mismo. ¿Verdad? Y no necesitamos usar nuestros <a href="/tags/data">data</a> para esto. Porque lo estamos haciendo... Oh, Dios mío. No sé qué hice. Esto es... De acuerdo. Creo que usé alguna combinación extraña de teclas y esto se volvió loco. Pero solo quería eliminar... No sé qué pasó. De acuerdo. Cierro la aplicación y la abro de nuevo. Tal vez sea hora de una pequeña pausa. En serio, chicos. No sé qué pasó. Y esto también rompe una coma faltante. Pero, sí, solo estados. Recarguemos todo. ¿Ahora está listo? Espero que sí. Sí. Entonces, si vamos a este <a href="/tags/data">data</a> de usuario, como ya no necesitamos esta propiedad, no nos ocupamos de ella. No necesitamos esta propiedad. Comencemos primero con el perfil del usuario y las tareas pendientes del usuario. ¿De acuerdo? Entonces, nuevamente, exactamente como hicimos con la aplicación, necesitamos el composable. Como no sé qué partes necesitamos de aquí, sospecho que muy pocas. Comencemos a construir esto. Porque del perfil del usuario, ¿qué necesito? Necesito obtener el perfil del usuario. Y eso es todo. Creo que eso es todo. Entonces, const user y fetch user profile son iguales a user state. Y esto, sí, duplicado, por supuesto. Un salto de fe. Chicos, voy a eliminar todo y ver qué pasa. Ahora tenemos el usuario, pero ya no esperamos esto. ¿De acuerdo? Ah, y esperamos fetch user profile para obtener el usuario. ¿Correcto? Eso es todo. Vamos a las tareas pendientes del usuario y hagamos lo mismo. Estamos utilizando el mismo composable, y estamos esperando las tareas pendientes del usuario. Y estamos esperando. Estamos utilizando el mismo composable, y hagamos lo mismo. ¿Qué necesitamos aquí? Las tareas pendientes. Las tareas pendientes del usuario, ¿verdad? Completadas las tareas pendientes. Y alternar el estado de las tareas pendientes. Principalmente todo, creo. Entonces, las tareas pendientes, no las necesito, porque esto es algo global del composable, así que no lo utilizaré. Pero las tareas pendientes del usuario, las necesito. Las tareas pendientes del usuario. Completadas las tareas pendientes. Y obtener las tareas pendientes del usuario. Y alternar el estado de las tareas pendientes. Nuevamente, eliminemos todo y veamos qué pasa. Movamos esto al final. Y ya no necesitamos esto. Esperar a obtener las tareas pendientes del usuario. Y las tareas pendientes del usuario. Ya no necesitamos las tareas pendientes completadas. Y creo que esto funciona. Establecer el ID de usuario, no. Establecer el ID de usuario, lo hicimos en la jerarquía superior. ¿Verdad? Dijimos que íbamos a esto no está funcionando, chicos, pero aquí. ¿Verdad? Por supuesto, no está funcionando, porque se basa en suposiciones falsas. Entonces, ahora mismo, creo que esto debería funcionar. Usuario <a href="/tags/data">data</a>. De acuerdo. Usuario <a href="/tags/data">data</a>, ya no necesitamos esto. No necesitamos nada. Y también, no necesitamos esto. Entonces, en lugar de las tareas pendientes y el nombre, sí. Para las tareas pendientes, tenemos las tareas pendientes completadas.

igual a la respuesta de las tareas pendientes, y esto no debería funcionar. ¿Por qué? Porque esta es la colección completa, ¿verdad? No me interesa la colección completa. Es solo para el ID de usuario uno. Entonces, hicimos algo extremadamente similar en primer lugar, así que quiero pasar mucho tiempo aquí, solo para que esto pase, y funciona. Entonces, las tareas pendientes están hidratadas, podemos, sí. De nuevo, no sé quién respondió esto antes. Sabemos que las tareas pendientes se hidrataron porque las tareas del usuario se basan en las tareas pendientes. Entonces, si las tareas pendientes no se hidrataron, no obtendremos las tareas del usuario. Entonces, es como, sí, es como una consecuencia, ¿verdad? Podemos decir con seguridad que las tareas del usuario, lo siento, las tareas pendientes funcionan bien, incluso si no estamos exportando y <a href="/tags/testing">testing</a> específicamente. Entonces, ¿qué más? Las tareas pendientes completadas muestran el número de tareas pendientes completadas. De acuerdo, entonces, sí, este no es el mejor nombre, pero quiero hacerlo rápido. Entonces, sí, las tareas pendientes completadas deben ser cero. No sé por qué esto no funciona. Tenemos las tareas pendientes completadas del estado del usuario. Evaluemos cómo funciona esto. Solo necesitamos las tareas pendientes que sean del usuario. Entonces, necesitamos, nuevamente, especificar un ID de usuario. Entonces, necesitamos establecer el ID de usuario y obtener las tareas pendientes del usuario. Entonces, estamos estableciendo el ID de usuario, estamos esperando las tareas pendientes y ahora, estas tareas que estamos devolviendo, todas son sin completar. Entonces, si intento, esto es un número, por cierto, que devuelve un número. No olvides eso. Entonces, debería ser cero, ¿verdad? Y lo es. No, no lo es. Son 11. Ah, es porque no estamos simulando la respuesta. ¿Ves lo que pasa? Lo devolvemos. No, creo que hicimos una operación asíncrona real allí a la colección real. No. Quiero la simulación de la respuesta. Entonces, sí, aquí está. De nuevo, está pasando. Pero lo que quiero hacer también es establecer el toggle también establecer el estado de la tarea, y el estado de la tarea espera el ID de la tarea como un número. estado de la tarea, lo siento chicos, para el número uno, esto ahora no debería funcionar Por ejemplo, intentemos completar la primera tarea que tiene un ID de uno. Entonces, si digo aquí toggle porque tenemos uno, ¿verdad? Entonces, puedo esperar con seguridad que esto ahora sea uno. Y podemos continuar en Aeternum, pero creo que esto está bastante claro en este punto, que estamos bastante claro en este punto, que estamos tratando con funciones de <a href="/tags/javascript">JavaScript</a> o funciones de <a href="/tags/typescript-libraries">TypeScript</a>, pero al final es <a href="/tags/javascript">JavaScript</a>, y solo estamos <a href="/tags/testing">testing</a> la lógica interna de nuestro mundo Composable, no las APIs que provienen del DOM o del navegador como Fetch o de probar el estado de alternar el estado de la tarea, alternar, la URL correcta. Esto es extremadamente fácil de probar y lo dejaré aquí. Entonces, creo que esto debería ser el primero, pero lo que sea. Entonces, creo que también Opilot va a hacer un trabajo increíble, y lo está haciendo. Y es cierto, está obteniendo, establecer el ID de usuario. Esto no es cierto. No necesitamos establecer el ID de usuario para llamar a fetch, así que no necesitamos esto, pero necesitamos esto. Entonces, esto debería pasar y pasa y funciona. Y solo para dejarlo muy claro, si escribo mal la URL, esto no funcionará, ¿verdad? Entonces, basta. ¿Alguna duda aquí? ¿Alguna pregunta? ¿Alguien? Nos estamos acercando al final, chicos. Así que asumo que todo está claro. Entonces, ahora lo que podemos hacer, tenemos este escenario, ¿verdad? Tenemos un Composable aquí solo para manejar estas operaciones asíncronas que tenemos ahora, ¿verdad? Porque, ¿por qué? Porque esto está funcionando bien. No tengo ningún problema. Pero sí, manejar el error. Y nuevamente, podemos verificar si este <a href="/tags/cli">console</a> log está funcionando, chicos. Entonces, es <a href="/tags/cli">console</a> error cuando una función asíncrona falla. ¿Verdad? Entonces, tendremos que espiar const <a href="/tags/cli">console</a> error, <a href="/tags/cli">console</a> espiar. Por así decirlo, no importa. Y luego, sí. Estamos, sí, obteniéndolo para espiar. Sí. Entonces, ahora podemos intentar obtener algo, ¿verdad? Entonces, obtener tareas de usuario para esto, por ejemplo, esperar obtener tareas de usuario para esto. Y podemos decir que, sí, <a href="/tags/cli">console</a> espiar ha sido llamado con nuevo error. No se pudo obtener. No estoy tan seguro de que esto esté funcionando. Sí. Aquí está. No se pudo obtener y está aquí. Y podemos decir que no estamos rastreando ningún mensaje, ¿verdad? Pero creo que esto está lo suficientemente cerca. ¿Verdad? Porque no estamos almacenando el error en ningún lugar. De acuerdo. Lo dejaré aquí. Asegurémonos de que esto esté funcionando. Todo está funcionando. Y nuevamente, pero esta es la versión del hombre pobre, ¿verdad? Del manejo de errores. Podemos hacer lo que queramos en esta cláusula catch. Pero tenemos que repetirlo cada vez. Y tal vez no sea la solución más sabia. Entonces, ¿qué deberíamos hacer? Podemos crear otro Composable, el Composable de sincronización de usuario para manejar todas las operaciones asíncronas en la aplicación. ¿Verdad? Entonces, hagámoslo ahora. Creémoslo aquí. Usar sincronización de usuario. Esto es otro típico. El estado del usuario es uno y el usuario sincronizado es otro. Entonces, ¿qué necesitamos para esta operación de sincronización de usuario? Bueno, esperaremos vamos a escribir esto como un genérico. Tipo T y esperaremos una función que será una promesa de T. De T. ¿Verdad? Y eso es todo, ¿verdad? Porque lo que queremos es imitar lo que hacemos aquí. Teniendo esta cláusula try catch aquí. Entonces, vamos a intentar, ¿verdad? Tenemos un resultado y tenemos un error. ¿Verdad? Y tenemos un estado de carga. Entonces, completaré esto. Lo crearé yo mismo. ¿Verdad? Entonces, <a href="/tags/data">data</a> es ref, aquí. No quería hacer esto, pero, sí,

ese soy yo. Permíteme desglosar esto y eliminar lo que no necesitamos. Permíteme importar y explicar a ustedes lo que estoy haciendo. Entonces, estamos tratando de crear un composable solo para operaciones asincrónicas para lidiar con este bloque try-catch y capturar los errores, hacer lo que sea necesario. Para hacer eso, voy a crear un composable que se consumirá donde sea que necesitemos una operación asincrónica. Eso significa también dentro de este composable. Pero también podría usarse fuera de este composable. Donde sea que necesitemos algún tipo de operación asincrónica, podemos usar esto. Entonces, la API de este composable, tengo un <a href="/tags/data">data</a>, tengo un error y una carga. ¿Verdad? Y esto es del mismo tipo de la función en sí. No sé quién preguntó antes si hay diferencia entre devolver esto dentro de la función o no. En este caso, quiero que este composable sea sin estado. No quiero mantener ni compartir ningún estado. <a href="/tags/data">Data</a>, error y carga deben ser únicos para cada implementación. Cada vez que uso un composable, es un <a href="/tags/data">data</a> diferente, un error diferente y un estado de carga diferente. Si lo movemos arriba, nuevamente, lo compartiremos con todas las implementaciones. No queremos eso. Espero que esto esté claro. Entonces, no quiero exponer una función. Iré directamente con el try-catch y el pensamiento. Entonces, ¿qué es el try-catch? El valor de <a href="/tags/data">data</a> es una función de espera. Esto es async, por cierto. Esto era async antes, lo siento. Una función de espera. Déjame ver. Estudiante. Tipo de parámetro de estudiante...... Oh, sí. Lo siento. Gracias. Sí. Es una función que devuelve una promesa de este tipo. No una promesa de este tipo. Gracias. Sí. Quiero ser rápido, pero sí. De acuerdo. Problemas. El tipo de espera no es async. De acuerdo. Haré una afirmación y eso es todo. Vamos a extraer las props de view. Entonces, bien. El valor de desactivación es verdadero. Está cargando. Valor de carga mientras sea verdadero. El valor de desactivación finalmente es falso. No necesitamos cargado. No tenemos ejecutar. Aquí, sí. Tenemos que ser seguros en cuanto al tipo, ¿verdad? Tenemos que asegurarnos de que el error sea una instancia de error. Si lo es, podemos proceder. Entonces, creo que tenemos lo que necesitamos. Tenemos un try-catch. Cuando comenzamos a cargar, el valor de <a href="/tags/data">data</a>, eso es la referencia reactiva, por cierto. Entonces, sí. Creo que tenemos todo. Entonces, intentemos usar esto aquí, ¿verdad? Entonces, saquemos esto. Saquemos este composable. Importar. Usar async de useAsync. Y copiaré y pegaré esta operación, porque en este punto estoy completamente sobre la marcha. No estoy seguro de cómo implementar esto, así que eliminaré todo el interior, y comenzaré. Entonces, const, estoy interesado en el resultado, para ser honesto, es igual a await useAsync y useAsync espera una función asincrónica, pero tenemos un problema. El problema, no un problema, una situación. La situación es que tenemos dos funciones, así que tenemos que ser creativos en este caso. Si queremos usar esta API específica y no complicar aún más el composable, tenemos que ser creativos. ¿Por qué? Porque esta será una operación asincrónica que devuelve async, por lo que debería ser await fetch esto. Entonces, await JSON. Y sorprendentemente, funciona. Está declarado, pero nunca se usó. Para ser honesto, no estoy tan seguro de que esto sea

funcionando. Pero probémoslo, porque ahora tenemos nuestros resultados, el perfil del usuario. Entonces, tenemos que hacer que el valor del usuario sea igual al resultado del objeto aplanado. Así que, solo un async, espera. Así que, no sé si esto está funcionando, pero lo que estoy tratando de hacer es primero extraer esto y luego esperar el valor JSON de esto, lo que está aquí. Estamos esperando esto y luego obteniendo el valor JSON. Entonces, no sé, para ser honesto, sí, es este, ¿verdad? Sí. No sé. ¿Esto está funcionando o no? No estoy seguro. No. Es solo un async. Lo siento. Y esto se queja porque es solo un async. De acuerdo. Ahora es un tipo async, al menos. No es un error sintáctico. Entonces, no está funcionando. No sé qué está pasando aquí. Así que, solo un async, espera. Estoy esperando este resultado y también esta operación de fetch. Imprimamos el valor en la consola. Es <a href="/tags/data">data</a>, lo siento. Es <a href="/tags/data">data</a>. No me gusta <a href="/tags/data">data</a>. Me gustaría que fuera resultado. ¿Es tal vez esto? No sé. Sí, lo es. Aquí está. Está funcionando, chicos. Entonces, el valor del usuario es igual al resultado del objeto aplanado, y esto no está funcionando. Entonces, un valor, resultados del objeto aplanado, valor del resultado, ¿verdad? Sí, está funcionando. Sí, está funcionando. Entonces, sí. Creo que esto es todo, ¿verdad? Lo eliminaré. No estamos tratando con errores aquí porque quiero manejar todos los errores de forma global. Verán eso. Entonces, hagamos exactamente lo mismo aquí, ¿verdad? Pero quiero cambiar. Es solo para hacer. Probaremos que esto falle en nuestras pruebas aquí. En este caso, es el valor para hacer. No es un objeto aplanado. Es el valor del resultado. Y ya no necesitamos eso. Entonces, nuevamente, esto está funcionando, ¿verdad? Hago clic aquí. De acuerdo. Entonces, tal vez te estés preguntando. Sí, al menos antes de tener un console.log, ¿qué vamos a hacer? Atención resultados. Sí. Al final, podría arreglarlo. Gracias. ¿Qué vamos a hacer? Y esta es una respuesta para otra pregunta. Alguien preguntó al principio, oye, ¿podemos exponer algo fuera de la función? Sí. En este caso, lo haré porque hay un patrón que expliqué en mi charla que es el patrón de opciones. Así que, imaginemos que tenemos una interfaz. Exportar. No exportar. Interfaz de opciones. Y verán esto en todas partes. Y esta interfaz será, por ejemplo, digamos que queremos registrar errores, será Boolean, ¿verdad? Entonces, ¿qué podemos hacer con esta opción? Podemos ir aquí y esperar que pasemos opciones. Y un objeto vacío como valor predeterminado. Y luego simplemente podemos decir, oye, const logErrors, pasamos un buen valor predeterminado de true, igual a opciones. Y en caso de que tengamos más opciones, por ejemplo, clave, propiedades, cadena, una clave, un desconocido, si quieres ser súper seguro, podemos obtener todo el resto aquí. Opciones del composable. De forma segura. ¿Verdad? Pero en este caso, lo que quiero decir es, oye, quiero registrar los errores. Quiero registrar todos los errores que ocurran en todas las operaciones asíncronas. Así que, tendremos los errores individuales de cada operación si lo deseamos, pero podemos tener una matriz global de errores. Creo que esto es, imaginemos que tenemos que registrar esto en otro lugar, ¿verdad? En cualquier, no sé, en cualquier aplicación que consuma este tipo de información. Entonces, creemos estos errores. Piensa. No es un error, será una cadena. No pasaré el error en sí, solo un mensaje. Eso es todo, ¿verdad? Entonces, si aquí, comencemos con llaves, porque tendremos más de una oración. Y podemos preguntar, logErrors y empujar el mensaje. Y, por supuesto, podemos hacer esto exportable. Entonces, no pondré estos errores dentro del composable, porque esto es opcional. Puedes trabajar con este composable con esta función opcional de errores, pero si lo deseas, probablemente necesites enchufarlo fuera de la implementación principal. Entonces, obtendrás esta matriz de errores. Y probablemente necesitarás algún tipo de clearErrors, ¿verdad? Una forma de restablecer la cosa. Entonces, también estás exportando esto. Podríamos exportar un objeto, pero para mí esto está bastante bien. Así que, probemos esta cosa de error global, porque esto está funcionando. Y como no quiero construir un modelo, permítanme hacer un poco de trampa aquí y ir a lo que han resuelto. Esto es un escenario dos. Esto es el final. Esto es un alt. Y fuimos a usuario <a href="/tags/data">data</a> e hicimos esto, ¿verdad? Así que, déjame copiar

todo. O al menos esto. Entonces, si voy aquí, está justo debajo de aquí. Estamos construyendo un modelo. Solo eso. Entonces, sí. Podemos obtener esto aquí y te mostraré específicamente lo que estoy haciendo. Entonces, obtenemos el estado del usuario, limpiamos los errores y los errores. Lo siento. Lo siento. Sincronización del usuario. Lo siento, chicos. Tenemos errores y errores de la sincronización del usuario. Y en este caso, son errores. También necesitamos vigilar. Explicaré rápidamente qué estoy haciendo aquí. Unref. De acuerdo. Cada vez que tenemos un error, ya que tenemos un lugar, lo siento, sincronización del usuario. Cada vez que tenemos un error y queremos registrar el error, quiero mostrarlo en un modelo. Entonces, y si cierro el modelo, borraré los errores. ¿Verdad? Entonces, ¿cómo sé si debo mostrar el modelo o no? Simplemente vigilo los errores porque los errores son una referencia reactiva. Se puede vigilar. Entonces, cada vez que aparece un nuevo error, muestro el modelo. Y como es un array, tengo que mostrar eso. Y tengo que mostrar el modelo, ¿verdad? Así que voy a mostrar el modelo. Y voy a el modelo. Y como es un array, tengo que vigilar esto en profundidad. Así que creo que esto debería funcionar. Y esto es, por cierto, construyendo un modelo de diálogo. Así que, ningún error en absoluto. Pero hagamos algunas cosas locas aquí. Usemos para ir a <a href="/tags/react-hooks">use state</a>. Y, por ejemplo, cambiemos esto. Cambiar JSON por JSON. Ahora, y por cierto, también debería verificar si el usuario es, entonces, continuar y también hacerlo aquí, porque si no hay valor para esos. De acuerdo. Otra vez. Esto está sucediendo, ¿verdad, chicos? ¿Por qué está fallando ahora? Si es un valor de resultado, lo siento, no quiero continuar. ¿Verdad? Bueno, aquí está. Cierra la cosa. Y si vamos a la otra implementación de sincronización del usuario, y no sé, hagamos algunas tonterías aquí. Verás que tenemos error al obtener y JSON no es una función. Así que puedes cerrar de forma segura. Cuando cerramos, restablecemos los errores. Y al menos vemos algo en la pantalla. Esto no funcionará. Nuevamente, esta es una implementación muy sencilla, muy mala, pero creo que esto es suficiente para que veas cómo funciona esto. ¿Alguna pregunta? Probemos esto muy rápidamente y pasaré a la última implementación. Y no sé si deberíamos probar esto, chicos, para ser honesto, porque esto no es un <a href="/tags/testing">testing</a> <a href="/tags/workshop">workshop</a>. Y si lo quieres, aquí lo tienes. Así que, copiaré y pegaré y trabajaré contigo. Vamos a crear este use a sync spec.ts. Peguémoslo rápidamente. Tal vez deberíamos cambiar, reset errors es clear, pero es lo mismo. Creo que esto funcionará de inmediato, y no lo hace. De acuerdo. De hecho. No puedo resistirme a intentar hacer que esto funcione, chicos. Le dedicaré 50 segundos a la instancia de error. Falla. Y falla al igualar profundamente. A igualar. Valor de errores. Esto no es. No, está bien. Falla, ¿verdad? Porque error cuando una función falla. Y estamos grabando, ¿verdad? Falso. Entonces, lo que está sucediendo aquí es que estos errores. Valor de errores para igualar. No estamos simulando toda la implementación detrás de esto, ¿verdad? Así que deberíamos borrar eso. Así que, solo para hacer que funcione. Después de cada valor de errores igual a. Creo que de esta manera, esto funcionará. Ah, estábamos llamando a clear errors. Entonces entiendo. Sí. Sí. Está fallando independientemente, también. Valor de errores para igualar. Pero sí. Esto está bien. Porque si borramos los errores, esto funcionará. Así que creo que esta prueba no está escrita correctamente. Creo que esto es lo que esperamos. ¿Verdad? Esto es correcto. Porque no estamos borrando los errores aquí. Entonces, incluso si tienes la rama original para probar e intentar hacer tu cosa, esto es lo que haré con el Composa. Pero, error y resultado. Haciendo algo con una promesa

rechazar. Haciendo algunas cosas locas para asegurarnos de que estamos lidiando con todas las situaciones. De acuerdo. Terminemos este segundo escenario. No tenemos mucho tiempo. Pondré fin. Y pasemos al último. ¿Cuál es el último? Estamos utilizando una API DOM. Cubrimos la mezcla con la API de opciones. Cubrimos el patrón de almacenamiento de datos con perforación de sonda y incluso fraude en el segundo escenario. ¿Qué sucede si queremos trabajar con una API DOM canónica? Sí. Vamos aquí. ¿Verdad? Antes. Tenemos una publicación de blog y un pie de página. Cada uno de esos componentes contiene un banner. Quiero recibir una notificación cada vez que este banner sea visible. ¿Cómo? Estamos utilizando la API Intersection Observer. Una API muy buena. Intersection Observer API. Te sugiero que la uses. Te sugiero que lo intentes. Es casi unánime el soporte que tiene actualmente. Y es muy fácil. Puedes hacer muchas cosas locas aquí. En las implementaciones más básicas, puedes decir, `oye, observa este elemento y cuando se intersecte con el viewport o con cualquier otro elemento, solo dime algo. Porque quiero lanzar una devolución de llamada. Quiero hacer algo. Notifícame`. Ya no tenemos que espiar el desplazamiento. Ya no tenemos que hacer esas cosas que hacíamos antes para lograr este tipo de lógica. Estamos utilizando esta API Intersection Observer aquí y también aquí porque quiero un contador. ¿Verdad? Veamos cómo se ve esto en realidad. Cambiemos también para dejar el escenario tres. Así que, vamos aquí. Aquí está. Puedes ver el registro de la aplicación aquí. Como puedes ver, esto es una aplicación y tenemos esta traza. Nuevamente, la aplicación del pie de página. Nuevamente y nuevamente. Cada vez que se intersecta, y deberías revisar la API porque puedes ver cuánto se intersecta. ¿Verdad? Y controlar muchas cosas aquí. Pero esta es la más básica. Así que, permíteme mostrarte el <a href="/tags/code">code</a>. Tenemos la aplicación. Ya no tenemos el ID de usuario. Lo que tenemos es, permíteme mostrarte el pie de página y la publicación de blog. La publicación de blog está utilizando esta API, esta Intersection Observer, y está observando este elemento que tiene una referencia aquí, una referencia DOM. Y cuando se monta, porque esto es un DOM, escribe, `oye, observa esto`. Y eso es exactamente lo que estamos haciendo aquí. Cuando esto se intersecta, se intersecta con el viewport, emitimos un evento con el nombre de esta propiedad y la fecha. Y hacemos exactamente lo mismo en la publicación de blog. Entonces, en la aplicación, estamos escuchando esos eventos, lanzando este controlador y mostrando el resultado aquí. ¿Se entiende esto? Quiero decir, ¿está claro? ¿Chicos? Porque creo que en media hora, llegaremos a esto. De acuerdo. Asumiré que sí. Tal vez tres horas fueron demasiado. No sé. De acuerdo. Como siempre, creemos aquí. useIntersectionObserver.ts. ¿Y qué queremos construir aquí? Nuevamente, ¿cuáles son los estados reactivos? Sí, ¿cuántas veces se ha visto esta cosa, verdad? Y también, la referencia reactiva del propio elemento, el objetivo. Entonces, esto no es exactamente, exactamente, exactamente lo mismo a lo que estamos acostumbrados. Pero intentemos construirlo. Así que, exporta la función, use Intersection Observer. ¿Y qué necesitamos aquí? ¿Verdad? Bueno, necesitamos un objetivo. ¿Verdad? Necesitamos un objetivo. Pero necesitamos una referencia reactiva de un objetivo. Así que, empecemos. Vamos aquí y pon objetivo. Este objetivo será una referencia de un elemento <a href="/tags/html">HTML</a>. ¿Por qué? Tengo que poner ref, por cierto. Importa el tipo ref. Porque mira esto. Al principio, la referencia reactiva es nula. Pero cuando el DOM se monta, se hidrata con el enlace correcto al nodo del DOM. Así que, al principio, es nulo. Pero en algún momento, debería ser un elemento <a href="/tags/html">HTML</a>. Y lo dejaré así. Tendremos opciones al final. Pero vayamos a la implementación más básica. Entonces, lo que quiero compartir aquí es si está intersectando o no. Quiero recibir una notificación. Así que, permíteme... así, esto espera un objetivo. ¿Y qué devuelve? Si es visible, este objetivo. Y también, los métodos observe y disconnect. Porque puedes desconectar la Intersection Observer. También puedes dejar de observar. Pero vayamos a la implementación más básica. De acuerdo.

Si es visible, lo colocaré como una cosa sin estado dentro de la implementación. No quiero compartir la visibilidad de todas las implementaciones. Cada vez que uso esta composable de intersección del servidor, tengo un uso privado esVisible, tengo un observar y desconectar privados. ¿Por qué? Porque pasaré un objetivo privado. Es un objetivo diferente cada vez. Entonces, ¿por qué tiene que ser compartido? Esto está claro. Entonces, creemos esta constante esVisible que es una referencia de falso. Y saquemos la referencia. Saquemos la referencia. Y también... bien. Y como puedes ver, aquí tenemos dos opciones. Espero que no estés tan muerto de cerebro como yo. Permíteme tratar de explicarlo. Esto es importante. Cuando hablas de una composable, asumes que la estás usando desde dentro del componente. Pero no tienes que hacerlo. No tienes que hacerlo. Puedes usar una composable cuando quieras. Pero si quieres necesitar... si quieres usar estos hooks del ciclo de vida, montado, desmontado, antes de montar, etc., debes consumir la composable desde un entorno de configuración, desde un componente. Entonces, en este caso, como vamos a usar este desmontado porque queremos hacerlo automáticamente, queremos comenzar a observar automáticamente. Solo quiero que pases una referencia a un elemento <a href="/tags/html">HTML</a>. Y cuando la referencia se hidrate, sí, comienza a observar y haz tu cosa. Entonces, siempre necesitaremos usar el observador de intersección desde componentes. Y en este caso, tiene mucho sentido porque estamos usando una API Reactiva,

Atom API que espera elementos. Es un componente, no el origen de esto. Pero solo para dejarlo muy claro. Así que, déjame copiar esto. Y no necesitamos remitir. Pero lo que necesitamos es que visible sea verdadero. Y si no, visible es falso. Así que, déjame sacar desmontado. De hecho, si intentas usar esta composable tal como está ahora mismo, usando montado y desmontado fuera de un componente, obtendrás algunas advertencias de uso, oye, tienes que usar esto en un entorno de configuración. Así que, desmontado, desmontado. Así que, creemos la función observar, el valor del objetivo. Pero el objetivo es, sí, el valor del objetivo, ¿verdad? Sí. Porque el objetivo es una referencia Reactiva, así que su valor. Así que, tenemos el valor, observamos. De acuerdo. Y la función desconectar. Observador, desconectar. Así que, vamos a devolver todo como siempre hacemos. Necesitamos el es visible. Vamos a devolver primero, sí, es visible, las transformaciones. Vamos a devolver el observar, y vamos a devolver desconectar. Y esto es importante. Esto es suficiente bien, ¿verdad? Pero deberíamos observar y desconectar manualmente. Y estamos proporcionando esto en caso de que queramos usar esta funcionalidad fuera de los ciclos de vida. Pero ya que tenemos acceso a montado y desmontado, ¿por qué no usarlo? Desmontado... Lo siento, esto es... Observar y desmontado. Desconectar. Y no estamos exponiendo esto. Solo estamos exponiendo eso. Este observar y desconectar es visible. Así que, cuando esto suceda... Porque lo que sucederá es, este montado y desmontado se vinculará al componente en el que se ejecute la composable. Así que, en este caso, si lo usas en una publicación de blog, esto se ejecutará cuando esta publicación de blog se monte, y esto se ejecutará cuando la publicación de blog se desmonte. Así que se vinculará al entorno en el que se ejecute. Espero que esto esté claro porque es muy importante. Así que, lo creas o no, creo que esto es suficiente. Pero lo que le falta es la funcionalidad de registro, ¿verdad? Así que intentemos hacer esto. Así que creemos una interfaz... No. Sí. Registro de intersección que tendrá su nombre, es una cadena, y cuándo es una cadena, ¿verdad? Y necesitamos un elemento, ¿verdad? Registro de intersección. Registro de intersección es igual a una referencia de registro de intersección. Y está vacío. Así que, cada vez... Y también, necesitamos algunas opciones, ¿verdad? Así que, const opciones de intersección... O opciones. Siempre llamamos opciones a todo. Así que, lo siento, lo pondré aquí. Lo pondremos aquí. Esto extiende la inicialización de intersección, ¿y qué es eso? Si echas un vistazo a la API, estas son algunas propiedades que puedes cambiar. Así que, queremos ocuparnos de este tipo de opciones que vienen con la propia API, pero también queremos algunas cosas opcionales. Como, por ejemplo, el nombre que no es opcional, ¿verdad? Porque queremos usarlo, y el cuándo se creará dentro del registro, ¿verdad? Podemos decir si registrar la cosa o no. Así que esto será opcional, y será un booleano, porque tal vez no queramos registrar el observador de intersección. De hecho, en realidad, siempre lo pondré en falso, porque tal vez no nos interese eso, pero podemos registrar la cosa. Así que ahora, lo que haré es usar este patrón aquí, el patrón de opciones por segunda vez. Súper poderoso. Así que, las opciones son opciones. No necesitamos el defecto aquí. Y aquí, podemos decir const nombre de registro, no sé por qué. No sé si me puedes oír. Pero de repente, no sé qué pasa. De acuerdo. ¿Me puedes oír de nuevo? ¿Puedes ver mi pantalla? Porque no sé qué pasa. De acuerdo. Lo siento, chicos. No sé de qué estaba hablando. Sí. El registro de intersección. Sí. Nombre de registro esto. Podemos poner un buen valor por defecto aquí. Y obtener todo, ¿verdad? Así que, si estamos registrando, si registro, podemos hacer esto. Podemos hidratar ese registro con el nombre y cuándo está sucediendo. Y, por supuesto, debemos exportar esto. Así que, exportar const registro de intersección, etc. Así que ahora, creo que estamos listos para probar esto también. ¿De acuerdo? Buena suerte más tarde <a href="/tags/testing">testing</a> esto, porque esta vez, creo que necesitaremos crear ese componente ficticio. Así que, necesitaremos probar la vista. Así que, sí. Comencemos con la implementación, ¿verdad? Para el pie de página. Así que, lo que necesito aquí, espero que esto no se rompa. Y por favor, déjame ir aquí y poner este bonito fondo <a href="/tags/creativity">music</a>. De acuerdo. Así que, desmontado, ref. Para ser honesto, no creo que necesitemos nada aquí además de la referencia. Así que, saquemos esta composable, esta importación. Usar la composable de intersección del observador en las composables. Y la estamos definiendo aquí. Así que, usar la composable de intersección del observador en los anuncios del pie de página.

 Y esto debería venir en un sujeto de opción. Entonces, su nombre es anuncio de pie de página. Podemos cambiar la API. Quiero decir, chicos, pueden hacer lo que quieran con esto. Pero créanlo o no, creo que no necesitamos nada de esto. Ni siquiera necesitamos la cosa desmontada. Así que, bien. Usar la composable de intersección del observador. Y sí. Y hagamos lo mismo para la publicación del blog. Entonces, obtendremos esto aquí. Y no son anuncios de pie de página. Es publicación del blog. Así que, lo estamos haciendo. Esta es nuestra referencia reactiva, ¿recuerdan? Y sí. Y aquí necesitamos este registro de intersección, ¿verdad? Así que, nuevamente, saquemos esto. No necesitamos el bloque completo. No necesitamos el bloque completo. No necesitamos el bloque completo de la composable. Solo necesitamos el registro de intersección. No nos importa observar nada aquí. Nos importa lo que se está observando. Así que lo ponemos aquí. Ya no estás manejando ningún evento, por cierto. Y no necesitamos esto. No necesitamos eso.

Entonces, para ‑‑ tampoco necesitamos esto. Podemos crear un alias, como at log, para acceder al ‑‑ no es ‑‑ está bien, casi ‑‑ olvidé cómo hacerlo aquí. Puedes hacerlo. No es importante. Será como ‑‑ No ‑‑ no importa.Registro de intersección. Esto es suficiente para mí. Y esto debería funcionar ahora mismo. Y lo hace. ¿Verdad? Pero fíjate en las consideraciones, ¿verdad? Porque ahora no tenemos que hacer esta cadena de comandos aquí. Esto podría o no ser un hijo directo de la aplicación. En este caso, es la aplicación. Así que sí. Tiene que ser un hijo directo. Pero imaginemos que tenemos otra cadena de componentes. Podemos escuchar esto desde cualquier lugar. ¿Verdad? Y no estamos llamando a la misma API dos veces desde el ‑‑ el mismo <a href="/tags/code">code</a>, quiero decir, la misma implementación. Tenemos una puerta de acceso a la API del DOM. En este caso, use la composable de intersección del servidor. Y esta es la composable. Y está funcionando perfectamente como puedes ver. ¿Alguna duda aquí? Porque ahora debemos probar esta cosa fea. ¿Alguna duda? No. De acuerdo. Así que, movamos esto a la derecha ‑‑ a la izquierda. Y vayamos a la derecha. Y creemos una composable. useIntersectionOfServer.spec.ts. Y saquemos las cosas típicas, de nuevo. Importar. Ser, comer, esperar, describir. Y necesitaremos callbacks después. Pero lo haremos según sea necesario. E importar montar. Desde las pruebas de vista. Porque necesitaremos un componente. ¿Verdad? En este punto, estoy asustado. Así que, no sé. Han pasado casi ‑‑ más de tres ‑‑ casi tres horas. No necesitamos estos componentes. Necesitaremos ‑‑ ¿qué necesitaremos? Necesitaremos, por supuesto, la composable. Así que, importar. Registro de intersección del servidor. Registro de intersección. Y useIntersectionOfServer. La propia composable. Y lo que intentaré hacer es simular. Esta vez tenemos que simular la implementación de la API del navegador. De la API del navegador. ¿Verdad? Porque esto usa la composable de intersección del servidor. Y estamos usando dos de los métodos de la API. Observar y desconectar. Así que, creemos un espía, una simulación ‑‑ lo siento. Es una simulación. No. Es un espía. No. Es una simulación. Así que, será observar. Simulación igual a BFN. Y lo mismo para la simulación de desconectar. Y ahora, podemos decir que la simulación de la composable de intersección del servidor. La simulación será BFN. Y aquí, estamos devolviendo observar y desconectar. ¿Verdad? Y también, esto es importante, ya que estamos reemplazando ‑‑ no estamos espiando, reemplazando la implementación, es una buena idea tener una copia. Así que, const original intersectionOfServer. Y necesitaremos el beforeAll y el afterAll. Y antes de todo, lo que queremos hacer. Es bastante obvio, ¿verdad? Queremos, sí. Ventana intersectionOfServer como cualquier cosa ‑‑ ya no me importa. Después de todo, queremos reemplazar. De nuevo. Así que, tenemos esto simulado, ¿verdad? Teníamos beforeAll y afterAll. Necesitamos un componente. Tenemos un componente. Y sí. Un componente. Porque no quiero traer este componente donde lo estoy usando. Así que, const componente igual a esto es un objeto, ¿verdad? Donde tenemos plantillas. Y sí. Bref null. No creo que necesitemos esto más. ¿Verdad? Necesitamos un objetivo. Ah. Necesitamos un objetivo. Por supuesto. Así que, const elementos objetivo. Tenemos que ‑‑ esto es un ref, ¿verdad? Ref. Necesitamos un ref. Así que, importar ref de vista.

De acuerdo. Entonces, elementos objetivo. Entonces, no creo que necesitemos esto. Es visible. Observar y desconectar. Elementos objetivo. Y el resto es el nombre de la prueba. ¿De acuerdo? Entonces, estamos obteniendo la cosa de que es visible aquí. Entonces, creo que podemos ‑‑ tenemos ‑‑ no sé, para ser honesto, chicos. No sé si tenemos algo que necesitemos. Pero intentemos comprobar si esto comienza y se detiene la observación. ¿De acuerdo? Entonces, describir. Comienza y se detiene la observación. Entonces, no, no es una cosa, ¿verdad? No sé. Estoy agotado mentalmente. En este punto. De acuerdo. Permítanme comprobar esto. Componentes de montaje adecuados. Entonces, no necesitamos esperar esto. ¿De acuerdo? Entonces, estamos montando los componentes. Entonces, el espía del observador debe ser llamado una vez y el espía de desconexión debe ser llamado cero veces. Y cuando montamos, recuerda, cuando montamos, desconectamos. Cuando montamos, observamos. Entonces, cuando estamos montando estos componentes, esta cosa, esta observación debe ser llamada una vez. Y la desconexión, cero veces. Lo dejaré como está por ahora. Entonces, esto debería funcionar. Entonces, esto debería funcionar. Y funciona. Así que, al menos tenemos algo. Entonces, ¿qué más podemos probar? Esto ‑‑ tengo un fragmento de código aquí para una parte porque esto es superobtuso, así que lo copiaré. Porque lo único que dejaré como una prueba unitaria es si realmente lanza el callback del servidor de intersección y las actualizaciones del registro. Porque cualquier otra cosa aquí para mí es probar la implementación en sí a través de una de las API del servidor de intersección o las API reactivas de <a href="/tags/vue-3">Vue</a>. Lo que quería pasar aquí es este observador es un espía, y en este caso, es un observador simulado. Estamos simulando la implementación una vez. Tenemos llamadas simuladas cada vez que, ya que hemos simulado este servidor de intersección que ahora ha sido colocado nuevamente en la ventana, podemos saber cuántas veces se ha llamado. ¿Verdad? Entonces, podemos recuperar esa llamada y hacer la llamada al callback en sí con esta intersección exactamente como lo estamos haciendo en la API canónica. Así que, creo que esto funcionará, pero quién sabe. ¿Verdad? Lo que deberíamos hacer aquí es envolver el componente, y, sí. Es una cosa visible. Necesitamos realmente obtener esto es visible. Sí. El envoltorio es visible. ¿Por qué? Porque, de nuevo, estamos devolviendo y exponiendo esto es visible que a su vez también proviene del composable. No solo eso, sino observar y desconectar. Pero no estamos usando esta prueba para ser honesto. Solo si es visible. Entonces, VM, porque esta es la instancia de vista principal en este componente, es visible como verdadero. ¿Verdad? Y lo estamos falsificando. No estamos usando ningún asimilado tan pronto como esto se lanza. Estamos diciendo, eh, esto está intersectando. ¿Verdad? Entonces, esperemos que esto funcione. Y funciona. Entonces, ¿cómo podemos probar el registro? ¿Verdad? Porque ahora la longitud del registro de intersección que está aquí debe ser uno. No entraremos en detalles, pero podemos decir que esto funciona. ¿Verdad? Y antes de montar el componente, la longitud debería ser cero. ¿Verdad? Es una matriz vacía. Y lo es. Y lo es. Entonces, podemos seguir desde aquí y probar más cosas. Pero para mí, lo mínimo indispensable es que, sí, comienza y se detiene la observación de todo. Y también, se intersecta cuando esta cosa se intersecta, todo se notifica. Lanzamos el callback. Actualizamos el registro. Hacemos todo lo que necesitamos hacer. ¿Alguna pregunta sobre esto? Escribiré los comentarios. Y nuevamente, no empujaré estos comentarios. Porque ya tienes todas estas soluciones. Y no entraré en esto. Porque no sé. ¿Alguien aquí conoce la biblioteca <a href="/tags/vue-3">Vue</a> Use? No sé si conoces esta biblioteca. Quería implementar esto API del servidor de intersección de uso desde la biblioteca. Sí. Si quieres usar este patrón en tu propio trabajo, sugiero lo que tenemos aquí abajo. Construye tu propia biblioteca de composables. Pero y esto es importante. Hay <a href="/tags/vue-3">Vue</a> Use. <a href="/tags/vue-3">Vue</a> Use es una increíble, increíble, increíble colección de composables. Listos para usar. Funciona con <a href="/tags/vue-3">Vue</a> 2 y con <a href="/tags/vue-3">Vue 3</a>. Y mira y admira, si comienzas a buscar los composables, están aquí. Y usamos el servidor de intersección propio. Tenemos nuestra propia implementación. Entonces, por menos de un kilobyte, tamaño de exportación, quiero decir, puedes importar esto en tus propios proyectos, ya sea una directiva o la API directa expuesta, diría yo. La API en sí es completamente diferente a la mía. Pero eso es increíble, ¿verdad? Porque hay diferentes formas de hacerlo. Así que sugiero probar esto. Es increíble. Tenemos un estado, estado de sincronización de usuario, elementos, navegador, sensores, red, animación, componente, observar, reactividad, matriz, tiempo, utilidades, y así sucesivamente, ¿verdad? Es una increíble, en serio, hazte un favor y compruébalo

porque es una herramienta increíble para tu cinturón de herramientas. Así que, muy fácil de hacer. Tienes que por supuesto, instalar el núcleo de <a href="/tags/vue-3">Vue</a> Use. Y esto es 3-shakeable, por supuesto, solo los composables que implementes estarán en el paquete final. Así que está súper bien optimizado. Y la cosa es que puedes jugar, no sé si te diste cuenta, pero puedes jugar un poco con cada composable dentro de la documentación, ¿verdad? Puedes ser la fuente, la demo que está aquí. Y los detalles internos de cada uno de esos composables. Así que lo dejaré aquí porque creo que hemos cubierto muchas cosas. No sé si tienes alguna duda, alguna duda final antes de cerrar esto, chicos. Tendrás la grabación. De nuevo, tienes el el repositorio con todas las cosas que necesitas para comenzar. Así que tienes que ir a la rama principal, escenario 1, escenario 2, escenario 3. Tiene todas las respuestas. Así que lo dejaré aquí. Realmente, realmente, realmente espero que hayas aprendido algo útil para tu trabajo diario. Y sí, gracias a ustedes, chicos. Y nos vemos en la comunidad de <a href="/tags/vue-3">Vue</a>. Si tienes algo que preguntar o decir, puedes ir a squela.vue.es y pongámoslo en inglés. Algunos <a href="/tags/tips">tips</a>, etc. Tal vez más temprano o más tarde, haremos otra masterclass tal vez. Pero podemos mantenernos en contacto. De acuerdo, chicos. Gracias por su atención, por estar aquí. Y tengan un excelente resto del día, chicos. Adiós.

Vue.js Live Conference

Vue.js Live 2024

Learn To Use Composables: The Swiss Army Knife Of Vue Developers

Aprende a utilizar Composables: La navaja suiza de los desarrolladores de Vue

El masterclass introdujo los composables en Vue 3 como una alternativa a los mixins y la API de opciones. La transición de la API de opciones a los composables implica buscar estado reactivo, transformaciones y mutaciones. Los composables proporcionan un lugar centralizado para gestionar el estado, lo que hace que los componentes sean más reutilizables. El uso de pruebas y simulaciones permite realizar pruebas exhaustivas de los composables y su comportamiento. Por último, el masterclass exploró el uso de la API Intersection Observer y su integración con los composables de Vue 3.

Los Composables (funciones de composición) son funciones con estado/sin estado que pueden aprovechar la API de reactividad de Vue, desacoplándola de los componentes.Este cambio de perspectiva abre la posibilidad de abordar escenarios comunes de una manera nueva y creativa. En este masterclass, aprenderás cómo resolver problemas típicos que enfrenta cada desarrollador de Vue, utilizando composables: <ul><li>- Almacenamiento de datos;</li><li>- Comunicación entre componentes;</li><li>- Funciones de utilidad (DOM, API, etc);</li><li>Y más.</li></ul>

Juan Andrés Núñez Charro

JSNation US

I’m attending JSNation US. Join me there for free with 10k other JS engineers and 50+ great speakers. Just follow this badge.

JSNation US 2024

React Summit US

React Summit US 2024

React Advanced

React Advanced Conference 2024

Productivity Conference

Productivity Conference 2024

React Day Berlin

React Day Berlin 2024

Node Congress

I’m attending @NodeCongress, the biggest conf on #JavaScript backends – by clicking the badge you may get a free remote ticket & join me there with 5k other #nodejs devs & 35 great speakers #deno #cloudflare #awscloud

Node Congress 2025

JS Nation

I’m attending JSNation – the main JavaScript conference of the year. You may join me there for free with 10k other JS engineers and 40+ great speakers. Just follow this badge. 

#javascript

JSNation 2025

React Summit

I am attending the biggest #Reactjs conference remotely. You may get a limited free ticket (50% of talks, no workshops) and join me by clicking this badge.

#react #reactjs

React Summit 2025

C3 Dev Festival

Join me at C3 Dev Fest, a contemporary software engineering festival!

Register to win an all-paid trip to Amsterdam. Elevate your career with industry experts and workshops & rock 3 dance stages at the after-party!

C3 Dev Festival 2025

TechLead Conference

I'm attending TechLead Conference 2024 – get your free remote ticket and join me there

Aprende a utilizar Composables: La navaja suiza de los desarrolladores de Vue

Comments