Despliega y Prueba Aplicaciones React de Pila Completa en Cloudflare

Hola a todos. Bienvenidos a la masterclass, que trata sobre el despliegue y prueba de aplicaciones React de pila completa en Cloudflare. Antes de comenzar con el contenido aquí, voy a dar una breve introducción sobre mí mismo y dejaré que Dario se presente. Pero mi nombre es Christian Sparks. Estoy en el equipo de construcción y automatización en Cloudflare. Así que si alguna vez has usado Cloudflare pages o has usado Cloudflare workers builds, básicamente, trabajo en ese tipo de cosas. Así que básicamente, toda la integración con Git, si estás construyendo un sitio estático en Cloudflare, trabajo en ese tipo de cosas.

Y luego Dario Pietrovic. Trabajo en el equipo de frameworks en Cloudflare, donde básicamente intentamos mejorar nuestra integración de Cloudflare con los diversos frameworks de JavaScript en el ecosistema. Y sí, la masterclass trata sobre crear una aplicación React de pila completa y desplegarla en nuestra plataforma. Todo hecho junto con pruebas exhaustivas. Esta es la agenda. Está dividida aproximadamente en tres bloques de una hora. Comenzaremos con una breve introducción al proyecto, luego algunas implementaciones ligeras de UI, y luego desplegaremos nuestro proyecto en la plataforma Cloudflare. Luego tendremos un breve descanso. Después, implementaremos algo de lógica de backend que realmente integre nuestra aplicación con algunos recursos de la plataforma Cloudflare. Luego otro breve descanso. Y finalmente concluiremos combinando la lógica del lado del servidor que acabamos de implementar en el paso anterior con nuestra UI, y probaremos toda la aplicación. Y esto nos llevará al final de la masterclass.

En cuanto a los requisitos, son bastante mínimos. Pero sí, solo tu IDE favorito. Usualmente sugerimos VS Code, pero cualquier IDE debería funcionar. NPM o tu gestor de paquetes preferido. Git, como viste, tenemos este repositorio de GitHub y la masterclass gira en torno a este repositorio. Así que Git es definitivamente necesario. La cuenta de Cloudflare, ya que necesitamos integrarnos con los recursos de Cloudflare y desplegar en Cloudflare. Así que se necesita una cuenta de Cloudflare. Si no has configurado una, solo toma unos minutos y es completamente gratis. No tienes que pagar nada ni nada por el estilo. Así que debería estar bastante bien. Y finalmente algo de entusiasmo, que nunca está de más.

Y sí. Sí, claro. Así que para dar una visión general rápida de lo que estaremos haciendo durante esta masterclass, estaremos construyendo una aplicación generadora de tarjetas de intercambio construida usando Remix, que es un framework de pila completa de React, Cloudflare workers y pages. Sí, dejaré el enlace del repositorio. Pero Cloudflare workers y algunos otros recursos de Cloudflare. Y aquí hay una pequeña demostración de nuestras aplicaciones completadas. Tienes un pequeño formulario aquí, así que hagamos un ejemplo. Luego podemos hacer clic en Generar, una vez que hayamos insertado un título y una descripción. Tomará unos segundos, porque está generando una imagen. Y esperemos ver un resultado en un segundo. Y puedes ver que hemos generado una pequeña tarjeta de intercambio, una tarjeta de intercambio de buen aspecto. Y esto es lo que obtendrás de la masterclass.

Ahora, para dar una visión general de con qué tecnología estamos construyendo esto, la primera es Cloudflare workers. Así que voy a dar un poco de visión general, porque es un poco diferente de muchas de las plataformas de JavaScript que podrías haber usado antes. Típicamente, la gente hará cosas en Node o en el navegador, pero workers es un poco diferente. La clave es que es un runtime sin servidor de baja latencia, y es algo así como sin región. La idea es que puede ejecutarse en prácticamente cualquier ubicación en el mundo, y puedes elegir su ubicación y hacer que se ejecute cerca de un usuario, lejos de un usuario, cerca de ciertas bases de datos que podrías tener para optimizar la capacidad de respuesta para cualquier usuario de tu aplicación. También está basado en V8, así que es más o menos la misma tecnología que Chrome y Node.js, pero hay algunas diferencias de API. Bastante eficiente.

Y la forma en que lo aislamos, esto es un poco más detallado de lo que necesitas, pero usamos V8 isolates para minimizar los inicios en frío. Entonces, lo que eso significa es que, si nadie ha accedido a tu aplicación en un tiempo en otras plataformas sin servidor, podrías experimentar una solicitud bastante lenta, como inicios en frío de casi medio segundo o un segundo, en comparación con Cloudflare, intentamos minimizarlo a cero, por lo que básicamente no hay diferencia entre un inicio en frío y un inicio en caliente. También es bastante económico. Plan gratuito, $5 al mes, hay muchas solicitudes incluidas. La masterclass de hoy se puede completar completamente dentro del plan gratuito con muchas, muchas solicitudes allí, así que no necesitas preocuparte por eso. Y específicamente, la tecnología que usaremos es Cloudflare Pages, que proporciona una combinación de alojamiento de activos estáticos, así como algunas capacidades de trabajadores de backend, lo cual es ideal para nuestro caso de uso hoy, que es una aplicación web de pila completa. Le pasaré a Dario para hablar sobre React.

Genial, así que sí, el framework de React de pila completa que usaremos es Remix. Probablemente todos aquí deberían estar bastante familiarizados con eso. Pero de todos modos, solo para dar una ligera introducción, es un framework de React de pila completa con una buena UXDX y todas las campanas y silbatos que esperarías de un framework moderno. Una cosa a mencionar es que el equipo de Remix está migrándolo para convertirse en parte de React Routers v7. Pero sí, cualquier cosa que usemos hoy, debería ser bastante trivial migrarla de todos modos a React v7 cuando llegue, así que no es como si lo que presentaremos hoy, vaya a quedar obsoleto pronto. De todos modos, lo que también implementaremos se puede implementar con cualquier framework de React de pila completa o incluso cualquier framework de JavaScript de pila completa en general, por lo que es un poco basado en Remix, pero los conceptos son bastante genéricos.

Como un framework de React de pila completa en Cloudflare, hay algunas otras alternativas, por ejemplo la grande es NxJS. También hay otras más nuevas y experimentales como Quark y 10-steps. Pero sí, de todos modos, elegimos ir con Remix porque tiene muy buen soporte desde el principio para Cloudflare. Tiene una API pulida para acceder a los recursos de Cloudflare, como veremos en la masterclass. También tenemos una buena plantilla de inicio en nuestra herramienta C3 para crear un nuevo proyecto Remix y puedo mostrarte muy rápidamente a qué me refiero con eso. Si no estás familiarizado con nuestra herramienta Create, es una herramienta CLI simple que puedes ejecutar a través de C3 y crear Cloudflare o tu alternativa de gestor de paquetes. Puedes elegir dónde crear tu aplicación. Hay varias opciones, y como mencioné, tenemos una opción para Remix. Así que básicamente, si fueras a usar la herramienta C3, aquí crearíamos y crearíamos una aplicación Remix lista para que simplemente la despliegues en Cloudflare. De todos modos, solo te estaba mostrando la herramienta, pero no la vamos a usar ya que en nuestro repositorio. Ya hemos creado toda la aplicación para ti. Hablando de eso, este es el repositorio. Christian ya lo compartió. Si puedes, por favor clónalo. De todos modos, para dar una introducción de muy alto nivel del repositorio, simplemente hay una sección de bienvenida con un enlace a las diapositivas. Quiero decir, creo que lo tienes, pero está ahí si lo necesitas. Y una cosa importante a mencionar, tenemos un conjunto de GitHubs para que si quieres, puedes saltar a cualquier punto de la masterclass en cualquier momento. Así que sí, si, por ejemplo, te pierdes en algún punto, o quieres saltarte un ejercicio o verificar la solución para un ejercicio o cualquier cosa que quieras, simplemente puedes revisar las varias etiquetas, que están listadas aquí. Sí. De todos modos, también codificamos en vivo los varios ejercicios, soluciones y cosas por el estilo. Así que con suerte no deberías necesitar saltar demasiado a través de etiquetas, pero si necesitas, están ahí para ti. Podemos comenzar con el primer ejercicio. Aquí también estamos listando los varios GitHubs relacionados con este ejercicio. De todos modos, para cada ejercicio en nuestra masterclass, tenemos un archivo readme, que puedes encontrar bajo ejercicios. Y sí, este primer ejercicio, se trata de implementar el formulario de nuestra UI. Así que ahora mismo tenemos una UI simple parcialmente implementada, y la tarea de este primer ejercicio es implementar el formulario con la lógica de acción y cargador, por lo que la lógica de integración de backend para eso. Así que sí, te daremos unos minutos para familiarizarte con el repositorio y comenzar el proyecto y comenzar a trabajar en el primer paso, luego en unos minutos podemos codificar en vivo el primer paso juntos y también continuaremos con esta estructura para los otros pasos. Así que sí, si quieres comenzar con el ejercicio. Y por cierto, en cualquier momento si tienes alguna pregunta o algo, solo grita o envíanos un mensaje en el chat o lo que quieras. Así que vamos a empezar a ver la solución para el primer paso juntos. Y déjame... Ya hice un fork... ¿Cómo me deshago de esto? Bien, ya cloné el repositorio. Así que hagamos un simple npm install. Y podemos iniciar la aplicación con npm run dev. Así que obtenemos nuestro... Así que esta es la aplicación inicial.

Y el primer ejercicio fue... El primer paso es realmente actualizar esta vista al formulario. Así que si vamos al primer readme, esto te pide básicamente actualizar este archivo index.ts. Así que aquí, veamos, el primer paso nos pide primero actualizar esta variable de detalles de la tarjeta. Así que en lugar de tener esos valores de marcador de posición, realmente solo queremos tener null. Y luego también queremos hacer que TypeScript sea pesado aquí. Y luego, si no hay... Si la variable de detalles de la tarjeta es null, queremos implementar nuestro formulario. Así que usaremos el componente de formulario de Remixer. Y aquí, queremos tener dos campos. Así que una entrada, que es para el título, y un textarea, que es para la descripción. Así que sí, esto es básicamente todo para las entradas. También queremos un botón, que es para generar nuestra tarjeta. Por último, especificamos aquí que el formulario debe tener un método post. Y no debería tener ninguna acción. Por último, espero... Esto es tan claro como logré hacerlo. Pero básicamente, para que heredes nuestros estilos, deberías seguir esta estructura. De todos modos, aquí puedo mostrarte lo que significaban. Así que en el componente de formulario, realmente queremos la clase de formulario de tarjeta. Luego realmente queremos envolver nuestras entradas dentro de un div con el nombre de clase de tarjeta. Y movamos esto aquí. Luego queremos un div extra, que será un marcador de posición para la imagen de la tarjeta. Así que ahí está. Luego agreguemos las clases para el título y la descripción. Así que, card.title y card.title.input Aquí. Esto debería ser descripción. Bien. Así que, por último, nuestro botón debería tener una clase de btn y btn.generate. Así que, si ahora vamos a nuestra aplicación, podemos ver que tenemos el formulario como queríamos. Y podemos ingresar algunos datos aquí. Podemos generar y, ya sabes, las cosas se rompen. Ese es entonces el segundo paso. Así que, queremos implementar una acción para que manejemos el envío del formulario. Así que, sí. Ahora, si tú – te damos alrededor de cinco minutos o así para hacer el segundo paso. Y luego también dejamos ir la solución del segundo paso juntos. Estaremos vinculando las diferencias a lo largo. Y también puedes revisar las soluciones localmente también. Solo para que todos puedan seguir. Comenzaré el – como, poniendo el segundo paso del ejercicio. Así que, implementamos nuestro formulario. A continuación, queremos implementar la acción. Así que, para implementar la acción, vamos aquí. Y queremos exportar una función que queremos que sea asíncrona. Y esta función necesita llamarse acción. Toma algunos argumentos que son argumentos de función de acción de Remix. Y de los argumentos, podemos obtener la solicitud. Así que, de la solicitud, podemos obtener nuestros datos del formulario de los cuales podemos obtener los, ya sabes, datos de entrada dentro del formulario. Esto necesita ser esperado.

Y aquí en nuestros datos del formulario, podemos obtener el título y la descripción. Y queremos asignar algunas variables a esos. Así que, ahora, tenemos nuestro título y descripción. El ejercicio nos pide también registrarlos. Así que, un simple console log debería bastar. Y el título y la descripción.

A continuación, queremos esperar un segundo para simular un retraso del back-end. Así que, simplemente esperaremos una nueva promesa. Y en la promesa, simplemente podemos hacer un set timeout de 1 segundo. Así que, después de esperar 1 segundo, podemos simular un ID de tarjeta. Así que, solo un ID de tarjeta. Igual a un marcador de posición de ID de tarjeta. Y finalmente, devolvemos una redirección a esta URL. A este camino, debería decir. Así que, con esto en su lugar, si vamos a nuestra aplicación y la actualizamos, deberíamos poder poner un título y una descripción en nuestro formulario. Hacer clic en generar. Toma un segundo, pero luego ves que nos redirigen a esta URL. Y en nuestro terminal, obtenemos nuestro título y descripción. Así que, sí. Este fue el segundo paso. Como puedes ver, la interfaz de usuario no cambia después de enviar tu formulario. Y para eso se necesita el loader. Así que, ese es el siguiente paso en nuestro ejercicio.

Así que, sí. Te daré otros 5 minutos para trabajar en el tercer paso. Sí, vamos a codificar en vivo el tercer paso juntos, y Christian revisará el problema no definido en el chat. Así que, si volvemos a nuestro ReadMe... El primer paso nos pedía crear un loader. Así que, para el loader, nuevamente queremos implementar... implementar una función de exportación y asíncrona, que se llama loader. Los parámetros aquí son loader function args, de los cuales, nuevamente, podemos obtener nuestra solicitud. Así que, una vez que obtenemos la solicitud, queremos obtener el ID de la tarjeta, que realmente configuramos en la acción. Y para hacer eso, necesitamos crear un objeto URL. Así que, nuevo URL. Y pasamos la cadena de URL de nuestra solicitud. De la URL, podemos obtener nuestro ID de tarjeta. Así que, URL search parameters, obtener ID de tarjeta. Y lo que queremos hacer aquí es si el ID de tarjeta... Si no hay ID de tarjeta. Así que, realmente solo verifiquemos si es defectuoso. Entonces simplemente devolvemos null. De lo contrario, queremos devolver un objeto de marcador de posición. Así que, devuelve este objeto, que debería satisfacer esta interfaz de tarjeta. Satisfacer esta interfaz de tarjeta, debería tener un título. Así que, título de marcador de posición y descripción. Descripción de marcador de posición. Y finalmente, también hay una URL de imagen. Y esto debería ser todo para nuestro loader. Finalmente, realmente queremos leer estos datos desde otro componente. Y para hacer eso, usamos el hook use loader data de Remix, en el cual también queremos especificar que estamos usando los tipos del loader, para que obtengamos una buena tipificación para los detalles de nuestra tarjeta.

Y esto debería ser todo. Si ahora vamos a nuestra aplicación, sí, ya puedes ver que obtenemos nuestra UI, ya no el formulario. Pero intentemos de nuevo. Aquí puedo poner un título. Descripción, puedo generar. Nos tomará un segundo, pero luego nuestro formulario funcionará como se espera. Así que, sí, con esto completamos los primeros ejercicios. Así que, tenemos todo nuestro paquete de UI en su lugar. Y ahora queremos implementar la lógica del backend para proporcionar funcionalidad real a la aplicación. Antes de eso, también haremos algunas configuraciones para la integración en la nube y también el despliegue. Eso es lo que Christian hará a continuación. ¿Podrías intentar ayudar en el chat y luego yo tomaré el control? Claro. Entonces deja de compartir.

Así que rápidamente tomaré el control aquí. Un segundo. Lo siento, tengo que hacerlo rápidamente. Así que, obviamente ahora deberíamos tener una aplicación front-end muy básica, pero eso realmente no nos da ninguna funcionalidad. Así que, queremos añadir algo de persistencia para que nuestra aplicación pueda hacer cosas geniales como generar ilustraciones de tarjetas, así como guardar y compartir nuestras tarjetas.

Y para hacer esto, vamos a usar algunos recursos útiles de Cloudflare, específicamente los llamados bindings. Así que, los bindings son un concepto que son algo únicos de Cloudflare, pero la idea es que hacen dos cosas clave. Otorgan capacidades y permisos. Así que, por ejemplo, tu worker tiene acceso a un recurso específico. Así que, eso podría ser un bucket R2, eso podría ser un espacio de nombres de clave-valor. Explicaré qué son esos más adelante en un segundo, pero básicamente te dan acceso a tal vez algunos datos o una API. Y luego también inyectan la API de servicios en el entorno de tu worker. Así que, la idea es que, oh, sí. ¿Puedes enviar la solución al paso anterior? También inyectan tu API de servicios en el entorno de los workers. Así que, la idea es que, esencialmente, no tienes que importar ninguna biblioteca, como que obtienes la biblioteca importada e inyectada en tu worker. Y averiguaremos cómo se ve eso, cómo se ve eso en un segundo.

Pero para generar y guardar tarjetas, usaremos los siguientes bindings. Workers KV, que es básicamente un almacén de clave-valor. Así que, almacenas algunos datos en alguna clave. R2, que es básicamente equivalente a S3, si alguna vez lo has usado, así que es almacenamiento de blobs. Y lo usaremos para almacenar las imágenes de nuestras tarjetas, así como la IA del worker, que básicamente nos permite hacer algunas cosas de IA generativa con los workers. Así que, en nuestro caso, generar algunas imágenes.

Así que, podrías estar preguntando, ¿por qué Cloudflare usa bindings en lugar de lo que sería el método típico, que es configurar un token de API y luego usar ese token de API con una biblioteca por conjunto? La razón es que tienes menores riesgos de seguridad, porque nunca tienes un token de API que pueda filtrarse. Así que, no estás copiando y pegando tokens de API. Tampoco necesitas ningún boilerplate, así que no necesitas configurar tu biblioteca o configurar un cliente de API o algo así. También te da una visibilidad bastante clara sobre el uso de recursos.

Así que, ahora intentemos realmente desplegar nuestro sitio muy básico y configurar algunos bindings. Así que, esto va a ser un poco más guiado. Así que, si todos quieren seguirme mientras hago esto. Déjame sacar esto. De hecho, voy a, déjame cerrar este. Genial.

Muy bien, así que, si no lo has hecho, si has completado todos los ejercicios, actualmente estoy solo en la etiqueta EXR 01, así que solo revisa eso. Pero si has completado los ejercicios, no necesariamente necesitas hacer eso. Así que, abramos la sección O2 Bindings. Y si todos quieren mirar este ejercicio específico, técnicamente hay dos de ellos. Hay dos opciones. Está la versión pura de KV así como la pura de R2, o la versión de R2 más KV. Recomendamos la versión de R2 más KV. Así que, creo que podemos enlazar eso. Lo siento, oh, todos solo ven la diapositiva. Lo siento por eso. Oh, ups. Dame un segundo rápido. Déjame compartir toda mi pantalla.

Muy bien, estoy de vuelta. Bien, así que voy a sacar esto aquí. Así que primero, iniciemos sesión en nuestra cuenta de CloudFlare. Así que, si no has iniciado sesión en tu cuenta de CloudFlare ya, hagámoslo en el CLI de Wrangler, que es solo una forma útil para nosotros de gestionar nuestros proyectos de CloudFlare dentro de tu terminal. Así que, hagamos npx wrangler login.

Y esto básicamente me pedirá que inicie sesión. Y debería redirigirme al panel. Y solo me da un aviso de autorización. Y puedes permitir eso si no has iniciado sesión en Wrangler aún. Les dejaré hacer eso. Y una vez que hayas iniciado sesión, puedes hacer npm run deploy. Y lo que esto hará es que te pedirá, si no has creado este proyecto ya, lo cual probablemente no has hecho, te pedirá que crees un nuevo proyecto. Y luego también simplemente subirá y desplegará nuestro proyecto de páginas. Así que, voy a ejecutar esto. Idealmente, deberías obtener este aviso. Crear un nuevo proyecto. Puedes simplemente hacer clic a través del nombre de la rama de producción, simplemente déjalo como predeterminado. Luego deberíamos obtener una carga en un segundo. Y voy a abrir rápidamente el panel de CloudFlare. Sí, debería darte un resultado, este dominio pages.dev. Esto no funcionará durante los primeros dos o tres minutos. Sí, toma tiempo hasta que el proyecto comience a estar disponible. Así que eso es normal y esperado. Y mientras tanto, vamos a intentar configurar algunos bindings. Así que, puedes ver que esto aparecerá con una página en blanco. Eso es solo porque estamos configurando el dominio y esas cosas. Aparecerá en un segundo rápido. Pero mientras tanto, puedes ver que en tu panel de CloudFlare, que está en dash.cloudflare.com, puedes ver que deberías tener un nuevo proyecto aquí que tiene un despliegue y tiene algunas configuraciones. Y son básicamente los valores predeterminados. Ahora, una vez que tengamos estos bindings, vamos, o una vez que tengamos este proyecto, intentemos configurar algunos bindings. Así que, queremos hacer alguna configuración para configurar nuestros bindings de workers y pages. Así que, como dije antes, estos bindings pueden vincular permisos y una API de un worker. Y hemos incluido un binding para empezar, que está configurado en el wrangler.toml. Así que, ese wrangler.toml en la raíz del repositorio, así que justo aquí, puedes ver que tenemos el nombre de nuestro proyecto, la fecha de compatibilidad, el directorio de salida de la compilación, y luego tenemos esta cosa llamada ai binding equals ai. Lo que esto hace es que expone una variable de entorno para pages, o para que pages acceda al tipo ai, como la API ai. Y hablaremos un poco sobre cómo usar este binding más tarde, pero todo lo que necesitas saber es que hemos incluido esto para ti. Y si miras en el panel, justo aquí bajo la sección de binding, tenemos ai configurado como un binding. Así que, ahora vamos a crear algunos bindings de almacenamiento, así que para kv y r2. Así que, primero vamos a crear un espacio de nombres kv. Así que, esto será npx wrangler kv namespace create trading cards. Así que, voy a pegar este comando. Y... Oh. Espacio de nombres, oh, ups. Necesito tener, ya he creado este espacio de nombres. Trading cards, corto. El nombre realmente no importa tanto, porque puedes simplemente pegar en la configuración. Así que, podemos ver este ID aquí, y lo que queremos es usar este ID en nuestro archivo de configuración. Así que, en nuestro wrangler.toml. Así que, si miras en el wrangler.toml, hay esta cosa de espacios de nombres kv aquí. Y vamos a... De hecho, nos da un pequeño fragmento útil aquí. Queremos que este binding se llame kv, sin embargo, lo importante. Pero el ID va a ser específico para ti. Y esto está limitado a tu cuenta.

Ahora, en segundo lugar, o dejaré que la gente pase por esto y vea si tienen algún error. Y luego, una vez que hayas creado ese namespace kv, hagamos lo mismo para un bucket R2. Así que, eso es básicamente el equivalente a un bucket S3. Así que, vamos a hacer npx wrangler R2 bucket create, card images. Creo que este podría no ser un bucket único. Sí, necesito cambiar el nombre de mi bucket porque lo he creado demasiadas veces. Y este, podrías obtener un error de autenticación. La razón es que necesitas tener una tarjeta de crédito vinculada a tu cuenta. En el caso de usar R2, será totalmente gratuito. Pero si no quieres agregar una tarjeta de crédito a tu cuenta, hay una versión alternativa, puramente kv de esto. Pero no debería costar dinero. De todos modos, a lo largo de esta masterclass, es solo una cuestión de limitar el abuso. Y luego, podemos pegar aquí, el nombre del bucket que acabamos de crear. Y guardemos este wrangler toml. Y ahora, tenemos estos tres bindings que hemos creado. ¿Y cómo los usamos realmente en nuestro código? Bueno, para usarlos en nuestro código, primero haremos npm run build, y también podemos hacer npm run cftypegen. Y lo que eso hace es que genera la interfaz de tipo para nuestro worker. Porque si recuerdas, los bindings son tanto configuraciones como también APIs al mismo tiempo. Así que, el archivo de configuración define los tipos para la API que usaremos en el próximo ejercicio. Y esta interfaz se genera en worker configuration d.ts. Ahora que hemos configurado todo esto, y esperaré a que todos sigan un poco, pero ahora que hemos configurado esta configuración, podemos desplegar nuestro sitio nuevamente. Así que, simplemente podemos hacer npm run deploy, y esto va a crear un nuevo despliegue de nuestro sitio. Va a usar el mismo proyecto exacto que acabamos de crear. Y, ah sí, ese error, sí. Así que, si te encuentras con el error de R2, es porque ese error es solo porque con R2 lo limitamos a tener una tarjeta de crédito vinculada a tu cuenta. Puedes, esencialmente, si vas al panel y vas al almacenamiento de objetos R2, debería darte un aviso para insertar información de la tarjeta de crédito. Si no quieres hacer eso, puedes seguir con la versión puramente KB de esto, pero de cualquier manera, es principalmente solo como una cosa de mitigación de abuso para que no crees como un montón de buckets R2 gratis, pero todo está dentro del nivel gratuito. ¿Tiene sentido si te encuentras con ese error de bucket R2? También puedes seguir esta versión de bindings KB. Así que, sí, como en la diferencia entre las versiones KB y R2, así que, básicamente, KB es un almacén de clave-valor y en la versión regular de esto, básicamente vamos a almacenar metadatos de tarjetas y el bucket en R2 es que vamos a almacenar los datos de imagen en R2. Y típicamente KB es idealmente para metadatos y cosas así. Y luego R2 es útil para blobs. Así que, por ejemplo, imágenes. Ahora no hay nada que te impida almacenar datos de imagen en Workers KB, pero queremos demostrar algunos ejemplos más o algunas más oportunidades para probar bindings. Pero, ¿eso da una explicación más o menos clara? Pero si miras aquí, puedes ver que hemos creado este nuevo bucket R2 y luego también hemos creado un namespace KB, que es uno de estos. Y además de eso, si miramos la aplicación que acabamos de desplegar, hay un nuevo despliegue y en la sección de configuraciones, en realidad tenemos nuestros bindings configurados aquí. Así que están asociados con nuestro entorno.

Así que eso es básicamente el final del ejercicio dos. No hay una cantidad significativa de código para escribir, todo lo que estás escribiendo es específico para tu, va a ser específico para tu configuración solo porque es puramente configuración. Y les dejaré tener un pequeño descanso de unos cinco minutos y luego continuaremos con el ejercicio tres. Y seguiré por aquí si tienen alguna pregunta y puedo ayudar. Así que ahora que hemos tenido un pequeño descanso, voy a comenzar con el ejercicio tres. Déjame pegar, es ejercicio por lo que vale. Si no pudiste configurar, como configurar completamente como el despliegue y las cosas de binding, no te preocupes, todo, aún puedes continuar con esto. Todo es posible en desarrollo local de todos modos. Y esto es solo un poco de configuración para introducirte a lo que son los bindings, pero vamos a volver a algunas cosas más de codificación por el momento.

Y déjame, acabo de dejar caer el enlace del ejercicio. {{^}}Y déjame, déjame compartir toda mi pantalla porque esto va a ser corto. Así que ahora pasamos al ejercicio tres, que es una especie de card manager, implementación de clase. Ahora voy a, déjame sacar esto rápidamente. Así que básicamente, lo que tenemos ahora es que tenemos nuestra, tenemos nuestra aplicación regular, pero queremos implementar alguna funcionalidad. Y tenemos una especie de interfaz esbozada para que todos implementen para crear alguna funcionalidad. Así que en este caso, comencemos ejecutando algunas pruebas. Así que vamos a verificar que podemos probar cosas. Así que puedes ver que tenemos, tenemos dos series de pruebas aquí. Si miramos, solo necesitas implementar uno de estos archivos. Pero si miras aquí, básicamente tenemos esta clase card manager. Y la idea es que el objetivo de todo este ejercicio durante la próxima hora más o menos es básicamente implementar estas funciones.

Así que la clase card manager, y esto expone algunos métodos que usaremos en nuestra aplicación Remix real en un segundo, o más tarde, para gestionar la funcionalidad. Así que esta clase card manager exporta un par de métodos en exports generate card image, generate and save card, getCard y getCardImage. Y estos son generalmente bastante autoexplicativos. Y tenemos dos implementaciones de estas clases, la versión kv, o la versión r2. Solo necesitas implementar una de estas. Y luego tenemos dos archivos de prueba para cada uno de ellos. Y solo necesitas querer implementar uno de estos archivos de prueba. Es lo que pretendemos. Ahora, si vamos al ejercicio, podemos ver que tenemos todo preparado para ti. Y el primer paso es implementar y probar el generate card image.

Así que básicamente la idea de esto es que queremos implementar esta función aquí, la función generate card image. Y luego queremos probarla usando esto, llenando la información aquí en esta prueba. Y para darte una introducción súper rápida, puedes acceder a tus bindings con this.env.something. En este caso, tenemos env.ai, tenemos env.kb, y env.r2. Y esos están asociados con cada uno de los bindings. Para la sección generate card image, solo necesitas el binding AI y ai.run. Y proporcionamos un enlace a alguna documentación para mostrarte cómo generar una imagen con Workers AI, y algo de información sobre cómo probar esto. En este caso, usamos VITEST Pool Workers, que es la integración de pruebas VITEST con Cloudflare Workers. Básicamente, ejecuta una serie de pruebas en el runtime de Workers. Y es bastante sencillo y se integra bien con VITEST. VITEST no es súper complicado. Las cosas importantes que necesitas saber es que expone algunas funciones EXPECT. Así que puedes como EXPECT funcionalidad así como funcionalidad MOC. Y entramos en eso un poco. Pero sí, daré a todos alrededor de cinco a 10 minutos para intentar implementar esto. Y luego procederemos a codificar en vivo la función generate card image. Y háganme saber si alguien tiene alguna pregunta porque sé que estamos cambiando un poco de marcha hacia un código más enfocado en el backend, como código relacionado con Workers. Y también una nota importante es que si alguna vez ves resultados de prueba extraños, como falló al pop el marco de pila de almacenamiento aislado, te dice esto en los resultados de la prueba, pero esto es generalmente porque fallaste en esperar una función asíncrona. Me encuentro con esto todo el tiempo y siempre lo olvido. Pero ese es probablemente el error más común con el que te encontrarás. Y como recordatorio, siempre puedes simplemente revisar EXR 01 start porque ahí es donde estamos manteniendo esta parte del ejercicio porque podemos intentar implementar algo de nuestro card manager, algunas de nuestras clases card manager. Solo voy a intentar comenzar con este método generate card image. Así que recordamos antes, básicamente lo que queremos hacer es, la forma en que hacemos esto es que queremos esencialmente implementar la funcionalidad para generate card image, que es bastante sencillo. Lo que queremos hacer es simplemente mostrar los resultados de this.ai.run. Así que si miramos el Workers.ai, o déjame compartir toda mi pantalla. Si miramos la API de binding de Workers.ai, podemos ver que las entradas aquí, pasamos un prompt, déjame pasar env.ai.run con algún nombre de modelo. Y luego eso produce un flujo de respuesta. Así que bastante sencillo para la implementación.

Entonces, lo que queremos hacer es crear un prompt. Así que en este caso, podemos hacer const prompt igual, o llamemos a esto input igual a prompt. Y luego voy a pegar esto. En realidad, queremos una cadena con plantilla. Pega esto y haré title igual a igual a card.title y description igual a card.description. Y lo que es esto, es solo un prompt que estamos pasando a nuestro modelo de stable diffusion. Así que es una especie de pequeña ingeniería de prompts, lo cual es divertido. Y luego lo que queremos hacer es simplemente const stream igual a this.env.ai.run. Lo siento, esto es un pequeño error tipográfico aquí. Queremos this.env.ai.run. Y esto accede a nuestro binding. Así que el AI aquí es nuestro binding. Y luego la función aquí es solo una API inyectada. Y no necesitas hacer ninguna configuración para esto. Simplemente debería funcionar. Si copiamos este texto aquí, copiamos este texto aquí, y luego pasamos nuestro input. Esto debería darnos una salida de imagen de texto. Y deberíamos poder simplemente devolver el stream. Y una salida de imagen de texto AI es solo un readable stream UNT8 array. Así que genial, hemos implementado esta función.

Ahora, intentemos implementar la prueba para esta función. Así que en el caso de Workers.ai, el problema es que no hay soporte de desarrollo local para Workers.ai. Y esto podría ser raro, pero creo que tiene sentido porque no quieres descargar todos estos como modelos AI gigantes en tu máquina local. Pero aún necesitamos poder probar nuestra funcionalidad. Así que en este caso, tenemos que simular la respuesta de nuestra función AI. Así que vamos a crear algunos datos de imagen de muestra. Te doy un pequeño fragmento aquí para generar algunos datos de imagen. Y esto básicamente crea un readable stream falso con solo este array 1234. Y lo que podemos hacer es usar vi.spyon. Y lo que hace vi.spyon es reemplazar alguna implementación de una función, así que env.ai.run. Así que lo que hace esto es espiar env.ai, que en nuestro caso son cualquier llamada a this.env.ai.run. Así que básicamente solo espía esa función. Y en esa función, queremos simular el valor de resolución con el stream. Y lo que eso significa es que estamos simulando el resultado de esta función run. Así que cada vez que ejecutamos esta función localmente en nuestra prueba, si ejecutamos generateCardImage localmente en nuestra prueba, estamos reemplazando la salida de la función ai.run. Así que está generando estos datos de prueba falsos que queríamos. Y luego podemos usar expect. Oh, ups. Creo que import es un poco raro. Pero podemos hacer por test expect. Así que podemos hacer, o en realidad queremos ejecutar nuestra función. Así que cardManager.generateCardImage. Y en este caso, hagamos const card. Y podemos hacer title igual a title. Y description igual a description. Y esto es solo como una tarjeta de prueba que pasaremos. Hagamos simplemente card. Y luego si hacemos const stream result igual a await generateCardImage. Así que estamos generando nuestra imagen de tarjeta. Así que estamos ejecutando la función del card manager.

Y luego podemos esperar el resultado. Así que podemos esperar que nuestro resultado del stream sea estrictamente igual a nuestro stream. Y en este caso, solo estamos afirmando que nuestra respuesta simulada de nuestra función ai.run es la misma que la respuesta de nuestro card manager. Así que vamos a... Nuestro npm run test. Así que ejecutemos la prueba. Y esto, con suerte, debería pasar. Genial, así que esta prueba pasa. Y si quisiéramos no... Si quisiéramos romper esta prueba, debería simplemente, lanzar un nuevo error. Esta prueba debería fallar en este caso. Pero solo estamos verificando que el resultado de esta función es como esperamos. Y la funcionalidad tanto para la versión R2 del card manager como para la versión KB debe ser exactamente la misma. Y déjame enviar eso.

Y solo necesitas implementar uno para el contexto. Y ahora les daré un poco de tiempo para intentar implementar la función de generar y guardar tarjeta, que creo que es probablemente la parte más complicada de este ejercicio porque usaremos KB y R2 en esta instancia, o dos instancias de KB si estás haciendo la versión KB de esto. Así que les daré unos cinco a diez minutos para implementar este ejercicio. Así que voy a empezar a codificar en vivo esta función de generar y guardar tarjeta. Básicamente, solo almacenando la tarjeta en KB y R2. Así que vamos a codificar esto. Así que en este caso, lo que queremos hacer es primero generar un uuid para nuestra tarjeta. Así que esto básicamente va a ser card ID, digamos card ID. Y luego para hacer esto, solo podemos usar crypto.random uuid, que es solo una función estándar aquí. Y luego lo que queremos hacer es insertar los metadatos de la tarjeta como un par clave-valor. Lo que eso significa es que queremos insertar el título de la tarjeta, la descripción y la URL de la imagen bajo una clave específica. Y podemos hacer eso con this.env.kb.put. Y básicamente, eso inserta un valor en KB. Lo que hacemos es hacer card ID. Y luego lo que queremos es insertar nuestros datos JSON convertidos a cadena. Y lo que es eso, es solo como título, card.title, descripción, card.description, y luego image URL igual a imageUrl. Imagen slash card ID. Lo que esto hace es guardar nuestros datos en KB bajo la clave card ID. Y esperemos esto. Y luego además de esto, así que hemos guardado los metadatos de la tarjeta, pero aún no hemos guardado la imagen de la tarjeta. Y queremos guardar la imagen de la tarjeta en R2. Así que podemos hacer await this.env.R2.put. Y esta es una API similar. Y podemos ponerlo bajo card ID. Y queremos poner el valor allí. Y en realidad necesitamos llamar a nuestra función previamente implementada generate card image. Así que primero, hagamos const image igual a await this.generateCardImage. Y pasemos la tarjeta porque estos son los mismos tipos de parámetros con el título y la descripción aquí. Y esto nos da un readable stream de Uint8 array. Ahora, una cosa que es un poco extraña sobre esto es que no podemos simplemente poner esta imagen en R2. Lo que realmente necesitamos hacer de antemano, realmente necesitamos convertir el tipo de datos de la imagen. Y tenemos una pequeña función auxiliar para todos ustedes para hacer esto llamada convertReadableStreamToUint8Array. Básicamente, solo queremos extraer este Uint8 array de este readable stream antes de que podamos ponerlo en R2. Y para hacer eso, solo puedo envolver esta función en convertReadableStreamToUint8Array. Déjame importar esa función de utilidad. Y déjame guardar esta imagen.

Bien, genial. Así que ahora hemos guardado la imagen en R2. Ahora, básicamente hemos hecho toda la lógica de negocio que queremos. Queremos hacer una última cosa, que es devolver nuestro card ID, que nos proporciona el card ID que acabamos de generar y guardar. Ahora, esto podría verse un poco diferente si lo estás haciendo con KV. En el contexto de KV, solo voy a mostrar la solución aquí. Pero en KV, en lugar de hacer R2.put, solo vas a hacer dos diferentes KV.puts. Esto es solo un poco diferente de cómo lo hacemos, pero es efectivamente la misma funcionalidad. Simplemente lo ponemos todo en un bloque promise.all. Pero básicamente necesitas prefijar los datos porque los estás guardando en el mismo espacio de nombres KV. Pero es prácticamente la misma implementación.

Ahora que hemos creado la implementación de esto, podemos realmente probar el resultado de esto. Así que implementemos nuestras pruebas aquí. Así que realmente vamos a necesitar hacer la misma funcionalidad de simulación de binding que hicimos en el paso uno. Y crear como una tarjeta de muestra. La razón es que, si recuerdas aquí, realmente llamamos a generate card image, lo que significa que necesitamos simular AI.run. Pero lo importante es que no necesitamos simular KV o R2 localmente, porque la forma en que funciona el entorno de pruebas del worker es que proporcionamos básicamente una subversión simulada de R2 y KV que funciona automáticamente localmente. Así que funcionan básicamente como esperarías en producción.

Así que comencemos a implementar generate and save card. Así que digamos que hacemos const card ID equals await card manager, card manager.generateAndSaveCard. Vamos a pasar esta tarjeta. Y lo que esto hace es, como dijimos antes, inserta en KV y R2 y genera la imagen. Así que lo que queremos hacer aquí es afirmar que hemos guardado los datos correctos en KV y R2. Y puedes hacer esto accediendo a la variable env. Proporcionamos en el entorno de pruebas, hay una variable env expuesta a la que podemos acceder aquí y acceder a ellas tal como lo haríamos dentro de nuestra implementación.

Así que realmente podemos hacer, en el caso de env.kv, podemos hacer env.kv.get. Así que vamos a obtener nuestro card ID que acabamos de generar. const kv card equals await env.kv.card.get. Y realmente podemos mostrar eso como JSON. Vamos a hacer un typecast de esto a una tarjeta. Y luego podemos simplemente esperar que kv card.title sea estrictamente igual a card.title. Y podemos ver que esto debería asegurar que estamos obteniendo el resultado correcto de KV. Así que vamos a ejecutar esta prueba. Genial, eso pasa. Y si cambiáramos esto a foo, esto debería fallar. Y genial, así vemos que estamos obteniendo los datos correctos de kv card de KV. Y luego también podemos afirmar los otros valores. Así que en este caso, podemos hacer descripción. Y además de esto, también hemos insertado algunos datos en R2. Así que lo que queremos hacer es también imagen R2. Así que queremos esperar env.r2.get card ID. Y esto nos devuelve los datos de R2 de nuestra tienda. Y para hacer esto, podemos esperar que R2 image.arraybuffer. Solo vamos a acceder al array buffer aquí. Esto es realmente una función que se puede esperar. Así que estamos haciendo algunas conversiones aquí. Y podemos configurarlo para que sea estrictamente igual a estrictamente igual R image array.buffer. Hay muchas maneras de afirmarlo, pero esta es solo la forma en que lo estoy afirmando. Probablemente hay algunas, puedes afirmar los streams legibles, puedes afirmar como algunos blobs, pero esta es solo una forma de hacerlo. Y luego presumiblemente, esto también debería pasar. Genial, genial. Así que hemos afirmado que estamos almacenando los datos correctos en KV, y estamos afirmando que almacenamos los datos correctos en R2. Así que genial. Así que, y la funcionalidad o la prueba va a ser muy, muy similar para KV, excepto que en lugar de obtener del card ID, vas a obtener puramente de KV con algún prefijo. Pero ahora que hemos completado eso, les dejaré a todos implementar la función get card, que debería ser bastante sencilla dado que ya hemos estado obteniendo algunos datos de KV en nuestras pruebas. Así que les daré a todos un poco menos de tiempo para hacer esto solo porque es un poco más sencillo. Así que ahora que hemos pasado un poco de tiempo, vamos a repasar la sección de código en vivo para get card. Así que lo que esto hace es que básicamente solo queremos leer algunos datos de tarjeta de workers KV, y luego devolver esa tarjeta si existe. Si no, entonces devolveremos null, o si es como datos inválidos, también devolveremos null. Así que lo que queremos hacer aquí es const card equals await, si recordamos de la prueba anterior, podemos hacer env o esto, env.kv.get, podemos hacer card ID porque esa es nuestra clave en este caso, y podemos mostrar eso como JSON. Y vamos, realmente no sabemos si el tipo es válido o no, pero así que hagamos una verificación de null si card es nuevo, simplemente devolvamos no. Y luego también podemos hacer, tenemos un pequeño guardián de tipo para ti así que si no es una tarjeta, tenemos un guardián de tipo llamado is card, simplemente importaremos eso y básicamente, si no está en el tipo de datos que esperamos, así que como si current tiene un valor extra o no tiene, o si card no tiene como los parámetros correctos o algo, fallaremos y simplemente podemos devolver null, de lo contrario sabemos que tenemos una tarjeta y simplemente podemos devolver la tarjeta, genial. Así que implementación bastante sencilla para esta función, solo algunas obtenciones básicas y verificaciones de null. Y luego una vez que hemos implementado esto, probémoslo y probemos en dos casos, así que una tarjeta nula que es bastante sencilla simplemente hacemos await const card equals await cardManager.getCard null card. Esto no va a existir porque no hemos insertado ningún dato en KB, así que simplemente esperemos que la tarjeta sea null y eso debería pasar. Así que ejecutemos esta prueba. Genial, genial. Y luego, en segundo lugar, queremos intentar afirmar algunos datos con una tarjeta no nula. Así que const card to insert o card to put, digamos, y pongamos algunos datos que esperamos. Así que título título, descripción, descripción y luego tal vez URL de imagen, example.com slash image. Y luego podemos hacer await env.kb.put y simplemente podemos hacer clave, o simplemente hagamos como const key equals, hagamos realmente un UUID aleatorio. Clave, y luego JSON.stringify card to put y luego podemos hacer cardManager.getCard de esa clave que acabamos de usar, card equals y luego simplemente afirmemos que la tarjeta es estrictamente igual a lo que pusimos allí. Así que esperemos que la tarjeta sea estrictamente igual a nuestra tarjeta para poner, así que simplemente verifiquemos que estas tarjetas son las mismas, que estamos obteniendo el mismo resultado que esperamos. Y parece que esto falló, el almacenamiento aislado falló. Ah, eso es, este es un error clásico, olvidé esperar, así que esto debería resolverse.

Porque, genial, así que ahora que esperamos, nuestra prueba está funcionando y estamos obteniendo la respuesta correcta. Así que ahora el paso final es implementar y probar la función getCardImage, les dejaré implementar esto por un par de minutos y luego revisaremos la solución. Oh, y olvidé mencionar que la solución de KB es casi exactamente la misma en este caso, solo estás agregando un prefijo diferente a la, solo estás agregando un prefijo diferente a la clave. Pero por lo demás, bastante sencillo. Pero ahora intentemos implementar la función getCardImage.

Así que bastante sencillo, similar al método anterior. Así que hagamos cardImage y queremos obtenerlo de R2, así que eso es await this.env.r2.get, y ese será nuestro cardId pasado, o hagamos r2 image, de hecho, dejémoslo así. Y luego devolvemos r2 image.body que es solo un array buffer, o no un array buffer, es solo un flujo legible. Y si no existe, es indefinido, podemos hacer, podemos simplemente hacer una coalescencia nula. Así que básicamente, devolveremos el flujo si existe o simplemente devolveremos null. Implementación bastante simple.

Ahora implementemos las pruebas para nullCard. Esta va a ser una configuración similar a nuestra versión de KB. GetCardImage, hagamos solo cardImage. Esta va a ser bastante sencilla. Genial, debería pasar, con suerte, sí, ahí vamos. Y luego podemos hacer algo similar a lo que hicimos antes e insertar algunos datos en R2. Así que const, creemos algún uuid, const equals crypto.randomUuid. Y luego creemos algunos datos de muestra. Así que solo voy a copiar este array uint8. Y luego voy a hacer env.r2.put uuid y luego image array. Así que estamos poniendo algo en R2 y luego hagamos const R2 image igual a cardManager.getCardImage y luego uuid. Y esto debería devolvernos un flujo legible. Así que esperemos que esto devuelva, oh espera, necesito esperar esto para no tener fallos. Así que hagamos R2 image a strict equal R image array. Pero lo importante, si notamos aquí esto es un array uint8. Y luego esto es un flujo legible de array uint8. Así que usemos nuestra función auxiliar de antes. Así que hagamos solo await convert readable stream a uint8 array y pasemos ese flujo legible allí. Así que ahora ambos deberían ser del mismo tipo de datos. Creo, bueno, hagamos solo como flujo legible, solo voy a como flujo legible. Solo voy a hacer un typecast de esto. Idealmente también puedes simplemente hacer una afirmación nula. Cualquiera de las dos está bien porque la prueba fallará si no se afirma correctamente de todos modos. Y luego estas pruebas deberían pasar. Genial. Así que ahora hemos implementado esto. Si estás haciendo la versión de KV de esto, va a ser prácticamente lo mismo, excepto que en lugar de insertar en KV bajo algún prefijo de clave. Pero sí, esta es básicamente la implementación para nuestro cardManager. Y les dejaré tener un pequeño descanso de cinco minutos. Y luego trabajaremos en integrar la UI y el código del backend juntos. Dejaré que Dario haga eso después de ese descanso. Después de haber implementado con Christian nuestra lógica de backend, ahora queremos realmente integrar esta lógica de backend con nuestra UI. Y este es el lado perdido entonces. Esto es sencillo. Como vimos en el primer paso, implementamos nuestra acción y loader. Y lo que queremos hacer ahora es realmente en esas funciones usar nuestra clase cardManager. Así que primer paso, integrar la acción, luego el loader, y luego tenemos una ruta de imagen que también necesitamos integrar con nuestro backend. Así que de todos modos, comencemos con el primer paso. Y tomemos cinco minutos para...

Te daré cinco minutos para trabajar en esto, y luego podemos trabajar en la solución juntos. Una nota, si estás usando la versión KB de esta implementación, es posible que tengas que ir a... Déjame abrir el archivo. Necesitarás intercambiar la implementación predeterminada porque por defecto usamos la implementación R2, pero solo necesitarás modificar este archivo según sea necesario para cambiar a KB. De lo contrario, puedes dejar ese archivo tal como está.

Vamos a trabajar en la solución juntos. Abramos nuestro VS Code. Y así estaba el estado de nuestra aplicación. Podemos proporcionar entradas, y podemos colocar todos los resultados. Así que si ahora voy al Fortecsize Ritmi, y revisamos el primer paso, queremos integrar la acción con nuestro card manager. Así que queremos ir a nuestro archivo index y actualizar la función de acción. Y por cierto, una cosa que notarás es que aquí tengo un montón de validaciones extra y demás. Esto es solo un paso opcional en el primer ejercicio. Así que si no lo tienes, no es necesario tenerlo necesariamente. No se espera que lo tengas. De todos modos, lo que este paso nos está pidiendo es ahora eliminar el log y el sleep ficticio. Luego queremos acceder a las bindings de Cloudflare. Y en Remix, puedes hacerlo a través de este objeto de contexto que se te proporciona en los argumentos de acción. Una vez que obtienes el contexto, puedes acceder a las bindings de Cloudflare a través de context Cloudflareenv. Y esto es lo que usaremos para realmente, lo que obtendremos y pasaremos al constructor del card manager. Así que ahora podemos crear un card manager. Y para esto, nuevamente, podemos usar el context Cloudflareenv. Así que de esta manera, simplemente creamos nuestro card manager. Y en lugar de ahora generar un ID de tarjeta de marcador de posición, podemos simplemente usar nuestro card manager ejecutando el generate and save card. Y queremos pasar nuestro título y descripción. Aquí, TypeScript se queja un poco solo porque no entiende que el título y las descripciones son cadenas. Así que simplemente hagamos un typecast rápido. Y de esta manera, también necesitamos esperar esto. Y de esta manera, obtenemos nuestro ID de tarjeta. Así que ahora, en lugar de tener alguna implementación de marcador de posición de nuestra acción, realmente tenemos una integración adecuada con nuestro backend. Así que sí, este fue el primer paso.

A continuación, está actualizando el loader. Así que dediquemos unos minutos también a ese. Y hagamos un typecast a ese también. Trabajemos en el segundo paso juntos. Y aquí, solo estamos implementando el loader, que va a ser bastante similar a lo que acabamos de hacer con la acción. Y sí, nuevamente, obtenemos un contexto de Remix en sí. Y así nuevamente, queremos crear un card manager usando las ClutterBindings. Podemos hacerlo después de haber verificado que tenemos un ID de tarjeta. Y finalmente, en lugar de devolver un objeto de marcador de posición, podemos usar nuestro card manager y obtener la tarjeta basada en el ID de la tarjeta. Así que esto debería ser prácticamente todo para el loader. Si vamos a nuestra aplicación, deberíamos poder proporcionar algunos datos como... y generar una tarjeta. Así que la cosa debería funcionar ahora. Veamos. Sí, todo está funcionando como se esperaba. Lo único es que puedes ver que no obtenemos la ilustración de la tarjeta. El hecho es que realmente la estamos generando y guardando, pero no hemos implementado la ruta API que sirve la imagen a nuestra aplicación. Y ese es el tercer paso. Así que sí, tomemos unos minutos para también implementar eso.

Bien, repasemos rápidamente el tercer paso. El primer paso, como mencioné, fue sobre la implementación del enrutador de imágenes, que es este archivo con el que aún no hemos trabajado. Entonces, lo que se requiere aquí, queremos obtener, en primer lugar, el ID de la tarjeta de los parámetros de la URL de la ruta. Esto es algo que, nuevamente, Remix te proporciona. Así que en nuestros argumentos del loader, obtenemos el campo params que podemos usar para obtener el ID de la tarjeta. Así que params get... En realidad, es un objeto. Así que obtenemos el ID de la tarjeta del objeto param, y aquí también queremos obtener las bindings de la tarjeta del contexto que usaremos para crear nuestro card manager. Luego podemos generar nuestro card manager. Así que nuevamente, card manager igual a new card manager y proporcionar las cloud bindings. Y lo que queremos hacer aquí, llamaremos a nuestra función getCardImage para que, dado un ID de tarjeta, intentemos recuperar la imagen de esa tarjeta, y proporcionamos nuestra tarjeta. Obtenemos un error de tipo aquí solo porque el ID de la tarjeta podría no estar definido. Pero en realidad, no puede estar indefinido debido al enrutamiento de Remix, pero no es consciente de eso, así que tenemos que agregar esta afirmación de no nulo. Así que en este caso, obtenemos nuestro card imager, pero como estamos recuperando esto de nuestro almacenamiento, podría ser nulo. Así que en ese caso, queremos devolver una respuesta 404. Básicamente, si intentamos recuperar una imagen de una tarjeta que realmente no hemos generado, o si algo salió mal y no tenemos la imagen real en nuestro almacenamiento, queremos devolver una respuesta 404. Y aquí podemos decir no encontrado. De lo contrario, devolvemos una respuesta normal, return new response, y en esta respuesta, devolvemos la imagen de la tarjeta en flujo real. Esto no debería ser una imagen de tarjeta. Y aquí también necesitamos proporcionar el error de tipo de contenido configurado a image PNG. Así que esto debería ser prácticamente todo si ahora vamos a nuestra aplicación, puedes ver que ahora estamos realmente recuperando la imagen correctamente. Así que esto integra completamente nuestra UI con nuestro backend, completando la aplicación.

A continuación, dado que nuestra aplicación está completa, podemos proceder con algunas pruebas E2E. Lo que hemos estado probando hasta ahora con Christian ha sido más una prueba unitaria o de integración. Y lo que realmente queremos hacer ahora es realizar la integración completa de extremo a extremo, pruebas de extremo a extremo en las que realmente integramos con el navegador y verificamos que todo el comportamiento esperado del usuario de nuestra aplicación esté presente. Usaremos Playwright para hacer eso. Es un marco de pruebas E2E popular de Microsoft. Hay otras alternativas, pero esta es una que encontramos bastante agradable para trabajar. Esa es nuestra elección para las E2E aquí.

Así que podemos proceder con nuestros ejercicios. Los ejercicios, perdón, los pasos del ejercicio aquí son los iniciales un poco prescriptivos. Así que haremos los primeros tres ejercicios juntos. Y el cuarto, vuelve a ser un ejercicio estándar, al que te daremos algo de tiempo para que lo hagas por tu cuenta. Como primer paso de nuestro ejercicio, simplemente queremos instalar Playwright. Y queremos establecer el directorio de E2E como el directorio donde tendremos nuestras pruebas. No nos importa GitHub. Y sí queremos instalar los navegadores de Playwright. Así que una vez hecho esto, puedes ver que Playwright está listo y también sugiere algunos comandos útiles que podríamos usar. Y sí, este es realmente solo el primer paso de nuestro ejercicio.

En segundo lugar, realmente queremos ajustar el archivo de configuración de Playwright. Y eso es porque queremos que Playwright ejecute la aplicación usando nuestro CLI de wrangler. Esto significa que realmente queremos ejecutar nuestra aplicación en el tiempo de ejecución de los trabajadores para que realmente coincida lo más cerca posible, el comportamiento real de producción. Y para esto, cambiaremos el comando para que Playwright inicie el servidor de desarrollo a vista previa, que podemos ver en nuestros paquetes que ejecuta nuestro CLI para. Y también necesitamos cambiar el puerto a 8788. Así que este fue el segundo paso.

Y el tercer paso es el complicado. Así que tenemos este problema en el que realmente no queremos ejecutar la inferencia de AI durante los ajustes. Hay algunas razones para eso, pero principalmente porque, como viste, puede tomar un poco de tiempo para que se genere la imagen, pero también puede incurrir en algún costo ejecutar la generación de AI a menudo. Así que realmente no queremos hacer eso cuando simplemente estamos probando nuestra aplicación. Así que para hacer eso, necesitamos introducir un nuevo script de herramientas a nuestros paquetes. Aquí. Y básicamente, estos son simplemente para ejecutar nuestra aplicación con esta vinculación. Esta es una vinculación de prueba, vinculación de texto, que configuramos que se llama mod, y la configuramos a este texto de prueba e2e. Así que estamos configurando esta vinculación, que luego verificaremos en nuestro código para ver si estamos en este tipo de modo de prueba e2e. Una vez que agregamos estos scripts, realmente también necesitamos actualizar nuestra configuración de Playwright para que realmente ejecute nuestra aplicación en modo de prueba. Y a continuación, aprovecharemos esta API de Remix un poco más avanzada, que realmente te permite personalizar el contexto de carga que obtienen tus acciones y cargadores. Así que realmente queremos cambiarlo para que si estamos en este modo de prueba e2e, en lugar de obtener la vinculación de AI real como hemos estado obteniendo hasta ahora, obtendremos una versión simulada de ella. Para hacer eso, simplemente queremos ir al archivo load context TS. Aquí, tenemos realmente un copiar-pegar muy simple, pero solo queremos importar las cosas correctas. Y luego simplemente copiamos y pegamos. No copié lo correcto. Volvamos. Así que simplemente copiamos esta función. Déjame eliminar todas las clases y guardar. Así que esta es una función simple en la que, nuevamente, verificamos esta vinculación de texto de nuestro ENB. Y si estamos en modo de prueba, en lugar de la vinculación de AI real, configuraremos una vinculación de AI modificada, que ya configuramos de todos modos con anticipación. Ya implementamos con anticipación. Una vez que actualizamos este archivo, realmente necesitamos usar esta nueva función en dos lugares. Uno es este archivo de ruta de funciones, que es básicamente lo que inicia tu aplicación de páginas. Y nuevamente, simplemente copiamos y pegamos los cambios correctos. Así que ahora, le decimos a Remix, está bien, en lugar del estándar, el contexto de carga, deberías usar este contexto de carga personalizado. También queremos hacer lo mismo en el vid-config.js, que no afecta la vista previa y la versión de implementación de la aplicación, pero esto es simplemente para mantener en línea lo que obtienes cuando estás ejecutando la aplicación en ese modo usando vid y cuando realmente la previsualizas usando nuestro CLI y producción.

Así que también podemos actualizar el archivo aquí. Y una vez que hayamos hecho todos estos cambios, podemos ejecutar nuestra aplicación en modo de prueba de vista previa. Así que esto realmente construye la aplicación y la ejecuta usando nuestro CLI. Esta es la URL con el puerto 8788 como vimos antes. Y aquí puedes ver que todavía tenemos nuestra aplicación y si hacemos clic en generar, realmente está devolviendo de inmediato, así que esto realmente nos muestra que, sí, la vinculación de I está siendo simulada y no obtenemos una imagen real en este caso. Así que eso es exactamente lo que queríamos.

Y a continuación, queremos usar la generación de código de Playwright para interactuar realmente con esta vista previa en la versión de modo de prueba de nuestra aplicación, interactuar con el formulario y afirmar que realmente obtenemos el resultado esperado una vez que envías tu formulario. Así que este es el cuarto paso del ejercicio que te daremos algo de tiempo para implementar y luego lo haremos juntos en unos minutos. Genial, así que si quieres, resolvamos el ejercicio juntos. Déjame volver a mi VS code. Bien, lo que ahora el cuarto paso estaba pidiendo era ejecutar la prueba de vista previa y en una terminal separada, ejecutar npx play write code gen y proporcionar nuestra URL. Así que lo que obtienes cuando haces esto es realmente una ventana del navegador con el inspector de play y puedes simplemente interactuar con tu aplicación y play write generará algún código de prueba para ti.

Así que por ejemplo, queríamos verificar que tenemos una tarjeta que tenemos una imagen, un marcador de posición de imagen debería decir y tenemos dos entradas. Una para el título en la que puedo escribir título y otra para la descripción en la que puedo escribir descripción. Luego puedo generar la tarjeta y también puedo afirmar que obtenemos nuevamente obtenemos la tarjeta con ilustración y también tenemos un título y descripción. Incluso podemos afirmar que este elemento realmente contiene el texto que esperamos, por ejemplo. Así que una vez que haces esto, realmente puedes ver que play write generó un montón de código de prueba para ti que podemos simplemente copiar y pegar en nuestros archivos de prueba e2e. Así que puedes simplemente crear un nuevo archivo de especificación o lo que estaría haciendo ahora es simplemente sobrescribir el ejemplo e2e1 que play write genera para nosotros. Así que voy aquí y simplemente copio el código que play write nos dio. Ahora mato mis procesos y si ahora ejecuto npx play write test esto realmente ejecutará nuestra prueba y deberíamos ver que pasa.

También deberíamos ajustar ligeramente la prueba por ejemplo, estamos probando la generación de tarjetas. Hice clic más de una vez, esto deberíamos eliminarlo. Lo hice yo, oh no. Sí, seleccioné el elemento incorrecto, creo. Y luego, sí, todo debería ser como se esperaba. Solo para una verificación de cordura también podemos intentar romper la prueba. Por ejemplo, afirmando el texto incorrecto como si el elemento contiene el texto incorrecto. Y otra característica genial de playwright es que realmente puedes proporcionar esta bandera de UI y puedes ejecutar tu prueba con esta presentación de UI. Así que si realmente ahora ejecutamos esta prueba aquí deberíamos ver que debería fallar. Oh, lo ejecuté por error. Porque en algún momento puede encontrar el texto que acabo de romper aquí. Pero si lo arreglo y volvemos aquí ahora debería poder ejecutar la prueba. Y como puedes ver, todo está pasando y realmente está diciendo, está bien, el texto es correcto. Así que sí, este fue el ejercicio, el cuarto paso del ejercicio. Una cosa a notar es que terminamos con algunas pruebas bastante frágiles. Como por ejemplo, un playwright intenta usar el mejor localizador para tus elementos, pero no siempre puede obtener cosas que son perfectas si tu código no permite un selector más específico y robusto para tus elementos. Y en este caso podemos ver que playwright a veces solo localizó cosas como divs y obteniendo el primero o el segundo u obteniendo elementos por marcadores de posición y cosas así.

Así que el siguiente paso del ejercicio es realmente cambiar nuestro código para que sea más fácilmente comprobable y Playwright pueda realmente generar localizadores más robustos y estables para ti. Para que puedas hacer cambios y la prueba no se rompa solo porque cambiaste algo y en lugar de un div tienes un span o lo que sea. Dado que no estamos muy bien de tiempo, probablemente solo codificaré en vivo la solución si está bien. Y para eso realmente queremos ir a nuestra ruta de índice y vamos aquí y veamos tenemos nuestro formulario y nuestras entradas. Para las entradas queremos establecer este atributo de ID de prueba de datos que es algo que Playwright reconocerá y aquí podemos hacer como título de entrada. Podemos hacer lo mismo para la descripción y para la imagen también. Y luego también podemos hacerlo para el botón. Así que hagamos, establezcamos el ID de prueba para el botón de generación de tarjeta y finalmente para la imagen de la tarjeta. Salida y luego también para el título y la descripción. Así que salida del título de la tarjeta y salida de la descripción de la tarjeta. Así que con todos estos nuevos atributos de ID de prueba, puedo repetir el ejercicio de generación de código que hicimos antes. Así que déjame realmente comenzar de nuevo nuestra aplicación en el modelo de prueba de vista previa y luego ejecutar la herramienta de generación de código de Playwright. Y en este caso podemos afirmar cosas y como puedes ver inmediatamente Playwright ahora es lo suficientemente inteligente como para realmente priorizar los IDs de prueba y seleccionarlos por esta utilidad de obtener ID de prueba. Sí, no entraré en detalles sobre todo el flujo pero como puedes ver de esta manera terminamos con una prueba más estable para que en el futuro si haces cambios sea mucho más difícil realmente romper estas pruebas de manera no intencionada. Y así sí, esto concluye el quinto ejercicio y esto nos lleva prácticamente al final de la masterclass. Después de la masterclass si estás interesado en explorar un poco más y seguir jugando un poco con la aplicación pusimos un par de ideas en este extra y en el repositorio. Así que hay cosas en las que aún puedes trabajar si quieres tener una idea más sobre la plataforma Calculator y lo que ofrece. Por favor, si quisieras tenemos este formulario de Google así que nos encantaría escuchar algunos comentarios y lo que hicimos bien, lo que hicimos mal y cualquier comentario que tengas para nosotros para mejorar en el futuro. Sí, y pegué todos esos enlaces así que siéntete libre de revisar todo. Escribe cualquier comentario así como para referencia futura si quieres acceder a la grabación pegué ese enlace y el repositorio y las diapositivas están todos allí y si todos tienen alguna pregunta nos quedaremos aquí por un par de minutos. Pero de lo contrario eso es prácticamente todo. Y por cierto sí, obviamente muchas gracias por unirse y sí. Aguantando toda la masterclass porque es una masterclass de tres horas. Sí, en realidad tiene que ser la última pero con esto. Gracias por asistir Dan, gracias.