Noticias

Cómo implementamos la caja de demostración interactiva en vivo

El equipo de Vanilla recientemente pasó dos semanas corriendo para crear un prototipo de una caja de demostración en vivo interactiva. Nuestra tarea es llegar a una prueba de concepto para demostrar dinámicamente cada variante de nuestro ejemplo. Algunos desarrolladores invitados pudieron unirse a nosotros, lo que significó que cuatro de nosotros pudimos dedicar dos semanas de iteración al proyecto.

Cómo funciona actualmente

Actualmente, cada componente Vanilla tiene su propio página de documentación, y cada variante del componente existe bajo su propio encabezado. Algunos JavaScript hacen su magia tomando el archivo de muestra HTML correcto correspondiente e inyectándolo debajo del encabezado. etc:

Aunque la estructura actual funciona bien, las páginas de documentación de los componentes pueden ser largas con mucho texto y desplazamiento. Queríamos buscar un enfoque diferente… ¡aquí viene la caja de demostración en vivo!

como queremos que funcione

En lugar de mostrar cada ejemplo uno por uno, nos gustaría tener un cuadro de demostración interactivo en vivo para cada variante.

Diferenciamos variantes definiendo casos de uso. Si el caso de uso es el mismo, pertenece a la misma variante. Si es diferente, pertenece a una nueva variante. Se solicitaron las siguientes características:

  • Opciones desplegables para cambiar tipo, tema o estilo
  • Un botón de opción o interruptor para activar o desactivar la modificación
  • Ventana de visualización que muestra la combinación correcta de las características de los componentes
  • Ver la variante correcta del código que se muestra debajo de la ventana
  • El ejemplo y el código en la ventana deben actualizarse dinámicamente para mostrar el ejemplo correcto cuando se cambia la entrada

Feliz de tener:

  • Un enlace para abrir Codepen e inyectar el código correcto
  • Botón de pantalla completa para abrir el ejemplo a pantalla completa en otra ventana
  • Código escalable que funciona con múltiples componentes, no solo con notificaciones

planificación preliminar

Comenzamos con una reunión de lanzamiento inicial con preguntas. Nuestro equipo de diseño comparte los archivos Zeplin y contienen pautas para demostrar el aspecto.

Decidimos que dado que es un componente reutilizable que se actualiza después de la interacción del usuario, React puede manejar esto bien. Primero, tenemos algunas preguntas para pensar y planificar:

  • ¿Cómo proporcionaremos datos para las opciones del menú desplegable, p. escribe tipo de notificación texto ¿Esperar el contenido?

Un archivo JSON podría ser una buena opción. Actualmente solo tenemos el archivo de notificación.html, también podríamos tener un archivo de notificación.json con todas las características y variaciones de cada ejemplo para completar las opciones del cuadro de demostración.

  • ¿Cómo sabe la página de muestra de notificación.html qué variante de la muestra representar?

Pensamos que pasar parámetros en la URL funcionaría bien ya que el archivo admite la representación de plantillas Jinja. A continuación, el código HTML de muestra se puede representar de forma condicional en función de los parámetros de consulta.

  • ¿Es posible hacer una caja de demostración para cada variante de componente?

Esta es la pregunta del millón. No estamos seguros en este momento ya que cada componente es muy diferente. ¿Podemos tener una estructura de interfaz de usuario que funcione para todo? ¡Creo que lo averiguaremos!

implementar

Primero, agregamos un json que contiene los valores de configuración utilizados para completar el cuadro de demostración Para el modo de notificación. La estructura incluye el valor legible por humanos de la etiqueta y el valor de consulta adjunto a la URL.

Luego, editamos la plantilla para incluir la representación condicional, por lo que el flujo se parece un poco a esto:

  1. El usuario selecciona una opción del cuadro de presentación
  2. Luego agregue el valor de esa opción a la URL
  3. Archivo de plantilla de ejemplo para leer el valor de un parámetro de consulta
  4. En función de este valor, represente una versión diferente del ejemplo.

Aquí está todo el archivo toast.html Si está interesado en comprender la estructura del archivo.

sensible Estoy trabajando en la construcción de componentes React. Construir algo desde cero fue divertido y pudimos pasar la mayor parte de nuestro tiempo emparejados. Después de algunas batallas de TypeScript (que todos pasamos), pudimos construir algo similar al diseño de Zeplin que obtuvimos.

Código de representación condicional

También necesitamos incluir el código necesario para cada variante. Para hacer esto, necesitamos construir un componente React que tome el código correcto basado en la configuración definida por el usuario y luego lo muestre. Al igual que con la vista de componentes representados, podemos pasar parámetros de consulta basados ​​en configuraciones definidas por el usuario al obtener el código. Gracias a la magia de las capacidades de representación condicional de Jinja, nuestros componentes front-end pueden simplemente solicitar una URL y devolver HTML completo, JavaScript y cualquier otro CSS.

refactorizar

Perfecto, tenemos el componente de notificación funcionando. ¡Trabajo hecho! Lamentablemente no. Luego tenemos que hacer que el componente React sea menos específico para poder aceptar archivos json de cualquier estructura.nosotros usamos componente de fragmento de código como nuestro próximo ejemplo.

Fue entonces cuando nos dimos cuenta de que no sería tan simple como pensamos al principio. El componente de fragmento de código es muy diferente del patrón de notificación. Hay diferentes combinaciones de nombres de clase y variantes, que se pueden usar solas o con otras combinaciones. Sin embargo, finalmente llegamos allí.finalmente encontramos uno La estructura json del componente de fragmento de códigocon uno Plantilla de fragmento de código refactorizado Funciona con nuestro código de caja de demostración refactorizado. ¡Hurra!

Clásico

Hicimos una retrospectiva después del sprint para obtener comentarios de los desarrolladores que trabajaban en el componente y ver cómo funcionaba el proceso.

Los comentarios fueron en su mayoría positivos y muy agradables de escuchar. A los desarrolladores les encanta asociarse, trabajar en diferentes trabajos, poder construir algo desde cero y poder demostrar una caja de demostración funcional al resto del equipo al final de dos semanas. ¡resultado! Incluso logramos incluir algunos «agradables de tener».

Nuestros comentarios incluyeron comentarios de que el emparejamiento puede ser agotador, especialmente sin descansos frecuentes. Un desarrollador pensó que el emparejamiento podría estar más organizado. De esto surge una acción, tratando de garantizar que el siguiente sprint tenga un emparejamiento y un tiempo de enfoque más formales y dedicados.

Tenemos algunas preocupaciones sobre la escalabilidad de esta interfaz de usuario. Después de lidiar con el componente de fragmento de código y darnos cuenta de la complejidad de compilar json, planteamos este problema con nuestro equipo de UX y actualmente estamos trabajando en una hoja de cálculo que revisará cada uno de los cuadros de demostración en vivo antes de que se clasifiquen las funciones de implementación.

En conclusión

Con todo, el sprint fue un éxito. Teníamos una prueba de concepto funcional que podía usarse para tomar decisiones finales de diseño y, lo que es más importante, aprendimos mucho y expusimos posibles obstáculos futuros.

LEER  ¿Qué? ¡Los Snaps de Steam están evolucionando!

Publicaciones relacionadas

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Botón volver arriba