Domina el Multiverso de Componentes

Rate this content
Bookmark

Estado de error, estado de carga, punto de quiebre incómodo, datos incorrectos, formato deficiente, soporte del navegador. Cada componente es una multitud de desafíos. ¿Cómo lo gestionas realmente? Desactiva la red, temporalmente. Inserta código incorrecto, solo por un minuto. Juega en el borde de tu pantalla. Manipula las fijaciones de la base de datos local. El desarrollo frontend es un multiverso donde dimensiones como el tiempo y la variación resultan en un número infinito de posibilidades de interfaz de usuario. En esta charla, utilizaremos Storybook para desarrollar, probar y documentar progresivamente nuestro trabajo y dominar el multiverso de nuestros componentes.

27 min
21 Jun, 2022

Video Summary and Transcription

Esta charla explora el impacto de las pruebas de interfaz de usuario en aplicaciones y la web, resaltando la necesidad de estrategias de pruebas integrales. Se discuten las complejidades del multiverso de la interfaz de usuario y los desafíos en la gestión de los estados de la interfaz de usuario. Se examina la idoneidad de diferentes estrategias de pruebas en el continuo de pruebas, junto con la importancia de abordar el peso de los desafíos de las pruebas de interfaz de usuario. Se enfatiza el papel de herramientas como Storybook y Chromatic en las pruebas automatizadas y la colaboración. En última instancia, la charla enfatiza el amor por la web y la necesidad de estrategias para gestionar el multiverso de la interfaz de usuario.

Available in English

1. Introducción a las pruebas de interfaz de usuario

Short description:

Esta es una charla sobre las pruebas de interfaz de usuario, su impacto en nuestras aplicaciones y en la web en general. Discutiremos la falta de herramientas, estrategias para desarrolladores frontend e ingenieros de UI, y la importancia de las pruebas para proteger las experiencias de los usuarios.

Esta es una charla sobre las pruebas de interfaz de usuario, un problema de herramientas que subestimamos críticamente y su impacto tanto en nuestras aplicaciones, en nuestra experiencia al construirlas y creo que en la web en general.

Ahora, quiero hablar sobre algunas herramientas que creo que faltan en nuestro conjunto actual de pruebas. Así que vamos a hablar sobre algunas herramientas, algunas estrategias que creo que deberíamos empezar a utilizar como desarrolladores frontend e ingenieros de UI, y espero responder a la pregunta que algún fanático me ha estado haciendo desde que subí a este escenario virtual, ¿cuándo este idiota va a quitar esta diapositiva? Todavía no.

Así que amo la web, y amo el buen software, y me he sentido muy decepcionado a medida que hemos visto que la web ha ido ocupando una parte cada vez más grande del desarrollo de software en general. Con la llegada de React Native y Electron, la web ha comenzado a moverse cada vez más lugares en el software en su conjunto, y ha comenzado a ofrecer una experiencia bastante deficiente en todos los aspectos. Ahora, egoístamente, quiero que la web sea mejor, porque la uso todo el tiempo. Amo la web, y quiero asegurarme de que tengamos las estrategias de pruebas necesarias para garantizar que protegemos las experiencias de los usuarios en cada paso del camino.

2. Introducción al Orador y al Trofeo de Pruebas

Short description:

Esta es una introducción general sobre quién soy, mis experiencias con React Podcasts, el equipo principal de React y mi trabajo en Chromatic. Tengo 12 años de experiencia en desarrollo web y me enfoco en la productividad del desarrollador, sistemas de diseño y arquitectura frontend. También hablaré sobre el trofeo de pruebas y cómo se relaciona con las estrategias de pruebas.

Ahora que hemos terminado con la introducción, finalmente podemos deshacernos de esta diapositiva. Entonces, ¿quién diablos soy yo? Este es el punto de la charla donde se supone que debo convencerte de que tengo mucha credibilidad, así que simplemente te daré una introducción general sobre quién soy y tú puedes decidir si me encuentras creíble. Confía en ti mismo.

Entonces, en primer lugar, soy Chan, Chantastic o Michael. Puedes llamarme como quieras, cualquiera está bien para mí. Solía presentar un programa llamado React Podcasts hasta que, desafortunadamente, me agoté. Fue mucho trabajo. Si alguna vez has hecho un podcast, sabes que es mucho trabajo, pero durante mi tiempo en React Podcasts tuve la oportunidad de hablar con algunos de los desarrolladores y personas más brillantes que he conocido en toda mi vida. Así que si estás interesado en eso y nunca has escuchado el programa antes, hay un gran catálogo, y si quieres escuchar a algunos de tus desarrolladores favoritos, está ahí para ti.

Ahora, durante mi fase de agotamiento, me enamoré del juego Destiny también. Así que si eres jugador de Destiny, contáctame y podemos hacer algunas incursiones o jugar en el Crucible juntos o algo así. Ahora, no todo fue diversión y juegos. Tuve la oportunidad de trabajar con el equipo principal de React en el Grupo de Trabajo de React, lo cual fue una experiencia realmente increíble, ya que ayudé a dar vida a React 18 en la comunidad y asegurarme de que todos supieran cómo hacer la transición de sus aplicaciones y aprovechar algunas de las nuevas características. También comencé uno de mis espacios en línea favoritos para desarrolladores de React creativos, curiosos y amables. Está en discord.gg. Tenemos muchas personas allí, y te invito a unirte si te gusta pasar tiempo en discords. Lo más relevante para esta charla es que tengo unos 12 años de experiencia en productividad del desarrollador, sistemas de diseño y arquitectura frontend. Ahí es donde he adquirido experiencia en el desarrollo web y de donde provienen muchas de las experiencias que compartiré hoy. Ahora trabajo en Chromatic, y hablaremos sobre ese servicio a medida que avancemos en esta charla.

Nuestro objetivo allí es mejorar la experiencia de usuario en la web. Si has estado en el espacio de React y JavaScript durante un tiempo, probablemente hayas oído hablar del trofeo de pruebas. Permíteme mostrarlo en pantalla ahora mismo. Este es el trofeo de pruebas, visualizado por Kent C. Dodds. Se basa en un tweet de Guillermo Rauch que dice: escribe pruebas, no demasiadas, principalmente de integración. Curiosamente, se basa en un formato de resumen que Michael Pollan utilizó para resumir El dilema del omnívoro, que es un libro muy bueno y un formato de resumen muy bueno para muchas cosas como las pruebas. De todos modos, de ahí viene eso. Este es el trofeo de pruebas. Para esta charla, quiero ponerlo de lado y hablar de él como un continuo y colocar algunas de nuestras estrategias de pruebas en la parte superior. Cuando miramos esta visualización, tenemos algunas cosas.

3. Tipos de Pruebas y el Continuo de Pruebas de UI

Short description:

Tenemos diferentes tipos de pruebas como Estáticas, Unitarias, Integración y de Extremo a Extremo. TypeScript domina en el ámbito Estático, mientras que Cypress es popular para las pruebas de Extremo a Extremo. Jest es una herramienta bien integrada para pruebas unitarias e integración en el espacio de React. Sin embargo, parece haber cierta complicación en esta distribución, lo que puede indicar la necesidad de un concepto como las pruebas visuales. Esta charla se centrará en las pruebas visuales y el continuo de pruebas de UI.

Tenemos pruebas Estáticas, Unitarias, Integración y de Extremo a Extremo. Estos son todos los tipos de pruebas que podemos escribir para respaldar una aplicación. En el ámbito de las pruebas Estáticas, TypeScript domina en este momento, así que simplemente voy a colocar TypeScript allí. En las pruebas de Extremo a Extremo, escuchamos mucho sobre Cypress. Definitivamente tienen la mayor atención. En el medio, tenemos Jest, u otras bibliotecas similares, que abarcan las pruebas unitarias y de integración. Pongo a Jest aquí porque creo que está muy bien integrado con JSDOM y la biblioteca de Testing, que son herramientas muy populares en el espacio de React específicamente. Aquí es donde se supone que debemos escribir la mayoría de nuestras pruebas. Hay un poco de complicación aquí. Tenemos dos categorías y tres herramientas aquí. Y cada vez que veo una distribución como esta, donde no está particularmente claro qué está sucediendo, me pregunto si no tenemos a dos niños en un abrigo, si no hay alguna idea que es un poco confusa y que aún no hemos descubierto completamente. Ahora, si tuviera que adivinar, diría que el concepto que realmente no hemos dominado es el de las pruebas visuales. Así que de eso se trata esto, pruebas visuales. Hablaré mucho sobre esta diapositiva y la llamaré el continuo de pruebas de UI. Así que si me refiero a eso, me estoy refiriendo a este continuo del que estoy hablando.

4. UI Multiverse and Complexity

Short description:

Hablemos sobre el multiverso de la interfaz de usuario y las complejidades que presenta en las pruebas de integración visual. Diseñamos vistas web con un estado ideal, pero también debemos considerar los estados de error y carga, los puntos de interrupción, la compatibilidad con navegadores, las habilidades del usuario y las capacidades del dispositivo. Si bien no tengo soluciones para todos estos desafíos, es crucial abordarlos para aplicaciones exitosas. La autorización y la lógica en las páginas también agregan complejidad, especialmente al considerar la lógica combinatoria en los estados de los componentes.

Hablemos sobre el multiverso de la interfaz de usuario. Este es el problema al que veo que los desarrolladores front-end se enfrentan en el espacio de las pruebas de integración visual. A veces también me refiero a esto como las 10 dimensiones aproximadas de la interfaz de usuario web, o si me siento especialmente ingenioso, las 35,000 estados perfectos. Vamos a profundizar en eso.

Entonces, cada vez que designamos una vista web, pensamos en ella en su estado ideal. Esta vista perfecta, tal vez la hayamos dibujado en un papel o la hayamos diseñado, pero este estado ideal perfecto para esta vista. Ahora todos sabemos que la vida no es perfecta y tendremos que complementar eso con estados de error y carga. Tenemos una tercera dimensión, que son las complicaciones de los estados de carga y error, para las cuales podríamos tener vistas de esqueleto dedicadas para una página específica. Manejamos diferentes errores de diferentes maneras porque un error 404 es significativamente diferente de un error 500, y así sucesivamente. Ahora tenemos una dimensión adicional, incluso para nuestras páginas exitosas, que son los puntos de interrupción. Entonces no creamos una sola vista. Por lo general, para la web, tenemos varios puntos de interrupción para un sitio web receptivo. Es bastante estándar en estos días. Por lo general, utilizo alrededor de seis, pero para este caso, lo mantendré pequeño, en cuatro. Ahora eso se multiplica nuevamente cuando comenzamos a pensar en los navegadores y cómo nuestras vistas realmente interactúan con el navegador. En este momento, generalmente tenemos tres o cuatro motores a los que la mayoría de las aplicaciones tienen que apuntar, así que pondré cuatro allí. Ahora tomamos eso y lo multiplicamos nuevamente por las habilidades del usuario. Esto podría ser navegación por teclado o navegación por mouse o, ya sabes, tener el sitio leído a través de un lector de pantalla. También tenemos las capacidades del dispositivo. Esto es un poco diferente a las capacidades del usuario porque un dispositivo puede tener pantalla táctil o teclado o mouse, o se puede hablar con él. Y todas esas son formas en las que podemos interactuar con el contenido. Ahora no tengo soluciones para esta parte en este momento, así que no agregaré diapositivas a nuestro universo en expansión de páginas. Así que pasamos por alto eso.

Ahora la mayoría de las aplicaciones en estos días, al menos aquellas que son servicios, tendrán algún nivel de autorización también. Y he duplicado esto varias veces para mostrar diferentes tipos de autorización. Pero además de esto, puedes pensar en la lógica en tus páginas. Cualquier página que tenga, ya sabes, un booleano que cambie la vista, pero lo que no he representado aquí es la lógica combinatoria donde tienes dos propiedades que generan un tercer o cuarto o quinto estado posible. Sé que podrías estar pensando, como, wow, acabas de agregar un montón de páginas. Pero en realidad, este es un número bastante mínimo si consideramos lo complicados que se vuelven los componentes. Y hablaremos más sobre eso en un segundo.

5. Complexity of UI States and Testing

Short description:

El soporte de múltiples idiomas y diferentes frameworks en un sistema de diseño o biblioteca de componentes puede llevar a un crecimiento exponencial en el número de estados ideales por componente. Por ejemplo, al considerar Vue, motores de navegadores, capacidades del dispositivo, habilidades del usuario, tipos de autorización, frameworks, temas, modos de contraste y aplicaciones, el número de estados ideales puede alcanzar un incomprensible 34,560 por componente. Esta complejidad resalta los desafíos que se enfrentan en la gestión de los estados de la interfaz de usuario y la necesidad de estrategias de prueba y diseño integrales.

Ahora, si se admite múltiples idiomas, entonces realmente multiplicará toda esta pila de vistas perfectas por cada idioma que se admita. Esto es particularmente importante si se admite el texto de derecha a izquierda, donde la página se volteará efectivamente para admitir el idioma adecuado. Así que estamos hablando de números bastante grandes aquí.

Ahora, si trabajas en el espacio de los sistemas de diseño o bibliotecas de componentes, sabes que también existe esta dimensión de organización, donde podrías tener todo el mundo bajo tu control. Pero tu galaxia de componentes está bajo una presión increíble por las partes de tu organización que adoptaron, tanto de manera intencional como accidental o no intencionalmente. Y cómo algunos de esos equipos o partes de tu organización incluso pueden tener la autonomía para elegir la capa de visualización que utilizan. Tal vez no estén utilizando React. Sé que en mi caso, estábamos utilizando Rails y React. Pero algunos de ustedes podrían tener partes de su aplicación en Backbone o Ember o incluso Vue. Y construir una biblioteca de componentes que sea integral realmente implica admitir todas esas bibliotecas. Así que realmente no puedo asumir los desafíos específicos que enfrenta tu sistema de diseño y biblioteca de componentes. Sin embargo, puedo contarte un poco sobre el mío y hacer los cálculos sobre los problemas que he estado resolviendo en los últimos años, y multiplicar eso.

Estas son las apuestas básicas. Entonces, para cada componente Vue, tendríamos seis puertos Vue, tres motores de navegadores, tres capacidades del dispositivo y cuatro habilidades del usuario. Eso nos lleva a 216 estados perfectos. Bueno, hay un poco más. Tendríamos al menos dos tipos de autorización. Por lo general, eran más como cuatro o cinco. No admitíamos el texto de derecha a izquierda, porque somos una empresa con sede en Estados Unidos, pero sí admitíamos dos frameworks. Eso nos lleva a un total de 864 estados perfectos. Pero no termina ahí, porque ni siquiera hemos hablado sobre el estilo. Así que admitiríamos dos temas, dos modos de contraste y todos ellos podrían multiplicarse por las 10 aplicaciones, que tendrían un tema discreto para cada aplicación. Totalmente loco. Pero en realidad nos lleva a un incomprensible 34,560 estados ideales por componente. Ahora, esto ni siquiera maneja todas nuestras posibilidades de autorización y definitivamente no maneja ninguna lógica combinatoria de props. Absolutamente asombroso. Ahora quiero hablar sobre la parte lógica de esto por un segundo, para mostrarte cuánto pueden crecer exponencialmente los estados de la interfaz de usuario. Este fue un artículo de blog que mostraba un botón que se estaba construyendo y todas las posibles variantes, ni siquiera para modos de contraste adicionales, sino solo para dos temas, claro y oscuro. Y todas las formas en que se podía representar un botón en esta aplicación. Y tenían 1134 variantes.

6. The Weight of UI Testing Challenge

Short description:

A menudo ignoramos el peso del desafío en las pruebas de interfaz de usuario y nos enfocamos en nuestras tareas inmediatas. Sin embargo, este enfoque puede llevar a problemas y depender de la retroalimentación de QA o de los usuarios. Es importante abordar este problema y considerar mejores estrategias de prueba.

Solo para este componente. Ahora, creo que tenemos un problema realmente grande. Y muchas veces no nos permitimos sentir el peso de este desafío. Y incluso en este momento podrías estar retorciéndote porque la primera vez que realmente pensaste en todo esto fue ahora mismo. Y muchas veces seguimos adelante simplemente no pensando en esto. Solo nos enfocamos en nuestra tarea actual y dejamos que QA se encargue de informarnos los errores, o simplemente hacemos un desarrollo impulsado por Twitter donde lo lanzamos sabiendo que puede haber cosas malas y la gente nos dirá dónde están.

7. Suitability of Testing Strategies

Short description:

Uno de los mayores desafíos en la creación de pruebas es la adecuación de las estrategias de prueba en todo el continuum. Las pruebas estáticas son excelentes para las interfaces, mientras que las pruebas unitarias son ideales para probar la implementación del código. Las pruebas de extremo a extremo son perfectas para probar flujos, y las pruebas de integración se centran en aspectos no visuales. Las pruebas visuales ocurren cuando nuestro código se representa en un navegador.

Ahora creo que uno de los mayores desafíos a los que nos enfrentamos está en la creación de pruebas. Así que quiero hablar un poco sobre la adecuación de las estrategias de prueba en este continuum. Entonces, en primer lugar, las pruebas estáticas son realmente excelentes para las interfaces. Por lo tanto, los lenguajes son excelentes para probar interfaces. Las pruebas unitarias son excelentes para probar la implementación de una unidad de código. Las pruebas de extremo a extremo son realmente excelentes para los flujos, registro, CRUD, actualización de facturación, etc. Y en esta parte de integración, tenemos coordinación. Idealmente, esta es la coordinación de componentes o código. Están separados del stack completo, que es lo que hacen las pruebas de extremo a extremo. Ahora, la integración es principalmente para, voy a limitarlo a cosas no visuales. Y luego lo visual será ese punto de integración donde nuestro código realmente se representa dentro de un navegador.

8. Suitabilidad de las Estrategias de Prueba según el Rol

Short description:

Ahora hablemos sobre la idoneidad de estas estrategias de prueba según el rol. En la mayoría de los casos, los ingenieros se encargan de las pruebas estáticas, unitarias e de integración, mientras que el equipo de control de calidad se enfoca en las pruebas de extremo a extremo. Sin embargo, a menudo se descuida la prueba exhaustiva del aspecto visual. Para mejorar la cobertura de las pruebas, necesitamos herramientas que se alineen con la creación de interfaces de usuario y sean más declarativas. Storybook, Chromatic y la integración continua ofrecen un enfoque declarativo para las pruebas de interfaz de usuario. Storybook sirve como puente entre el diseño y el desarrollo, ofreciendo componentes vivos con documentación, interacción y herramientas como vistas, medidas y pruebas de accesibilidad. También genera documentación automáticamente y proporciona controles para las pruebas de componentes. Los controles interactivos de Storybook mejoran la comunicación y la comprensión interfuncional en torno a React.

Ahora hablemos sobre la idoneidad de estas estrategias de prueba según el rol. En la mayoría de los casos, los ingenieros se encargan de las pruebas estáticas, unitarias y de integración. Esto depende de la organización, obviamente. Por otro lado, el equipo de control de calidad suele dominar las pruebas de extremo a extremo. Sin embargo, en el aspecto visual, a menudo nos encontramos con pruebas insuficientes y esperamos que se vea bien en nuestra máquina y que también se vea bien para los demás. Creo que si queremos tener una mejor cobertura de pruebas en este aspecto, necesitamos herramientas que funcionen de la misma manera que la creación de interfaces de usuario y que sean más declarativas.

Por un lado, Jest tiene pruebas de instantáneas y Cypress tiene algunas pruebas de componentes, pero tienen desafíos en cuanto a la forma en que se sienten al crear pruebas visuales. Entonces, ¿cómo producimos pruebas en esta brecha de integración visual? Creo que lo hacemos de forma automática. Ahora quiero hablar sobre algunas cosas. Llamo a esto las pruebas de interfaz de usuario declarativas. Estas son Storybook, Chromatic y la integración continua. Quiero agradecer a mi compañero de trabajo, Varun, por preparar estas diapositivas a partir de una presentación que comparte con nuestros clientes.

Comencemos con Storybook. Cuando pienso en Storybook, realmente se sitúa en la brecha entre el diseño y el desarrollo. Tenemos esta idea de desarrollo basado en componentes donde realmente aprovechamos los componentes y el hecho de que están aislados del resto del entorno de componentes. Nos inspiramos en herramientas como Figma, que tienen estas ideas de hojas de pegatinas para los componentes, y llevamos eso al lado del código. Creamos un entorno que está disponible para cualquier persona con acceso, de la forma que deseen compartirlo, que realmente representa visualmente los componentes y combina eso con la documentación y la capacidad de interactuar con ellos. Estos son componentes vivos. Traemos muchas herramientas con nosotros que ahora podemos compartir en este entorno de desarrollo front-end. Tenemos vistas, que podemos codificar con las vistas que admitimos en nuestra aplicación. Podemos usar herramientas como medidas en lugar de tener que abrir un inspector y medir todo esto, simplemente podemos tenerlo y asegurarnos de que todos nuestros espacios estén correctos y el tamaño sea el adecuado entre los elementos. Podemos resaltar cosas para depurar las interfaces de usuario, todo dentro de este entorno de desarrollo front-end. Además, tenemos pruebas de accesibilidad incorporadas. Esto es algo que normalmente tienes que instalar en tu navegador o a través de alguna herramienta de línea de comandos. Podemos llevar eso a nuestro entorno de desarrollo front-end y asegurarnos de que todos tengan la misma información sobre las auditorías de accesibilidad y si pueden admitir el espectro completo de usuarios en nuestras aplicaciones. Y para mí, sé que hago muchos console.log.wats, o console.log.wats, y podemos tener una amplia variedad de formas de probar nuestros componentes utilizando controles, arquetipos, etc. Tenemos documentación generada automáticamente dentro de Storybook que te permite, simplemente escribiendo un componente, tener documentación que muestre la interfaz de ese componente y las props disponibles para ti. Y tenemos controles, por lo que una vez que se identifican esas interfaces, ahora te ofrecemos un espacio de pruebas donde cualquier persona, independientemente de su capacidad para codificar el componente, puede experimentar con algunas de las props y asegurarse de que lo que están intentando lograr, en este caso el botón, sea posible con la interfaz disponible. Ahora hay una cita, tuve la oportunidad de hablar con Ryan Bayhan en Shopify, y ellos se centran mucho en el poder interfuncional de sus equipos, en la capacidad de los equipos de enfocarse en su experiencia y tener empatía por las otras disciplinas también. Él dice que los controles interactivos de Storybook mejoran la comprensión interfuncional y la comunicación en torno a React, y simplemente me encanta eso.

9. Pruebas Automatizadas con Chromatic

Short description:

Ahora Chromatic es la pieza de esto donde realmente podemos obtener pruebas automatizadas. Storybook es realmente bueno para resolver el aspecto organizativo, pero Chromatic es donde se convierte en una herramienta de prueba. Chromatic se integra con tu canal de integración continua (CI) para realizar pruebas visuales en comparación con las pruebas previamente aceptadas. Cubre tanto vistas estáticas como interactivas, incluyendo modales. Admite múltiples navegadores y tamaños de pantalla. Brad Frost enfatiza la importancia de escribir historias para la documentación, pruebas y entornos de pruebas. La colaboración con Redwood permite una mayor integración de las pruebas de Storybook utilizando Testing Library, MSW y Prisma, brindando características como la generación de estados.

Ahora Chromatic es la pieza de esto donde realmente podemos obtener algunas pruebas automatizadas. Storybook es realmente bueno para resolver el aspecto organizativo, pero Chromatic es donde se convierte en una herramienta de prueba. Cuando integras Chromatic con tu canal de integración continua (CI), puedes realizar pruebas visuales en comparación con las pruebas visuales previamente aceptadas. Así que cuando cargas tu primera prueba visual, la defines como línea base, y luego cada solicitud de extracción después de eso se comparará para asegurarse de que no se hayan introducido cambios inesperados. Esto no solo está disponible para vistas estáticas, sino que también podemos hacerlo para elementos interactivos. Por ejemplo, podemos tener un botón que abre un modal y luego podemos ejecutar nuestras pruebas para asegurarnos de que se haya hecho clic y se haya abierto correctamente. Muy interesante. También podemos hacer esto en todos los navegadores que admitimos y en todos los tamaños de pantalla. Y todo esto está integrado en tu canal de integración continua (CI), por lo que al enviar una solicitud de extracción, ahora puedes ejecutar tu ejército de robots en todas tus pruebas visuales y asegurarte de que nada haya cambiado. Y así, Brad Frost, quien es una figura destacada en el espacio del frontend, lo expresó de manera muy elocuente. Él dice que las pruebas históricamente han sido difíciles para nosotros porque ha sido como una imagen en tu mente, un modal, e imagina hacer clic en un botón que abre ese modal. Pero al escribir una historia, obtienes la documentación para el componente, las pruebas y un entorno de pruebas, todo de forma gratuita. Ahora, también he estado muy emocionado de trabajar con equipos como Redwood para integrar aún más las pruebas de Storybook utilizando Testing Library, MSW y Prisma en el marco y obtener cosas realmente geniales con características como los generadores de Redwood, que simplemente generan todos estos diferentes estados de éxito, inicio de sesión, error y carga de forma automática. Muy interesante.

10. El Amor por la Web y el Multiverso de la Interfaz de Usuario

Short description:

Amamos la web porque nos permite creer en todo, en todas partes, al mismo tiempo. A pesar de sus fallas, la web abierta es la única plataforma que realmente cumple esta promesa. Crear y controlar estos universos es divertido, pero necesitamos estrategias para gestionarlos y mantener el multiverso de la interfaz de usuario bajo control.

Entonces hablamos de storybook, chromatic, pruebas visuales, ¿por qué debería importarte? Bueno, creo que estamos igualmente maldecidos, y eso es porque amamos la web. La web es increíble. Creemos en todo, en todas partes, al mismo tiempo, ahora y para siempre, accesible para todos. Y a pesar de todas sus fallas, ninguna plataforma excepto la web abierta realmente cumple esa promesa. Y si soy completamente honesto, hay algo divertido en crear estos mundos, estos universos que controlo completamente. Y cuando se resisten, tengo que aprender nuevas estrategias para volver a controlarlos nuevamente. Y mantener este universo, este multiverso de la interfaz de usuario que hemos creado bajo control. Desafortunadamente, deja de ser divertido cuando las cosas se salen de control. Y tendemos a agotarnos de manera interesante, desafortunadamente, cuando queremos implementar nuevas características, pero cada vez que implementamos algo, llegan cien nuevos informes de errores o diez personas se quejan de lo que hemos hecho. Y nos volvemos tímidos acerca de lo que queremos lanzar al mundo. Así que comenzamos a decir que no a nuevas ideas, características y bibliotecas porque tememos que se rompan. Nuestros productos comienzan a languidecer y nuestros equipos comienzan a irritarse. E inevitablemente, nos convertimos en estos villanos retorcidos que juramos nunca ser cuando éramos ambiciosos y creíamos que todo era posible. Simplemente nos sentamos y disfrutamos del hecho de que realmente no hay nada que podamos hacer que tenga éxito. Pero quiero que la web sea grandiosa. Quiero que mis aplicaciones sean grandiosas y quiero que tus aplicaciones sean grandiosas. Especialmente tus aplicaciones, si soy cliente de tus aplicaciones. Ahora, creo que hasta este punto, no hemos tenido las herramientas de frontend que realmente representen la forma en que trabajamos, la forma en que trabajamos en un espacio visual, uno complicado por múltiples motores de renderizado y múltiples bibliotecas. Y hay una gran discrepancia de impedancia entre la forma declarativa en que escribimos código y la forma imperativa en que se espera que escribamos pruebas. Antes de los componentes, realmente nunca tuvimos las herramientas adecuadas para manejar la integración con nuestro código y los navegadores, y para escribir pruebas de una manera declarativa que no requiera la pila completa como lo hace una prueba de extremo a extremo. Entonces, las pruebas visuales son una categoría completa de pruebas de integración basadas en el navegador que estamos apenas comenzando a explorar. Y estas son las herramientas que uso, amo y recomiendo, pero realmente espero que comiences a explorar este espacio de pruebas de integración visual en tus aplicaciones y lo hagas de tal manera que se integre con las herramientas que ya estamos utilizando en este espacio de integración. Ahora, nuevamente, la encapsulación, el aislamiento de un componente realmente nos ha permitido hacer cosas que nunca antes habíamos hecho e integrarnos con el navegador de una manera que no requiere la pila completa. Y sé que he dicho eso un par de veces, pero creo que es algo tan importante de recordar, que las pruebas visuales son una prueba de integración con el navegador, pero sin la pila completa. Ahora, una de mis citas favoritas es de Sandy Matt, un desarrollador héroe mío, y dicen, prueba el muro a tus espaldas. Ahora, quiero que tengas la seguridad de que nunca romperás la interfaz de usuario para ningún usuario nunca más, que cada decisión que hayas codificado para cada vista, para cada punto de interrupción y tipo de usuario esté defendida, contenida y controlada. Así que puedes avanzar con confianza hacia el futuro. Tenemos una gran tarea por delante, pero armados con las herramientas adecuadas y los paradigmas de pruebas, espero con ansias el futuro de la web, controla tu multiverso de la interfaz de usuario y mejoremos la experiencia de usuario de la web juntos. Soy ChanTastic, puedes encontrarme en chan.dev, en chantastic, discord.gg/lunchdev. Y si estás interesado en storybook, puedes visitarnos en storybook.js.org, en storybookjs y discord.gg/storybook. Muchas gracias por escuchar. Espero verte en línea.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Summit 2022React Summit 2022
147 min
Hands-on with AG Grid's React Data Grid
WorkshopFree
Get started with AG Grid React Data Grid with a hands-on tutorial from the core team that will take you through the steps of creating your first grid, including how to configure the grid with simple properties and custom components. AG Grid community edition is completely free to use in commercial applications, so you'll learn a powerful tool that you can immediately add to your projects. You'll also discover how to load data into the grid and different ways to add custom rendering to the grid. By the end of the workshop, you will have created an AG Grid React Data Grid and customized with functional React components.- Getting started and installing AG Grid- Configuring sorting, filtering, pagination- Loading data into the grid- The grid API- Using hooks and functional components with AG Grid- Capabilities of the free community edition of AG Grid- Customizing the grid with React Components