La magia de construir una arquitectura de sistema de diseño multiplataforma

Hola a todos. Soy Kamlesh. Trabajo como ingeniero de producto principal en el equipo de sistemas de diseño y herramientas de infraestructura, que forma parte del equipo de plataformas en Razorpay. Así que, hoy voy a hablar sobre la magia de construir una arquitectura de sistemas de diseño multiplataforma. Entonces, antes de comenzar, quiero aclarar que esto se basa en nuestra experiencia y en cómo abordamos este espacio de problemas según los factores. Y eso no significa necesariamente que sea la única forma. Así que, comencemos primero con el enunciado del problema. Queríamos un sistema de lenguaje de diseño que funcionara en varias plataformas. Ahora, comenzamos con qué otros enfoques tenemos disponibles. El primer enfoque fue que cada equipo construyera para cada plataforma. Eso es natural. Tienes diferentes equipos, diferentes plataformas y tienes diferentes equipos trabajando.

en esas plataformas. Y luego comenzamos a enumerar los pros y los contras de cada uno de los enfoques. Entonces, los pros de este enfoque eran que teníamos la experiencia de las personas para cada plataforma. Digamos que un desarrollador nativo estaba trabajando en una aplicación de iOS, tendrían su propio conjunto de conocimientos. Y luego otro desarrollador web estaba trabajando en la plataforma web, tendrían su propio conjunto de conocimientos. Así que, queríamos ambos. Y también podríamos aprovechar las capacidades nativas ofrecidas por cada plataforma porque hay muchas capacidades que, digamos, a veces las plataformas nativas te ofrecen, pero las plataformas web no, o las han expuesto de una manera diferente. Así que, queríamos aprovechar estas capacidades de forma nativa en cada una de las plataformas.

Los contras de este enfoque son múltiples equipos construyendo lo mismo, ¿verdad? Como tienes varias personas que están resolviendo el mismo problema una y otra vez. Y luego teníamos código redundante para cosas similares. El tercero era una menor unificación de las API, ¿verdad? Porque ahora tus API serían redundantes o serían creadas por diferentes equipos.

Luego había otro enfoque que era usar React Native Web, por supuesto, que es una opción muy famosa en estos días. Así que tenía pros, que era que podías escribir una vez y usarlo en la web y en las plataformas nativas, que es lo que estábamos buscando. En segundo lugar, eran API similares en todas las plataformas. Los contras eran que React Native Web se usa para escribir también para la web, ¿verdad? Ahora los desafíos para React Native Web para debug cosas de la web. Es como nativo primero y luego penetrar con la web.

Ahora, ninguno de los anteriores cumplía con nuestras necesidades. Estábamos buscando algo que tuviera una misma API y funcionara en la web y en las plataformas nativas, aprovechar las capacidades nativas ofrecidas por cada plataforma y luego queríamos que los desarrolladores de aplicaciones hicieran lo que mejor saben hacer y los desarrolladores web hicieran lo que mejor saben hacer. Así que, básicamente, nuestro deseo en el estado de Nirvana era qué pasaría si un desarrollador tuviera que implementar lo siguiente en plataformas, para ellos debería ser como para nosotros si tomas este subcódigo y lo copias y pegas tanto en la web como en las plataformas nativas, debería funcionar sin problemas. Eso era como podrías decir nuestro estado de Nirvana. Entonces, ¿cómo abordamos esto? Así que, enumeramos todas las cosas que necesitamos abordar. La primera fue una API única que funcionara en todas las plataformas, luego queríamos un testing center porque aunque escribieras una vez y ejecutaras en ambas plataformas, aún queríamos probar nuestros componentes en ambas plataformas individualmente para no perder ningún error en ninguna de las plataformas. Y luego queríamos empaquetar cada plataforma por separado para que tu paquete web no se mezcle con react native y viceversa porque de lo contrario se romperá. Y también queríamos enviar tipos de TS junto con cada uno de estos paquetes individuales.

Sí, veamos las cosas en acción implementando un componente tipográfico. Entonces, este es el componente que implementaremos y debería funcionar tal como está en ambas plataformas. Esto es básicamente y el estado que haremos durante esta sesión. Ahora, comencemos con el primero, mismas APIs que funcionan en todas las plataformas. Entonces, si lo piensas, la API para esto se vería algo así, digamos que quieres design o crear un componente tipográfico, ¿cómo se vería la API? Tendría ID de color, familia de fuentes, tamaño de fuente, peso de fuente, estas son las propiedades básicas para un componente tipográfico. Entonces, por lo general, lo que harías es comenzar implementando plataforma por plataforma. Así que, lo obvio para comenzar es simplemente implementarlo en la web.

Correcto. Estamos utilizando componentes de estilo. Simplemente definimos los estilos y luego renderizamos el texto de estilo y lo devolvemos, y luego lo exportamos. Luego, en nativo, volvemos a definir los estilos y cómo se renderizarán y avanzamos. Pero hay algo que está sucediendo aquí. Vamos a averiguar qué está pasando. Si observas esta parte del código que se está resaltando y esta otra parte de código, ambas son iguales. La única diferencia entre ambas es la parte superior, que básicamente son tus importaciones donde estás importando tu estilo.dev en la web porque estás renderizando un estilo.txt en nativo. Esta es la única diferencia. Esto no es lo que queríamos ver. Vamos a ver qué podemos hacer para mejorarlo.

Entonces, primero vamos a extraer los estilos. Vamos a ver que los estilos son comunes. Vamos a crear una función que acepte ciertos argumentos y luego los devuelva. Estos son básicamente nuestros estilos. Ahora, hagamos una refactorización. Esta parte que es común tanto en la web como en nativo, la vamos a eliminar y reemplazar con nuestra nueva función getTextStyles. Ahora, a continuación, queremos exponer algo para nuestros consumidores. Este es el paso tres. Si el consumidor, el consumidor solo debería decir importar texto desde el sistema de diseño. Ya sea que deba ser un componente web que queremos devolver o queremos devolver un componente nativo, esa debería ser la abstracción y eso debería ser manejado por la herramienta o la plataforma que estamos creando. Entonces, esa es básicamente la responsabilidad del equipo de diseño del sistema.

Entonces, ¿cómo convertimos este concepto en realidad? ¿Cómo logramos algo que sea como, ya sabes, dices importar y la plataforma debería identificarlo directamente? Utilizamos el poder de los empaquetadores, las extensiones de archivo y los empaquetadores. Ahora, antes de adentrarnos en eso, quiero hablar sobre cómo Metro, que es básicamente un empaquetador para React Native,

Metro resuelve archivos a partir de hoy. Por ejemplo, cada vez que importas un archivo desde un archivo, Metro primero buscará la extensión del archivo, que básicamente significa si existe un archivo con, digamos, .Android.ts. Si es así, lo resuelve. Si no, luego busca ios.ts. Si no, verifica si existe native.ts. Si no existe, se utiliza .ts. Esto es algo que Metro hace actualmente. Esto te permite implementar cosas específicas de Android o específicas de iOS, que es un requisito muy básico y a veces necesario. ¿Qué tal si robamos esta idea y la aplicamos para que funcione en la web? Veamos cómo. Webpack tiene esta configuración que se llama resolve extensions, ¿verdad? Es un array que define el orden de prioridad para la resolución de archivos. Ahora, lo que haremos aquí es decirle a Webpack que haga lo que quiera hacer, como TSS y todo eso. Lo que haremos es agregar .web.ts y .web.tsx. El orden de prioridad es básicamente la forma en que defines los elementos en el array. Ahora, Webpack funciona de la siguiente manera: cada vez que importas un archivo, va y verifica si existe filename.web.ts. Si es así, lo resuelve. Si no, simplemente selecciona filename.ts. Después de hacer esto, lo que tenemos que hacer es renombrar nuestros archivos para que nuestros empaquetadores puedan seleccionar el archivo específico para esa plataforma en particular. Entonces, diremos text.web.tsx y text.native.tsx, y luego tendremos, por supuesto, un index.tsx que simplemente exportará text desde text. Ahora, veamos si las cosas están funcionando hasta ahora. Cambiaré a VS Code y escribiré text. Este es básicamente un componente de texto en el que estamos trabajando. Como puedes ver, tenemos text.native, text.web y luego tenemos index. Ahora, veamos si las cosas funcionan. Muy bien. Las cosas se están renderizando como queríamos. También mostraré la parte nativa. Las cosas funcionan perfectamente. Pero si observas, hay un pequeño error que dice no se puede encontrar el módulo text o su declaración. Ahora, lo que sucede es que hicimos que nuestros empaquetadores comprendieran cómo resolver estos archivos, pero TypeScript aún no lo sabe. La forma de solucionar este error es definir declaraciones y simplemente decir export text from text.web. Y las cosas deberían funcionar.

Disculpa, mi error. Necesitamos decir text.t.tsx. Y sí, esto funcionaría. Este error ha desaparecido porque ahora TypeScript está contento cuando dice que sabe que está bien. Cuando haces clic en él, sabe que está bien, necesito resolverlo desde aquí. Así que TypeScript está contento, nuestras salidas se están renderizando. Así que volvamos. Básicamente, si ves, configuramos los empaquetadores, pero luego, para que esto funcione, básicamente definimos nuestras declaraciones. Así que volviendo a nuestra lista de verificación, tenemos la misma API que funciona en todas las plataformas, al menos en una versión mínima.

Ahora pasemos al segundo elemento de nuestra lista de verificación, como pruebas, pruebas para ambas plataformas. Ahora estamos utilizando la biblioteca de pruebas de React. Así que configuremos Jest para pruebas para la web, porque si recuerdas, estaba diciendo que necesitamos Jest para pruebas para ambas plataformas, queremos probar para la web y también queremos probar para nativo. Entonces, comenzando con la configuración web para Jest, lo que estamos tratando de decirle a Jest es que, ya sabes, solo incluye la cosa de extensiones web y omite todos los archivos de prueba nativos. De manera similar, para nativo, estamos haciendo lo contrario. Estamos diciendo que ignore todos los archivos de prueba web e incluya solo las extensiones nativas que terminan en archivos .native. Ahora escribamos algunas pruebas. Así que creamos un componente de texto ahora mismo. Simplemente escribimos una prueba para ello. Esto es solo el componente básico extraído para pruebas. Ahora veamos la magia multiplataforma. Crearemos un archivo llamado test.web.test.tsx que básicamente utilizará el DOM de Jest y lo renderizará usando el renderizador que proporciona la biblioteca de pruebas de React. Y de manera similar lo haremos para para nativos. Ahora veamos si la prueba realmente funciona. Así que prueba con react. Está en ejecución. Finalmente, nuestras pruebas funcionan para la web. Ahora veamos si esto también funciona para React Native. Muy bien, las pruebas están pasando, lo que significa que las cosas funcionan bien. El nativo está haciendo lo que se supone que debe probar la plataforma nativa y la web está probando para las plataformas web. Sigamos adelante.

Así que las pruebas están hechas. Ahora vamos a empaquetar cada plataforma por separado junto con nuestros tipos de TypeScript. Entonces, ¿qué deberíamos usar para empaquetar nuestro sistema de diseño tanto para la web como para React Native? Utilizaremos Rollup. Pero, ¿puede Rollup empaquetar bibliotecas de React Native? Sí, lo hace.

Entonces, el primer paso sería configurar Babel. Esta es nuestra configuración de Babel. Primero definiremos los complementos y los ajustes para React Native. Esta configuración es simplemente un objeto que estamos creando ahora mismo. Tiene una clave llamada React Native. De manera similar, tiene una clave llamada React. Ahora lo que haremos es cuando exportemos, la forma en que exportamos es leyendo una variable de entorno llamada framework, y según el framework que se pase, exportaremos esa configuración de Babel en particular. Solo mantén esa variable de entorno. Volveremos a eso.

El segundo paso es configurar Rollup. De la misma manera que hicimos para Babel, lo haremos también para Rollup. Definiremos dos configuraciones. Primero comenzaremos con React Native. Definiremos la entrada como index.ts. Y luego la salida será index.native.js. Presta atención a esto en particular. De manera similar, para React, simplemente diremos que el archivo de salida es index.web.js en la configuración. Luego agregaremos scripts a nuestro package.json, que simplemente diremos que tendremos dos scripts, uno para construir React y otro para construir React Native. Si ves aquí, está la variable de entorno que estamos pasando. Decimos que el framework es React para el script de React, y el framework es React Native para el script de React Native. Pero veamos cómo funciona todo esto. Permíteme mostrarte o ayudarte a visualizar cómo funcionarían estas cosas. Entonces, primero cuando se ejecute el script para construir React, lo que hará es configurar la variable de entorno en React, lo cual luego actuará como una entrada para la variable config, que simplemente entenderá, okay, necesito exportar mi configuración de React. Y luego el siguiente paso sería Rollup. Así que simplemente leerá la variable de entorno y devolverá la configuración de React, básicamente la configuración web para Rollup. Y después de eso, simplemente creará un paquete,

que es index.web.ts. Y de manera similar, lo hará para React Native. Y lo que obtendrás es React native.ts. Así que veámoslo en acción. Vamos a regresar a nuestro navegador y simplemente ejecutaremos la construcción Yarn build. Hagamos una serie de cosas, creemos todo. Y está creando los paquetes. Ok, si ves, somos capaces de crear el paquete que es .native y de manera similar el .web, lo cual básicamente significa que hemos logrado crear lo que queríamos. Volvamos. Pero espera, ¿qué pasa con los tipos? Nuestros tipos están ubicados junto con nuestros componentes si los hubieras visto, ¿verdad? Pero empaquetamos los componentes en un solo paquete, pero no estamos empaquetando los tipos. ¿Qué hacemos? Entonces, necesitamos empaquetar nuestros tipos en la misma estructura que nuestro paquete de biblioteca, ¿verdad? Pero espera, ¿cómo lo vamos a hacer? Nuevamente, Rollup al rescate. Así que recuerda nuestra antigua configuración donde teníamos react-native y react. Lo que haremos es mejorarla, y vamos a usar un complemento llamado 'declarations'. Haremos, nuevamente, un complemento de Rollup llamado 'declarations'. Lo que hace es básicamente, generará un paquete de tus archivos de declaración. La entrada es index.d, y generará en tu carpeta de construcción junto a nuestras construcciones reales. Así es como se verá, la estructura final. Permíteme volver rápidamente al código y agregar este paquete. Y ejecutemos la construcción nuevamente. Sí, se está ejecutando, se está ejecutando, se está ejecutando. Listo, ha terminado. Ahora, si ves, tenemos estos tipos. Y si lo abres, tiene todas las declaraciones que exportamos o que queríamos. Dado que está junto a tus archivos de índice, tu inteligencia, todo funcionará correctamente. Y eso es básicamente lo que queríamos. Así que una cosa que queremos enfatizar es que solo necesitamos un paquete de tipos porque tenemos la misma API en todas las plataformas, ¿verdad? Recuerda que eso es básicamente con lo que comenzamos. Volviendo a nuestra lista de verificación, tenemos la misma API, que funciona en todas las plataformas. Tenemos una configuración de pruebas que prueba cosas individuales para no pasar por alto ningún error mientras intentamos lograr la compatibilidad entre plataformas, y luego podemos empaquetar cada plataforma junto con los tipos de typescript. Pero espera, ¿qué pasa con la accessibilidad? Hablemos de accessibilidad. Entonces, hay algunas indicaciones de accesibilidad nativas y web, ¿verdad? En React Native, se llama 'accessibility role description'.

en la web se llama 'area role description'. Luego tenemos la etiqueta de accesibilidad en React Native, pero en la web es como 'area label'. Estas son algunas diferencias. Siguiendo el mismo enfoque que nuestros componentes, crearemos dos mapas, ¿verdad?, que tendrán un alias, que es un label requerido oculto inválido en este ejemplo, y acceso, como le dimos los valores respectivos para cada plataforma. Estos son dos mapas. Luego los colocamos en dos archivos diferentes, que son accessibility.web.ts y .native.ps. Luego lanzaremos una función sobre ellos, que se resolverá o se ejecutará, que se utilizará en tiempo de ejecución. Y simplemente dirá, ok, si estás en tiempo de construcción, y simplemente dirá, sabes, estás construyendo para la web o estás construyendo para nativo basado en eso, simplemente hará una búsqueda y te dará el nombre de la propiedad respectiva. Veamos la acción. Simplemente tomaremos nuevamente el componente de tipografía que construimos. E importaremos nuestra función 'make accessible', le pasaremos la propiedad de accessibility. Y si ves en la parte inferior, esto es lo que obtendrás, ¿verdad? Simplemente te dará la propiedad, que es para ese programa en particular. Así que simplemente dirá 'text role'. Simplemente dirá 'text role heading', y simplemente hará un render de 'area role' en la web y simplemente 'role' en React Native. Así que, sí, eso es básicamente lo que queríamos, ¿verdad? Tu accessibility también está resuelta. Así que hagamos un breve resumen. Comenzamos con una única API para gobernarlos a todos. Utilizamos el poder de las extensiones de archivos, es decir, web y nativo, y luego extraímos todas las cosas comunes que son independientes de la plataforma, ¿verdad? Así que digamos que son cosas comunes, digamos estilos que son comunes, las extraímos en un get textiles. Obtenemos lógica específica de la plataforma dentro de los archivos web y nativos. Por ejemplo, si quieres pasar una propiedad que no existe en nativo, lo que harías es lanzar un error en la plataforma nativa. Así que podrías poner esa lógica en estos archivos web y nativos. Configuramos nuestras herramientas, que son metro, webpack, rollup, jest, estint y typescript para resolver adecuadamente. Nuevamente, simplemente estamos utilizando o aprovechando al máximo nuestras herramientas. Vuelven a empaquetar para cada plataforma individualmente utilizando rollup. Generamos un solo paquete de tipos utilizando rollup nuevamente. Así que sí, eso es todo de lo que tenía que hablar. Espero que te hayas divertido. La demostración que mostré está en GitHub. Puedes ir a mi perfil. Se llama cross-platform design system. Y puedes ir y visitar nuestro sistema de diseño, que se llama played, que también es de código abierto. Y puedes ver todo en acción. Y funciona perfectamente bien. Eso es todo. Gracias.