Compartir es Cuidar: Reutilizar Visualización de Datos Web en React Native

Hola a todos. Soy Cristal, y soy una desarrolladora de personal en Shopify, más específicamente en el equipo de Insights, donde trabajamos en la creación de experiencias de visualización de datos. Hoy me gustaría compartir con ustedes nuestro viaje sobre cómo reutilizar las cosas que habíamos construido originalmente para la web para acelerar nuestro proceso de desarrollo con React Native.

Pero antes de sumergirnos en los detalles de implementación, probablemente deberíamos hablar sobre qué es PolarisViz, qué es esta biblioteca que creamos y planeamos lanzar como código abierto pronto. Y creo que la mejor manera de entender qué es PolarisViz es hablar sobre cómo se veía la visualización de datos en Shopify antes de tenerla. Así que antes, cada equipo era responsable de tomar sus propias decisiones en cuanto a qué herramienta usar o implementar algo desde cero. Esto llevó, por supuesto, a muchas inconsistencias, como se puede ver en estos dos gráficos que solían estar en el panel de administración. Y como pueden ver, uno de ellos tiene líneas de cuadrícula verticales y el otro no. Uno de ellos tiene líneas gruesas y el otro líneas delgadas. También tienen estilos diferentes para las líneas discontinuas que representan períodos de comparación. Uno de ellos usa cuadrados en la leyenda, el otro usa líneas en la leyenda. Y por último, uno de ellos tiene un eje X visible y el otro no. Sin embargo, estas inconsistencias no eran solo visuales, ya que cada uno tenía una implementación completamente diferente. Uno tenía soporte de impresión y el otro no. Uno era accesible para la navegación por teclado y el otro no lo era.

Mi favorito fue el gráfico de líneas de área con etiqueta de ventas a lo largo del tiempo. Quiero decir, si estuviera usando un lector de pantalla, no estoy seguro de que estaría contento con esta descripción porque en realidad no me ayuda a entender cómo van mis ventas.

Incluso cuando los gráficos eran solo instancias del mismo componente utilizando nuestros componentes internos que construimos, porque la API se veía algo así, como pueden ver, tenemos que pasar muchas props diferentes para que un gráfico tenga un aspecto específico y estas props tenían que repetirse para cada instancia del gráfico. Por lo tanto, era muy fácil para un desarrollador, por ejemplo, decir que el margen horizontal era 30 en lugar de 20 y ahí lo tienes, los gráficos ahora no se ven iguales.

Entonces, para resolver todos esos problemas, comenzamos a crear una colección de componentes de React que no solo tenían los mismos estilos visuales, sino que también se enfocaban en cosas que son muy importantes para nosotros. Como el diseño de movimiento, por ejemplo, porque creemos que a través de la animación podemos guiar la vista de un usuario y ayudarlo a comprender mejor el conjunto de datos, reduciendo la carga cognitiva. También nos enfocamos en la accesibilidad. Por ejemplo, al permitir que nuestros usuarios resalten una serie de datos específica en un gráfico, les ayudamos a aquellos que tienen deficiencias en la visión del color a hacer la conexión en términos de lo que esa serie de barras específica significa, sin tener que depender de los colores. También nos enfocamos en implementar la accesibilidad para lectores de pantalla. Este gráfico de líneas, por ejemplo, utilizamos filas de área en el marcado SVG para que un lector de pantalla pueda acceder a los puntos de datos que alimentan el gráfico de líneas e interactuar con él como si fuera una etiqueta. Por lo tanto, pueden ver que aquí estoy navegando en la fila del 2 de abril, y podemos navegar por las diferentes celdas a través de filas y columnas como lo haríamos si estuviéramos interactuando con una tabla HTML simple.

Y, por supuesto, Shopify tiene muchas marcas diferentes que utilizan estilos visuales diferentes. Como mencioné antes, planeamos lanzar la biblioteca como código abierto pronto, por lo que queríamos que la biblioteca fuera lo suficientemente flexible como para que las personas pudieran implementar su propia identidad visual en los gráficos, pero también queríamos mantener las cosas consistentes para quienes usaran nuestros gráficos. Por lo tanto, no es necesario pasar props a cada uno de estos componentes. Tenemos un lugar centralizado donde puedes definir el tema que deseas usar y se aplica automáticamente a todas las instancias de un gráfico en tu aplicación. Hablaremos un poco más para explorar más a fondo cómo funciona eso un poco más adelante.

Entonces, en enero de 2020, Shopify anunció que React Native era el futuro. Y desde entonces nos hemos centrado en escribir nuestras aplicaciones móviles con React Native y todas nuestras nuevas funciones con React Native. Para nuestro equipo, esta fue una oportunidad muy buena para aprovechar las cosas que habíamos aprendido mientras construíamos Polaris Viz para la web y entender cómo podríamos crear experiencias muy buenas para dispositivos móviles con React Native. Lo primero que pensamos fue, bueno, podemos simplemente crear una nueva biblioteca, llamarla Polaris Viz Native, y eso es todo. Sin embargo, eso fue mucho trabajo. Habíamos estado trabajando en Polaris Viz durante algunos años en ese momento para llevar la biblioteca a donde estaba, y comenzar desde cero no podíamos reutilizar todas esas cosas, ¿verdad? Entonces, ¿qué pasaría si pudiéramos extraer el código específico de la plataforma, el código independiente de la plataforma de Polaris Viz para la web, en una tercera biblioteca, Polaris Viz core, y luego tanto React Native, la versión de Polaris Viz para la web y la versión de Polaris Viz para React Native podrían tener Polaris Viz core como una dependencia? ¿Qué exactamente podríamos compartir? Así que hablemos un poco sobre las similitudes y diferencias entre React y React Native.

En React Native, creamos componentes utilizando etiquetas HTML. Como divs y p para párrafos, por ejemplo. En React Native, por otro lado, tenemos que importar el marcado de la biblioteca React Native. Esto significa que tenemos, por ejemplo, vistas en lugar de divs y texto en lugar de p. Como todavía estamos en el mundo de React, podemos usar todas las funcionalidades comunes de React, como los hooks, por ejemplo. Puedes ver que estoy usando el useState hook exactamente de la misma manera, tanto en la web como en React Native. Hay algunas diferencias en cuanto a cómo adjuntamos eventos al marcado, como puedes ver aquí en el botón HTML, estoy pasando setCount a OnClick, y en el botón Native, se lo paso a OnPress.

Debido a que las aplicaciones nativas no se renderizarán en un navegador, no tendremos acceso a ninguno de los métodos de la ventana. Por lo tanto, en este ejemplo, puedes ver que estamos utilizando window.matchMedia para verificar si un usuario prefiere reducir el movimiento o no. Este es el hook que tenemos en nuestra biblioteca. Y tenemos que importar el módulo accessibilityinfo de React Native para obtener la misma información. Entonces, ambos hooks devuelven un valor verdadero o falso según las preferencias del usuario. Pero para la web, verificamos window.matchMedia en Native. Importamos el módulo accessibilityinfo de React Native. Y por último, React Native no admite SVG de forma nativa. Y esto fue realmente importante para nosotros porque todos nuestros gráficos están escritos con SVG. Entonces, para tener una API similar, decidimos utilizar la biblioteca React Native SVG que funciona prácticamente de la misma manera. Debes importar las etiquetas de la biblioteca y luego escribir tu componente de la misma manera que lo harías si estuvieras usando las etiquetas regulares de SVG.

Bien, hablemos de cómo comenzamos a extraer código independiente de la plataforma y qué es exactamente el código independiente de la plataforma. Así que, victorias rápidas. Lo primero fue todo lo que es simplemente JavaScript. Me refiero a las cosas que literalmente cortamos de la implementación original de Polaris Viz y las pegamos en Polaris Viz-core. Teníamos un archivo grande con muchas constantes guardadas que se compartían entre varios componentes. Cosas como valores predeterminados para espaciado, animación, rangos de bordes, etcétera. Todas esas cosas son simplemente JavaScript que podemos cortar y pegar.

También teníamos un montón de funciones de utilidad. Cosas que nos ayudan, por ejemplo, a crear degradados lineales a partir de una matriz de colores sólidos, convertir HEX a RGB, la curva personalizada que se aplica a nuestros gráficos de líneas. Funciones que nos ayudan a trabajar con data filtrando los valores falsos, etcétera. Todas esas pequeñas funciones de utilidad, simplemente JavaScript que podemos cortar y pegar.

Hablamos brevemente sobre los temas y cómo son importantes para mantener la consistencia. Y la implementación de los temas también fue muy fácil de extraer. La forma en que funciona es que la biblioteca viene con dos temas de forma predeterminada. El tema predeterminado, que es oscuro, y también proporcionamos un tema claro. Un tema es básicamente un objeto de configuración donde se pueden definir no solo los colores sino también todo tipo de estilos visuales, como si las barras deben tener bordes redondeados o no, si los ticks deben ser visibles o no en los ejes. La biblioteca exporta un componente llamado PolarizistProvider que se puede usar para envolver toda la aplicación y anular el tema predeterminado. En este ejemplo, estoy definiendo que el color de fondo de mis gráficos debe ser azul. Y más adelante en mi aplicación, estoy implementando un gráfico de barras y aunque no estoy pasando ninguna propiedad relacionada con el estilo, tiene un fondo azul porque indiqué que mi fondo debería ser azul en el tema predeterminado en el PolarizistProvider. Incluso podemos definir varios temas si queremos. Por ejemplo, aquí estoy definiendo un tema de Rojos Enojados y un tema de Verdes Felices en el proveedor y luego más adelante puedo elegir el tema que quiero usar por el nombre que les di en el proveedor. Aquí, Rojo Enojado tiene un fondo rojo, Verde Feliz tiene un fondo verde. Se ve horrible, pero funciona. El propio PolarizistProvider es simplemente un proveedor de contexto de React. En el fondo, utiliza una función createTheme que permite a los consumidores pasar una lista de temas parciales y devuelve una lista de temas completos. Esto es para que las personas no tengan que preocuparse por pasar ese enorme objeto de configuración. Si, por ejemplo, no pasas cómo deberían verse las rejillas, no hay problema. Simplemente vamos a usar el valor predeterminado de la biblioteca. Otra cosa que fue muy, muy fácil de extraer fueron los hooks. Tenemos un montón de hooks que usamos para crear todos los gráficos de manera consistente.

Cosas como useYscale que nos devuelve las marcas y la escala Y que podemos usar para dibujar un gráfico basado en un par de propiedades comunes como las alturas dibujables. Si el gráfico solo debe tener números enteros en las marcas o no, etcétera.

Lo mismo ocurre con useXscale y useLabels. Nuestras etiquetas son en realidad texto SVG. No son elementos HTML. Tenemos un cálculo muy complejo para determinar si las etiquetas deben mostrarse horizontalmente, en diagonal, verticalmente, si deben truncarse o no. Todas esas cosas se calculan en función del espacio de pantalla disponible y también del conjunto de datos que tienes. Para eso, usamos useLabels.

Debido a que era solo JavaScript, logramos extraerlo de la implementación original. También podemos usar TypeScript en React Native, lo que significa que todos nuestros tipos comunes podrían simplemente extraerse y pegarse en Polaris Viz Core. Para resumir, originalmente, Polaris Viz estaba compuesto por los componentes de gráficos y los componentes de interfaz de usuario que son los bloques de construcción de los gráficos, el proveedor de Polaris Viz que es responsable de los temas, tipos, hooks y utilidades. Solo con las victorias rápidas, y me refiero a cosas que no tuvimos que cambiar, simplemente cortamos y pegamos, logramos extraer prácticamente todo excepto la interfaz de usuario de la implementación original de Polaris Viz en Polaris Viz Core.

Antes de comenzar a hablar sobre cómo podemos extraer los componentes de interfaz de usuario para compartir, tal vez hablemos un poco sobre qué deberíamos compartir. Echemos un vistazo a este gráfico de líneas, por ejemplo. Tiene este tooltip con un montón de información a la que se puede acceder al pasar el cursor, y también líneas, y también leyendas, etcétera, etcétera. Este componente estaba originalmente destinado para web, sin embargo, hay que imaginar que si simplemente lo reducimos y lo hacemos encajar en una pantalla pequeña, no va a ser la mejor experiencia. Tomemos el tooltip, por ejemplo. Si intentas interactuar con algo que tiene un tooltip en un dispositivo móvil, tu pulgar tiende a interponerse en la información que estás leyendo. Por lo tanto, necesitaremos pensar en una mejor manera de manejar eso en pantallas pequeñas.

Pero lo que podríamos compartir, podríamos compartir, por ejemplo, el eje Y, el eje X, podríamos compartir las leyendas, el contenedor del gráfico, que es el componente que renderiza el fondo de color y también las líneas de la cuadrícula, y posiblemente todas las pequeñas líneas. Cada una de estas líneas es un componente que contiene no solo la línea, sino también el sutil degradado que se encuentra debajo de la línea y la animación que se reproduce una vez que se carga el componente, la línea crece de abajo hacia arriba, todas esas cosas probablemente podamos compartir sin comprometer la creación de una buena experiencia para dispositivos móviles.

Entonces, ¿cómo podemos compartir? Porque hablamos de cómo la diferencia principal entre React y React Native es cómo creamos la estructura de los componentes. Vistas versus divs, por ejemplo. El primer enfoque que intentamos fue usar una biblioteca llamada React Native Web. Esta biblioteca es realmente increíble porque te permite simplemente escribir componentes de React Native y se encarga de todo para que puedas renderizar tus componentes de React Native en un navegador. Entonces, teóricamente, podríamos reescribir los bloques de construcción de la interfaz de usuario que queremos compartir en React Native y hacer que tanto Polaris para web como Polaris Native utilicen esos bloques de construcción. Al hacer eso, podemos mover los componentes de interfaz de usuario de los bloques de construcción del Polaris Viz original a la biblioteca central y hacer que Polaris Viz React y Polaris Viz React Native los consuman desde la biblioteca central.

El problema con este enfoque es que no solo Polaris Native necesitaría tener React Native web y React Native como dependencia, sino también la versión web de Polaris Viz porque dependería de los componentes del núcleo. Esto puede no parecer mucho, pero si comparamos el tamaño del paquete de react-dom, podemos ver que React Native web es casi el doble de tamaño. ¿Y recuerdas que hablamos de que React Native no admite SVG de forma nativa? Entonces, para que esto funcione, también tendríamos que incluir React Native SVG como una dependencia del núcleo. Shopify es un sistema muy complejo que ya tiene muchas dependencias, y debido a que tenemos clientes en todo el mundo, incluidos lugares que no tienen acceso a velocidades de intranet rápidas, cada dependencia aparentemente pequeña que agregamos puede tener un gran impacto en la velocidad con la que las personas pueden ver la página web y administrar sus tiendas.

De acuerdo, necesitamos una nueva estrategia para hacer que esto funcione, compartir bloques de construcción de DUI mientras mantenemos el tamaño del paquete pequeño. Ya tenemos un proveedor de contexto que tanto Polaris Viz Web como Native usarán. Entonces, ¿qué tal si el proveedor también pudiera determinar qué etiquetas de marcado deben usar los componentes y núcleos según si estamos en Web o Native? En Polaris Viz Core, el proveedor de Polaris Viz aceptaría una lista de componentes, y luego Web pasaría componentes web, Native pasaría componentes nativos. Por lo tanto, en Core tendríamos el proveedor agnóstico de la plataforma que recibe la lista correcta de marcado según la plataforma de Polaris Viz Web y Polaris Viz Native.

Veamos esto como un ejemplo. En Polaris Viz Native tendríamos una reexportación del proveedor original, por lo que importaríamos el proveedor original de Polaris Viz desde Core y también importaríamos las etiquetas svg de react-native-svg. Esto significa que react-native-svg es solo una dependencia de Polaris Viz Native. Luego pasamos la lista de etiquetas svg que queremos usar para crear esos bloques de construcción compartidos a través del proveedor. Haríamos algo similar en la versión web de esto. También reexportaríamos el proveedor original, pero en lugar de pasar etiquetas svg nativas, simplemente pasaríamos etiquetas svg HTML regulares envueltas en componentes de React. Entonces puedes ver aquí que estoy usando React.createElement para básicamente usar el mismo comportamiento de la API predeterminada de una etiqueta svg o circle en React. Esto significa que podemos crear algún componente compartido en Polaris Viscore, y en lugar de usar svg directamente o importarlo directamente desde el svg nativo de React, obtenemos las etiquetas que queremos usar para crear la IU desde el contexto llamando al gancho UsePolarisVisProvider, y luego podemos crear cualquier marcado que queramos que se comparta entre React Native y la web. Al usar UsePolarisVisContext en Polaris Viscore web, voy a tener etiquetas svg regulares, y en Polaris Viscore nativo, voy a tener etiquetas svg nativas.

Ahora que hemos hablado de cómo se ve la estrategia general, echemos un vistazo más de cerca a cómo se ve implementar esta estrategia en un gráfico real. Tenemos este componente llamado SparkBarChart, y solo para contexto, SparkCharts son útiles para presentar una tendencia. Se supone que es algo en lo que puedes echar un vistazo rápido y tener una comprensión de tus datos, pero no es algo en lo que debas explorar los detalles de un conjunto de datos, como profundizar en un conjunto de datos. Por lo general, lo usamos en barras analíticas que se presentan en páginas, donde el enfoque principal no es la exploración de datos, pero puede proporcionar información útil sobre cómo está funcionando tu negocio. En esta página, por ejemplo, la tarea principal es trabajar en tus pedidos, los pedidos que tu tienda recibió, por lo que es útil saber cuáles son las tendencias de los pedidos recibidos o las devoluciones de productos, por ejemplo. Así es como se ve el archivo SPARK bar chart en Polaris Viz nativo. Primero importamos el tipo de propiedad compartida, los componentes de barra, así como los ganchos use X-scale y use Y-scale de Polaris Viz core. Luego usamos los ganchos para obtener todas las funciones que necesitamos para renderizar las barras, es decir, X-scale, Y-scale, el ancho de la barra y la altura de la barra. Luego usamos el componente de barra que importamos de core en el gráfico. Bajo el capó, el componente de barra que se encuentra en core obtiene su marcado de ruta del contexto. Entonces, porque estoy usando barra dentro de Polaris Viz nativo, va a obtener la versión nativa de la ruta en lugar de la regular. Luego importamos un contenedor de gráfico nativo desde una ruta relativa que también se encuentra en la carpeta Polaris Viz nativo. La razón por la que necesitamos un contenedor de gráfico nativo es porque accedemos a diferentes API para calcular el tamaño que debe tener el contenedor. Nuestros gráficos en Polaris Viz básicamente intentan ocupar el espacio proporcionado por los padres. Para hacer eso, necesitamos medir los padres para comprender cuál debe ser el ancho y la altura del gráfico. En nativo, obtenemos el ancho y la altura de los padres pasando una función a la propiedad onLayout del componente de vista. Esa función se llama cada vez que el componente cambia de tamaño.

Alternativamente, en la web, utilizamos el observador de redimensionamiento para hacer lo mismo. Tanto la web como la versión nativa pasan la altura y el ancho calculados a los hijos utilizando react.cloneElement. Con este enfoque, podemos asegurarnos de que los elementos tengan acceso al ancho y alto, aunque no se lo pasemos explícitamente como props. Aquí, el gráfico sabe cuál es el ancho y alto de los padres.

Después de mucha exploración, fracasos y nuevos intentos, llegamos a una solución que realmente funciona para nosotros y facilita mucho a los desarrolladores web contribuir a la biblioteca y acelera el proceso.

Con estos bloques de construcción en su lugar, podemos reimaginar cómo se ve una buena experiencia de visualización de datos en dispositivos móviles. Tomemos como ejemplo un gráfico de líneas. Hemos hablado brevemente sobre esto, pero esta experiencia no puede simplemente reducirse para adaptarse a una pantalla pequeña. En realidad, tenemos que pensar en cómo debería verse para pantallas pequeñas. Es muy molesto intentar leer una pieza de información que está oculta debajo de tu pulgar.

Entonces, ¿qué tal si, por ejemplo, usamos gestos para explorar un rango de datos específico? Podríamos omitir la información del eje para tener todo el ancho de la pantalla para dibujar las formas reales y luego podríamos usar gestos para explorar un período de tiempo específico, por ejemplo. Podríamos tener diferentes gestos, como pellizcar para hacer zoom dentro y fuera del rango de datos, y podríamos usar, por ejemplo, dos dedos para desplazarnos horizontalmente y ver los puntos de datos que no están actualmente visibles en la pantalla. Todo eso mientras mantenemos la información del punto de datos actual visible en la parte superior del gráfico en lugar de oculta debajo de mi pulgar. Incluso podríamos tener comandos de voz como `muéstrame los datos entre el 8 de junio y el 10 de junio` y el gráfico los filtraría automáticamente para ti.

Eso es todo lo que tenía para hoy. Espero que estés tan emocionado como yo por el futuro de la visualización de datos en dispositivos móviles. Como mencioné antes, Polaris Vis será de código abierto próximamente, así que espero que también estés emocionado de contribuir a la biblioteca. Pero si quieres tener un mejor acceso ahora y quieres ayudarnos a probar la biblioteca antes de que sea de código abierto, no dudes en comunicarte directamente conmigo, Cristal Campione, en Twitter o escribir al equipo en polaris-vis-feedback en Shopify.com. Muchas gracias por seguirnos y disfruta del resto de la conferencia.