Cómo probamos Storybook en sí

Vamos a hablar de cómo puedes usar TypeScript para escribir JavaScript con TypeScript. Hablaremos de cómo puedes usar TypeScript para escribir JavaScript con TypeScript. Hablaremos de cómo puedes usar TypeScript para escribir JavaScript con TypeScript. Hablaremos de cómo puedes usar TypeScript para escribir JavaScript con TypeScript. Hablaremos de cómo puedes usar TypeScript para escribir JavaScript con TypeScript.

No es perfecto. Y este es un tipo de charla que nunca he dado antes. Así que antes, siempre daba una charla sobre, oh, deberías hacer esto nuevo ahora mismo. Este es más bien un estudio de caso. Y por lo tanto, hay muchos detalles interesantes para mí. Espero que también sean interesantes para ti.

Soy de los Países Bajos. Y como se introdujo, trabajo para una empresa llamada Chromatic. Pero mi trabajo a tiempo completo es mantener Storybook. Así que tengo que sacar esto del camino antes de poder hablar de lo que hace funcionar y trabajar a Storybook internamente.

¿Qué es Storybook? Storybook es una herramienta que puedes usar para construir mejores componentes. Porque el principio fundamental de Storybook es que puedes trabajar en ellos de forma aislada. En lugar de trabajar en tus componentes de arriba a abajo, básicamente puedes empezar a trabajar en cualquier componente primero. Puedes catalogar todos esos componentes y todos sus estados, todas las variantes. Y puedes probarlos muy importante. Eso es de lo que trata esta conferencia, ¿verdad? Y entonces definitivamente quieres compartir esos componentes con tus stakeholders. Storybook es bastante popular, lo cual es muy humilde para mí. Todas estas empresas están usando Storybook. Y la razón es que en algún momento cuando estás construyendo aplicaciones, podrías empezar con algunos componentes fáciles. Y todo parece super fácil. Pero en algún momento, alcanzas un nivel de componentes que es simplemente complejo. He visto componentes de como 5,000 líneas de código. Y todo está contenido dentro del archivo. Como si pudieras entender todo, podrías. Pero a menudo, aprendes cómo se ejecuta el código y cómo funciona por cómo se usa.

La premisa de los componentes es que puedes usarlos en todas partes. Entonces, si un componente que es complejo tiene todas estas diferentes variaciones y variaciones en la aplicación, bueno, no vas a buscar en toda la aplicación y buscar todos esos casos de uso. Así que eso es realmente de lo que se trata Storybook. Está reuniendo todos esos diferentes casos extremos extraños que quizás ni siquiera encuentres normalmente en tu aplicación y los reúne para que puedas visualizarlos allí.

A menudo se pasa por alto que estos casos extremos extraños pueden ser combinatorios. Entonces, un estado de carga y un estado no autenticado y un idioma diferente pueden unirse todos juntos.

Muy bien. Con eso fuera del camino, puedo empezar a hablar de mi presentación actual, ¿verdad? Así que Storybook es, por sí mismo, bastante complejo. Y eso es por lo que hacemos. Storybook es como una aplicación web que arrancas junto a tu propia aplicación web. Y entonces tenemos que lidiar con lo que tu aplicación web hizo porque estamos mirando el mismo código fuente que tu aplicación web.

Así que tenemos que lidiar con múltiples constructores, Webpack y Vite. Tenemos que lidiar con múltiples frameworks como React, Vue, Angular, Svelte, etc. Y luego están los meta frameworks superpuestos a esos, como Next.js y SvelteKit. Tenemos que lidiar con múltiples gestores de paquetes, npm, yarn, pnp y pnpm. A algunas personas les encanta TypeScript, incluyéndome. Pero luego algunas personas sienten que, no, no quiero una capa de traducción entre escribir mi código y ejecutar mi código, lo cual también es válido. Y así que apoyamos ambos lenguajes. Y tratamos de apoyarlos a ambos por igual.

Y algo acaba de salir mal con las diapositivas. Y luego, encima de eso, todas esas cosas están fuera de nuestro control. Pero también nos complicamos la vida añadiendo más banderas de características y haciendo que Storybook sea muy configurable. Porque queremos que cualquiera pueda usar nuestra herramienta, pero eso significa que muchas personas se convierten en muchas opiniones. Y hacer feliz a todo el mundo significa que debes añadir configurabilidad. Intentamos modularizar nuestro conjunto de características en complementos. Y queremos permitir que cualquier otra persona cree tales conjuntos de características también. Así que en realidad tenemos una API de complementos de la comunidad que cualquiera puede usar. Y luego el elefante en la habitación, honestamente, es la compatibilidad hacia atrás. Así que Storybooks ha existido durante unos 7 a 8 años. Y así nuestra base de código ha cambiado mucho. Nuestra mentalidad, nuestras ideas de lo que los Storybooks deberían hacer, en realidad ha cambiado mucho. Pero al mismo tiempo, no queremos decir a los usuarios, como, lo que has estado haciendo durante los últimos N años, simplemente deséchalo, y haz esta otra cosa en su lugar. O cuando tenemos que hacer algo así, queremos darles guías de migración claras, o incluso auto-migraciones.

Muy bien, así que pruebas Storybook, y pruebas toda esa complejidad. Saquemos de en medio las cosas fáciles. Tenemos un monorepo con más de 80 paquetes.

Sí, eso es parte de lo fácil. Usamos TypeScript en toda nuestra base de código para asegurarnos de que todos estos paquetes diferentes y todas estas rutas de código, se interconectan correctamente. TypeScript es un factor enorme de cuánta confianza tenemos en nuestro código. Usamos ESLint para cuidar algunos de los errores sutiles que podrías encontrar. Y luego, obviamente, tenemos un montón de pruebas unitarias para todos los pequeños fragmentos de código individualmente. Cualquier cosa que sea una traducción fácil de A a B, tenemos pruebas unitarias para ello. Y luego, curiosamente, Storybook tiene algo de su propia interfaz de usuario, que está escrita en React. Y así tenemos un Storybook para Storybook. Tenemos un montón de componentes de interfaz de usuario que tienen historias que componen Storybook. Y luego puede ser bastante meta donde ves una pieza de Storybook dentro de Storybook.

Muy bien. Lo difícil. Porque esto es realmente algo que nos mantendría despiertos por la noche si no lo tuviéramos. Si alguien añade Storybook a su proyecto, ¿funciona? Después de haberlo añadido, ¿Storybook sigue funcionando? ¿Y puede crear una compilación? Si añaden complementos, ¿funcionan? Si cambian algunas configuraciones, ¿esas configuraciones hacen lo que se supone que deben hacer? Muchas de nuestras configuraciones en realidad se convierten en la configuración de algunas otras herramientas. Si configuras Storybook para soportar MDX, en realidad configuramos Webpack para que soporte MDX. Así que nuestras pruebas también prueban muchas cosas como los gigantes en los que nos apoyamos. Y otra parte importante para Storybook, muy importante para nosotros, algo en lo que nos hemos enfocado mucho en el último año y medio es el rendimiento y el tamaño de la instalación. Y para nosotros, es realmente importante saber que cuando fusionamos PRs, ¿es el rendimiento el mismo o es mejor? ¿Es peor? ¿Es un intercambio aceptable para hacer? Y lo mismo para el tamaño de la instalación y ¿qué tan grande es cuando creas una versión estática de tu Storybook? ¿Qué tan grande es eso? ¿Está aumentando con este PR? ¿Sí o no?

Bueno, no queremos hacer esto manualmente todo el tiempo, ¿verdad? Como definitivamente no. Y estos pasos no son súper fáciles porque configurar un nuevo proyecto Next.js necesita una conexión a Internet activa. Necesita hablar con NPM. Añadir Storybook también invoca una CLI que normalmente invocarías a través de algo como NPX. Y luego va y habla con NPM de nuevo para descargar los paquetes correctos basándose en el archivo o carpeta en el que se encuentra.

Así que la CLI de Storybook hace diferentes cosas basándose en lo que ya está en el directorio en el que la estás ejecutando. Así que si tienes un proyecto de vista, la CLI de Storybook añadirá Storybook para vista a él. Si estás usando React, añadirá Storybook para React a él, etc. Así que en esta prueba, si fuéramos a escribirla tal como está, hay otro factor de complicación porque, bueno, no queremos probar cosas que ya están en NPM, ¿verdad? Eso sería un poco tarde.

Así que queremos probar el código que está en nuestro repositorio, pero entonces la CLI viene de NPM. Y va a hablar con NPM para descargar el código. Así que lo que necesitamos es como un proxy NPM delante de todo esto. Y ese proxy NPM necesita estar lleno de cosas, ¿verdad? Y así, para llenar ese proxy con los paquetes que vienen de nuestro repositorio, necesitamos ir y conseguir ese repositorio. Necesitamos descargar todos los paquetes para hacer que eso funcione. Necesitamos compilar todos esos paquetes locales, luego configurar el proxy Ferdacho NPM y publicar los paquetes. Y luego podemos configurar el proyecto. Luego podemos añadir Storybook a él. Y en realidad podríamos querer hacer algunas modificaciones clave en la configuración de Storybook porque podríamos querer probar esas. Y luego podemos simplemente realizar esas comprobaciones.

Bien, casi estamos allí. No queremos hacer todo esto de una vez por cada línea de código que cambiamos. Eso sería horrendo. Esto lleva algún tiempo para ejecutar todo esto.

Esto lleva algún tiempo ejecutar todo esto. Entonces, si queremos hacer esto más a menudo que dos veces al día, necesitamos todo tipo de capas de caché en medio. Pero el alcance es aún mucho mayor que eso. Solo te mostré un proyecto, ¿verdad? Pero, de nuevo, apoyamos muchos tipos diferentes de proyectos. Apoyamos proyectos generados por Vue CLI. Apoyamos CRA. Apoyamos Next.js y Vite CLI. Muchos de estos generadores tienen todo tipo de banderas para generar con diferentes idiomas, etc. Y, como dije, queremos apoyar y probar la multitud de configuraciones que permitimos a los usuarios establecer. Y no solo tenemos una rápida comprobación de si Storybook funciona, sino que queremos comprobar varias cosas. Queremos comprobar si el corredor de pruebas funciona. Queremos probar si la construcción estática funciona, etc. Entonces, el escenario real se ve más o menos así. 80 paquetes para compilar, 80 paquetes para publicar, 50 proyectos diferentes para configurar, a los que necesitamos agregar Storybook, y 5 modificaciones diferentes para hacer, y luego unas 8 pruebas para ejecutar.

Ahora, afortunadamente, el CI, si estamos ejecutando esto en un CI, podemos hacer muchas de estas cosas en paralelo. Y por lo tanto, no tiene que llevar mucho tiempo, pero aún así lleva algún tiempo. Pero es muy importante no pensar solo en CI. Es importante para lo que este flujo de trabajo y todas estas pruebas significan para el mantenedor promedio de Storybook día a día. ¿Cómo te aseguras de que el PR en el que estás trabajando funciona? Bueno, podrías simplemente subirlo a GitHub y esperar al CI, pero definitivamente quieres poder hacerlo localmente también y obtener un ciclo de retroalimentación decentemente rápido. Entonces, lo que hemos hecho es que hemos creado un script que cualquiera en el repositorio puede invocar con una prueba o paso objetivo específico en mente. Entonces, quiero probar si una prueba de extremo a extremo después de una construcción estática, si eso funciona. Entonces puedes apuntar a esa prueba específica. Y luego el script simplemente averigua exactamente cuál es el estado del repositorio en este momento en toda su caché que hacemos. Y luego puede comenzar desde el lugar correcto en el tiempo. Y luego, lo importante es que el script es el mismo en el CI que cuando se ejecuta localmente, lo que significa que cuando un trabajo de CI falla, que es más o menos el punto de un trabajo de CI, ¿verdad? Un trabajo de CI debería decirte cuando algo está mal. Si un trabajo de CI nunca falla, entonces algo está realmente mal. Entonces, definitivamente estamos bien allí. Nuestros trabajos de CI fallan mucho. Pero lo importante es que cuando el trabajo de CI falla, entonces al final solo dice ejecuta esta única línea de código en tu línea de comandos y podrás reproducirlo.

Y esto me lleva a lo que son las plantillas. Y tenemos una lista bastante larga dentro de nuestro monorepositorio describiendo todo tipo de plantillas que Storybook soporta oficialmente. Y oficialmente tenemos todas estas pruebas para. Y simulan lo que los usuarios hacen en el mundo real. La gente real ejecuta Yarn, crea una aplicación Next todos los días. Y crean su próxima aplicación de esa manera. Y luego pueden elegir opcionalmente el dash dash JavaScript como hice aquí. Y luego básicamente describimos en el mundo real, hay estos proyectos que Storybook soporta. Y son los proyectos que usamos para construir todas estas pruebas.

Y así es como se ve nuestra configuración de CI. Tenemos algo de configuración que hacer. Así que esta construcción tarda poco más de tres minutos. Y luego creamos todos estos sandbox. Y luego los construimos todos. Y luego los probamos todos. Y si tuviera que acercarme a los sandbox de construcción aquí. Estos están ejecutando muchos, muchos proyectos todos al mismo tiempo. Lo cual no es barato. Pero funciona. Así que todos estos proyectos se están ejecutando en paralelo completo. Y si uno de ellos falla, lo sabremos. Algo que nos dimos cuenta es que estos proyectos, estos sandbox, en los que arrancamos Storybook, en realidad no cambian tan a menudo. Así que tenemos un trabajo diario que ejecuta estos generadores de proyectos. Y luego almacena estas salidas en un repositorio.

Y resulta que este caché es súper útil. No solo para nosotros, sino también para otros. Así que clonar un repositorio es mucho más rápido que ejecutar este generador normalmente. Pero también es importante, podemos ver cuál es la salida del generador de Next.js con el tiempo. Así que podemos ver cuál es la salida a medida que cambia. Y esto nos da pistas para si Storybook falla al inicializarse en una nueva versión de Next.js, por ejemplo. Como qué cambios internos hicieron. Para que podamos adaptarnos a ello y mantenernos compatibles con el futuro pero también con versiones anteriores. Y también podemos usar este caché para pedir a los usuarios que creen reproducciones de problemas. Así que esto está en realidad vinculado a StackBlitz. Y si usas storybook.new, puedes elegir una de estas plantillas. Y empezar un proyecto y obtener Storybook inicializado encima de él. Y puedes presentar un problema que esté demostrando el error. Sin tener que comprobar nada.

Bueno, hemos hecho toda esta organización. Ahora actuemos. ¿Qué es lo que realmente probamos? Así que cuando inicializas Storybook tú mismo como usuario final, solo obtienes como tres historias y tres componentes. Eso obviamente no es suficiente para obtener una buena cobertura. Así que inyectamos un montón de más componentes e historias. Comprobamos si cada caja de arena puede ser construida estáticamente. Y si el modo de desarrollo funciona. Lo probamos usando el corredor de pruebas. Y lo probamos con los dramaturgos. Y también lo probamos de manera importante con chromatic. De lo cual mi colega Ruben hablará más en una charla posterior.

También nos aseguramos de que Storybook se vuelva más rápido y pequeño con el tiempo. Porque tomamos data de todos estos pasos de caché y lo ponemos en una database. Y podemos ver cuánto tiempo tardaron estos pasos. Así que cuando estamos construyendo la versión estática de Storybook. Para luego ejecutar una prueba de extremo a extremo en ella. Tomamos ese tiempo en cuánto tiempo tomó. Y podemos compararlo con futuros PRs.

Bien, también quiero decir algo sobre la publicación. Nuestra cadencia de lanzamiento es cada 4 a 6 semanas. Intentamos hacer una versión principal aproximadamente una o dos veces al año. Podemos hacer lanzamientos alfa bastante a menudo. A menudo varias veces a la semana. Y podemos tomar cualquier PR y hacer un lanzamiento canario con unos pocos clics del botón. Hacemos lanzamientos escalonados. Lo que significa que podemos obtener PRs fusionados en nuestra rama de desarrollo prácticamente constantemente. No necesitamos esperar. Y luego tenemos una forma muy fácil de crear un PR que está representando efectivamente. Si fusionamos esto hacemos un lanzamiento. Y hay un montón de automation para crear el registro de cambios automáticamente allí también.

Entonces, la forma en que funciona es que tenemos un front end para el sitio web de documentation en otro lugar. Pero luego el contenido del sitio web de documentation se gestiona en el monorepo. Lo que te permite cuando estás añadiendo características. También añadir la documentation junto con ella. Lo cual es genial. Y luego Git es simplemente una forma perfecta de mantener ese contenido en un historial también.

Así que el front end hace solicitudes a GitHub. Para extraer el contenido de la versión correcta que la gente quiere mostrar. Aprendimos un montón de lecciones escribiendo todo esto y haciendo todo esto. Diría que nuestro mayor error fue equivocarnos en la paralelización. Así que la separación de preocupaciones, supongo. Así que cuando te mostré ese gráfico de nuestro CI. Observa cómo la construcción de entornos de pruebas es una cosa. Que todos se ejecutan en paralelo. Pero eso significa que si la cosa next.js o Vue CLI se rompe. Entonces ese trabajo de CI simplemente se detiene. Y no ejecutamos nada más. Así que estamos constantemente corriendo para asegurarnos de que todo funciona. Y así una plantilla puede afectar el fallo de las demás.

También notamos que almacenar y restaurar el espacio de trabajo. Que es una característica de CircleCI de la que dependemos mucho. Lleva mucho tiempo. De hecho, está tomando la mayor parte del tiempo en todo nuestro CI. También notamos más tarde que no todos los entornos de pruebas son igual de importantes. Lo que significa que tenemos algunos entornos de pruebas que esperamos que fallen a veces. Lo cual es realmente malo debido al error anterior que hemos cometido. Porque algunos de estos entornos de pruebas son para versiones alfa de cosas que queremos apoyar. Pero entonces esos no son estables en sí mismos. Y esa es mi charla. Creo que me he pasado bastante de tiempo.

Pero muchas gracias por escuchar. Sí, eso fue super interesante. De hecho, hice un fork de Storybook el verano pasado y ejecuté la prueba. Estábamos probando replay con él. Y es obviamente una base de pruebas muy robusta y madura. Así que fue genial ver esos detalles allí.

Una de las preguntas que tenemos aquí es ¿cuánto tiempo lleva ejecutar todas las pruebas en CI? ¿Y se siente productivo para ti en tu día a día? Definitivamente se puede mejorar. Es una cuestión de qué es lo suficientemente rápido para la cantidad de presión que tienes. Así que si tienes un desarrollo tranquilo entonces puedes tomar un poco más de tiempo. Si tienes muchas tareas pequeñas en las que trabajar está bien esperar. Pero para responder a la pregunta creo que tarda unos 16 minutos más o menos para que un PR pase de simplemente iniciar la construcción de CI a ponerse en verde.

Vale, sí y sé que mencionaste hablar sobre esa experiencia de prueba del desarrollador también. Y hacer eso localmente. ¿Encuentras que los desarrolladores tienden a hacer eso antes de pasarlo a CI con bastante frecuencia? Creo que difiere entre un colaborador o un contribuyente que acaba de abrir su primer PR. Creo que es más probable que dependan del CI porque leer la documentación de contribución es mucho trabajo. Así que creo que eso también está bien. Sí, como dijiste siempre es un equilibrio ¿verdad? Entre la confianza y la seguridad que obtienes de la prueba y cuánto tiempo tardan en ejecutarse. Y cómo eso podría impactar potencialmente la experiencia del desarrollador versus la experiencia del usuario final.

Ahora mencionaste que hay algunas cosas que podrías haber hecho hasta ahora para mejorar ese tiempo de ejecución. ¿Puedes hablar un poco más sobre cuáles son? ¿Podrías aclarar la pregunta? Sí, lo siento. Así que mencionaste que hay cosas que podrías hacer para hacer que el tiempo de ejecución sea un poco más rápido. Pero que has trabajado en eso hasta ahora. ¿Qué has encontrado que ha mejorado ese tiempo de ejecución? Así que lo que realmente quiero hacer pero simplemente no he encontrado el tiempo para hacerlo todavía es invertir esa paralización de la que estaba hablando. De manera que efectivamente decimos que cada sandbox tiene su propio carril. Y así una cosa que no se siente como que está perdiendo mucho tiempo. Pero si tenemos como 40 sandboxes y uno tarda como medio minuto en completarse y el otro tarda cuatro. Bueno, la prueba de extremo a extremo para ese primero que sólo tardó como 30 segundos no se iniciará hasta que el otro haya terminado. Y así de nuevo no se siente como mucho tiempo pero siento que probablemente hay bastante tiempo en la mesa. No para obtener la marca de verificación verde final en el PR. Pero a menudo sólo estás esperando una cosa específica que podría ser mucho más rápida.

En lugar de esperar la verificación final. Sí, siempre es encontrar esos pequeños cuellos de botella en el camino que pueden ayudar mucho. Entonces mencionaste que obviamente Storybook es muy configurable y usas flags de características para eso. ¿Cómo prueba Storybook esos flags de características? Entonces, cuando configuramos esos sandboxes podemos sobrescribir parte de la configuración. Y forzar de alguna manera que el archivo de configuración main.ts de Storybook sea editado. Así que podemos poner eso en el objeto de plantilla. Lo que son esas modificaciones. Y así simplemente tenemos más plantillas que muestran el Storybook con cada modificación.

Muy bien, genial. Sí, veo muchas preguntas. Tenemos tiempo para quizás una o dos más. Pero empecemos con ¿cómo pruebas en móvil? No tenemos pruebas para móvil en este momento. Tenemos pruebas de Playwright en todos esos sandboxes. Y también tenemos pruebas de Chromatic en todos esos sandboxes. Pero no creo que ninguna de esas se pruebe actualmente en una vista de puerto móvil. Definitivamente no en un dispositivo real. No estoy seguro si vale la pena para nosotros desde una perspectiva de costos hacerlo. Porque Storybook se siente como una aplicación de escritorio para mucha gente. Y más como una referencia rápida en un móvil. Así que para nosotros simplemente no es una preocupación de alta prioridad.

Sí, esa iba a ser mi pregunta de seguimiento. ¿Con qué frecuencia ves a la gente usando Storybook en móvil? Y me imagino que probablemente no muy a menudo al menos todavía. Quiero decir que es un poco un problema de huevo y gallina. Donde si Storybook no funciona muy bien en un teléfono, la gente está menos inclinada a usarlo. Y luego estamos menos inclinados a hacerlo un producto muy agradable. Creo que deberíamos invertir el tiempo. Veremos en Storybook 8 que la interfaz de usuario móvil va a ser mucho mejor. Sí, y si alguien está usando Storybook en móvil supongo que asegúrate de que... ¡Estarán felices! Sí, avísale a Norbert y ve cómo todos pueden ayudar con eso. Así que genial. Bueno, creo que eso es todo el tiempo que tenemos. Pero si tienes alguna pregunta adicional para Norbert, de nuevo asegúrate de unirte a él en la sesión de preguntas y respuestas con el ponente. Y nos vemos allí y en la conferencia. Así que muchas gracias. Gracias.