Plug and Play Design: Construyendo Aplicaciones React Extensibles

Hola, Nueva York. Es un placer estar aquí. Así que comencemos. Como se dijo, soy Mateusz Jagodziński. Soy desarrollador principal en Synergy Codes, que es una empresa que desarrolló el Workflow Builder. Aquí hemos enlazado a mi LinkedIn o mi correo electrónico.

Así que la charla de hoy se llama Plug and Play Design Building Extendable React Applications. En esta charla, hablaremos un poco sobre feature flags, modularidad y el caso de uso que tuvimos en nuestro producto y cómo abordamos estos casos, estos problemas. Les mostraré una demostración rápida de este Plug and Play Design, y luego entraré en un poco más de detalle sobre qué es, cómo funciona bajo el capó, y qué impacto tiene esta solución.

Así que feature flags. Una pregunta rápida para la audiencia. Siéntanse libres de levantar las manos quienes han trabajado en un proyecto que tenía feature flags. Bien, veo algunas manos. ¿Y cuántos de ustedes se han encontrado a veces en una situación en la que se preguntaban de dónde viene este feature flag? ¿Es de hace tres años o de algún lugar? Bien, veo algunas manos también. Así que feature flags. ¿Por qué los usamos siquiera? Son cosas bastante útiles. Nos permiten hacer un lanzamiento gradual de características. Proporcionan una manera de hacer pruebas A-B. Y entraré en un poco más de detalle en un momento. En nuestro caso, nos permiten preparar diferentes versiones del mismo producto para diferentes clientes, esencialmente.

Pero los feature flags, en general, pueden tener algunos de sus problemas. Así que hay más lógica condicional en nuestro código. Eso no es tan bueno, esas sentencias if y demás. Como con la pregunta que hice, con esos feature flags antiguos, pueden convertirse en deuda técnica si no los gestionamos adecuadamente. Así que tal vez lanzamos una nueva característica pero olvidamos eliminar la antigua, el feature flag permanece, y bueno, se convierte en un bloat de deuda técnica dentro de nuestro código. Y una cosa que también será relevante para nuestro caso es que el código de características no utilizadas generalmente todavía se envía en el bundle. Porque si tienes un feature flag condicional que sirve a un componente u otro, bueno, todavía necesitas ambos componentes dentro del código.

Así que la pregunta que quería hacerte hoy es, ¿y si las características pudieran simplemente añadirse o eliminarse simplemente dejando caer una carpeta dentro y fuera de tu proyecto? Así que como si tuviéramos una alternativa a los feature flags, pero en el tiempo de compilación, donde pudiéramos decir, bien, esta carpeta tiene una característica, esta otra, podemos elegir cuál queremos elegir. Imagina un configurador de coches donde dejas caer componentes o características específicas dentro de tu código. Entonces, ¿y si? Bueno, típicamente, si intentamos eliminar una carpeta de una aplicación de React, probablemente algo como en este GIF sucedería. Y esto es porque, bueno, modularidad. Sí, así que definitivamente este enfoque requeriría un buen enfoque modular para lo que tenemos en la aplicación. Buena separación del código.

Así que, bueno, esta carpeta que queremos eliminar realmente contiene todas las cosas relacionadas con esa característica. Y, bueno, generalmente nos gustaría evitar situaciones donde necesitamos tocar cinco lugares diferentes en el código, solo para añadir una cosa. Así que, sí, modularidad. Aquí encontré alguna definición para ello. Así que, lo que modularidad en general, ese es otro tema de los feature flags, probablemente es bueno tener, nos permite separar preocupaciones con nuestras aplicaciones y encapsular esas funcionalidades específicas. Básicamente hace nuestro código más limpio, asegura que sea más fácil de trabajar. Entonces, ¿cómo lograrlo? Bueno, obviamente hay diferentes maneras en las que podríamos hacerlo, pero permíteme saltar a un caso específico que tuvimos. ¿Cierto?

Está diseñado para ser configurable para diferentes casos de uso para diferentes clientes, y mucho de esto se puede hacer mediante configuración. Así que como en esta pantalla, tienes esta paleta. Puedes especificar esto principalmente a través de los archivos de configuración JSON y demás, ¿verdad? Esa era la idea, pero no todo se puede especificar mediante configuración. Hay tal vez formas en las que necesitas renderizar un componente o proporcionar un comportamiento diferente y demás.

Y con nuestra herramienta, este fue un caso muy común para nosotros donde queríamos enviar esencialmente la misma herramienta, pero como diferentes versiones de ella para diferentes clientes. ¿Verdad? Y los feature flags realmente no eran una respuesta para nosotros debido a algunas de nuestras restricciones. Pero ahora lo que me gustaría mostrar es este diseño de plan de plugins que tenemos rápidamente en una breve demostración y mostrarte cómo funciona, y luego profundizaré un poco en los detalles.

Así que aquí tengo solo una versión local de nuestro proyecto en ejecución. Así que sí, aquí está, algún diagrama con un flujo de trabajo, ¿verdad? Elegiré una de las características que tenemos aquí. Tenemos algo llamado widgets. Esto nos permite básicamente mostrar datos adicionales en esos nodos. Pero sí, así que digamos que añadiré otro widget, habilitaré una herramienta. Como puedes ver, aparece en varios lugares en el código. Tenemos este selector de widgets en el lado derecho, al mismo tiempo, estamos modificando los componentes de React que tenemos aquí. Así que sí, la característica, como una característica típica, captura un par de lugares dentro del código.

Así que déjame volver al código. Y sí, aquí dentro de la estructura, tenemos nuestra carpeta de plugins donde la lógica real para las características de los widgets está presente. Así que tenemos estos componentes que definen y etc. Hablaré un poco más sobre este código en un segundo. Pero lo que quería mostrarte es que puedo, bueno, eliminar esa carpeta. Necesito volver a ejecutar el código porque la recarga del módulo en caliente no funcionará con él. Pero en un segundo, mientras solo inicio la aplicación, y sí, debería funcionar. Y no funcionó. Bien, déjame verificar. No, está funcionando. Solo se está recargando. Oh sí, el síndrome de la demostración, sin estrés con toda la audiencia. Bien, sí. Ahora está cargado. Solo necesitaba un poco más de tiempo.

Solo necesitaba un poco más de tiempo. Así que como puedes ver, es el mismo diagrama, la misma cosa en la que trabajé. Pero bueno, ahora mismo, simplemente no tiene esas características, los datos y todo lo demás permanecen igual. Pero tenemos los nodos, y no hay un selector aquí en el lado derecho. Y no hay extensión aquí en el nodo. Así que volviendo a la presentación, me gustaría mostrarte cómo lo hicimos, cómo lo logramos. Sé que, ya sabes, eliminar una carpeta puede no ser gran cosa, pero cualquiera que haya trabajado con un código front end de React sabe que no puedes simplemente, ya sabes, eliminar piezas de código y, bueno, simplemente hacer que se construya y funcione típicamente.

Así que un par de cosas con esto, como lo llamamos, diseño plug and play, las restricciones que teníamos, lo que intentamos lograr fue este par de cosas que puedes ver aquí. Así que necesitábamos una manera de agregar y eliminar código fácilmente. Para que podamos, ya sabes, preparar esas diferentes construcciones. Lo que realmente queríamos era tener características eliminadas no enviadas en el código. Así que básicamente tener este, bueno, tamaño de paquete más pequeño, pero, ya sabes, código fuente más pequeño en general, no enviar lo que no se necesita. Al mismo tiempo, queríamos tener seguridad de tipos completa dentro de nuestro proyecto TypeScript. Así que todo este código viviría en un monorepo, y queríamos tener todas las referencias no, ya sabes, teniendo esos plugins en otro lugar.

Así que para permitirnos modificar el código de los plugins junto con el código de la aplicación. Entonces, ¿cómo funciona? Creo que es, disculpa. Entonces, ¿cómo funciona? Hay tres pasos y piezas de código que mostrarán adaptadores, plugins, y configuración general de construcción alrededor de esto. Así que lo primero, adaptadores. Aquí hay un ejemplo del código. Así que tenemos esto, esencialmente, un contenedor con plugins de componentes opcionales. Así que es como un contenedor que nos permite envolver cualquier componente de React con componentes adicionales. Con lógica adicional. La primera pieza que viene aquí nos permite básicamente modificar las props de cualquier componente. Así que tenemos un plugin que define funciones que modifican esas props. Lo siguiente que podemos hacer dentro de este adaptador es insertar un componente antes, después, o crear un componente de orden superior y un contenedor justo alrededor de él. Obviamente, junto con esas props modificadas. Así que esta es una manera de modificar la lógica existente dentro de la aplicación. ¿Verdad? Ahora, además de un adaptador para los componentes, tenemos un adaptador para funciones. Así que básicamente podemos tomar cualquier función dentro del código, envolverla con este adaptador y permitir esto, ya sabes, para básicamente cambiar los valores de entrada o tal vez los valores de salida de esa función y devolverlo.

Sí. Así que aquí está solo la continuación de ese código. Así que lo siguiente que necesitamos dentro de la aplicación, dentro de la lógica del adaptador es exponer una función para registrar este nuevo plugin dentro de la aplicación. Y esto es como, ya sabes, solo un conjunto que tiene todos esos plugins que aplican componentes separados. Mostraré en un segundo cómo esto está siendo utilizado. Así que para resumir, adaptadores, con ellos, podemos envolver un componente y una función, modificar sus pros, insertar otros componentes. Así que como en el caso de esos widgets que he mostrado, había un par de, ya sabes, selectores, widgets, etcétera. Y exponemos una función para permitirnos registrar nuevos plugins.

Ahora en el propio plugin, en el lado del plugin, tenemos, bueno, básicamente, lo primero es especificar los componentes que pueden ser envueltos. Así que aquí tenemos como este ejemplo, componente de barra de propiedades que se envuelve con este envoltorio. Y bueno, ahora los plugins pueden hacer uso de él. Y abajo hay un ejemplo de una función. Así que ese es el primer paso. Los plugins viven en su propia carpeta. Y la idea es que toda la lógica relacionada con ese plugin esté dentro de ese formato individual. Ya sean componentes, funciones, hooks, estilos, todo.

Y el actual, en el lado del plugin, la pieza actual, estamos usando esos decoradores de componentes de registro que hemos definido anteriormente básicamente diciendo, OK, para este componente específico aquí en este diagrama de ejemplo, modificamos las props por alguna función o tal vez modificamos algunas, como abajo con estas propiedades de borde, por ejemplo, añadimos componentes adicionales después del componente. Así que ahora lo primero, configuración de construcción. Bien, entonces, ¿dónde está la conexión entre los plugins, verdad? Así que tenemos esta importación de todos los plugins en un solo lugar. Hay este SlintRuler al que volveré en un segundo, pero básicamente este es el único lugar donde la aplicación realmente hace referencia a ese código de plugins. Ahora para esta aplicación, estamos usando Vit para construir la configuración para construir la aplicación y cómo lo hacemos que realmente podemos eliminar esos archivos de plugins. La idea es que tenemos este plugin de reemplazo de archivos que básicamente nos permite reemplazar con un simple stub, ¿verdad? Así que lo configuramos en el plugin de Vit.

Este es el código, lo llamamos fallback para un plugin faltante, que básicamente reemplaza el código siempre que el plugin esté faltante, ¿verdad? Y esto nos permite, bueno, eliminar algo sin que la aplicación deje de funcionar, ¿verdad? Las importaciones están funcionando. Bueno, este es el stub, bastante básico.

Y lo último dentro de la configuración de construcción que encontramos que es muy útil para nosotros es una regla personalizada de SLint que proporcionamos que básicamente evita que cualquier parte del código, del código de la aplicación, importe desde los archivos del plugin. Así que sí, cada vez que intentamos importar algo directamente desde el plugin, no debería permitirnos porque es un error, ¿verdad? Y esto obliga a los programadores a básicamente mantener el código del plugin dentro de la carpeta de plugins.

Así que sí, para resumir, exponer los componentes para nosotros, pero los plugins, importar archivos de plugins. Tenemos este fallback. Si eliminamos algo y usamos SLints para imponer esto a los desarrolladores. Aquí, como un diagrama, creo que tal vez lo visualiza mejor, las relaciones más antiguas. Así que tenemos estos plugins dentro de su propia carpeta, están haciendo uso de la aplicación y componentes envueltos en adaptadores. Al mismo tiempo, prevenimos esas importaciones y tenemos este plugin de Vit que permite reemplazar plugins faltantes con el código.

Así que resumamos esto. Bueno, hay algunos pros de esta solución. Así que las características construidas como plugins son autónomas, ¿verdad? Tenemos una mejor encapsulación de nuestra lógica. Con esta configuración de construcción y SLint, imponemos esas reglas. Así que hay menos lugar para un error. Sabes, típicamente la aplicación de React no, React en sí no impone mucho a los desarrolladores por sí misma. Así que a veces es bueno imponerse restricciones. Una cosa, el código innecesario no está en el paquete final. Así que si eliminamos algo como un plugin, no se envía, no se construye. Y al mismo tiempo, el código del plugin puede usar el código principal y sus tipos.

Pero por supuesto, hay algunas cosas no tan buenas sobre la solución. Obviamente, hay cierta sobrecarga de implementación en las características. Bueno, al implementar una sola característica, probablemente sería mucho más fácil simplemente omitir todo este asunto de los plugins, simplemente poner un par de nuevos componentes. No te preocupes por crear esos, usar esos envoltorios, poner todo este código en un lugar específico. La siguiente cosa, averiguar qué debería ser el plugin no es algo fácil, ¿verdad? Es una discusión arquitectónica que necesitas resolver, que tuvimos que resolver. Bien, ¿cuál es el núcleo real de la aplicación y dónde entran los plugins, verdad? Esta separación no es obvia. Y, sí, como descubrimos al iterar sobre esta solución, ¿verdad?, cuando comenzamos a anidar múltiples plugins, podría llevar a algunos problemas.

Así que, sí, ¿vale la pena? Yo diría, quiero decir, ¿vale la pena seguir con tal solución, implementar tal solución? Yo diría que depende del caso de uso, ¿verdad? Para nuestro caso, esto fue bastante útil ya que sabemos, enviar esas diferentes versiones a diferentes clientes, pero oye, tal vez los feature flags y en general, una buena separación del código es suficiente para tu caso, ¿verdad? Sin embargo, creo que esta solución podría tener una aplicación útil esta vez. Así que, dado lo ubicuas que son las herramientas de codificación de IA en este momento, las herramientas de generación de código, sabemos lo notorias que son, son por tocar diferentes lugares que no deberían tocar, ¿verdad? Y tener esta separación, básicamente forzar una característica dentro de una carpeta también puede hacer que sea mucho más fácil trabajar con estas herramientas, ¿verdad? Porque puedes ver claramente, bien, está tratando de poner el código en otro lugar, ¿verdad?

Así que, me gustaría conocer tus pensamientos. Creo que el gran Q&A en un segundo y sí, si te gustaría discutir, también puedes visitar nuestro stand, el stand de Workflow Builder, justo en la salida de allí. Cuando se trata de recursos, puedes encontrar la versión comunitaria de Workflow Builder en nuestro GitHub. Ese es el primer enlace. Y el segundo, uno de nuestros colegas preparó una demo de lo que esencialmente he mostrado. Sé que mostrar fragmentos de código aquí y allá podría no ser la mejor manera de aprender, pero si te gustaría echarle un vistazo, puedes simplemente visitar el GitHub y ver cómo funciona por ti mismo. Y sí, gracias. Muchas gracias por la charla. Gracias. Pensé que lo hiciste ver tan alcanzable y delineaste las formas, que como cuando necesitábamos los pros y los contras. Así que, sí, realmente informativo por allí. Sí, gracias. Sé que, bueno, resumir esto en 20 minutos, hay realmente mucho código.

No te preocupes. De acuerdo. Tenemos una pregunta de Velt. Entonces, ¿cómo decides o gestionas qué plugin se envía a qué cliente? Bueno, ¿cómo decidimos? Bueno, esto es en realidad parte del, yo diría, proceso de ventas. Así que, ya sabes, análisis de negocio, bien, lo que los clientes necesitan. Así que, tratamos de elegir un conjunto de características que realmente resuelvan sus necesidades, ¿verdad? No es una decisión de ingeniería per se, ¿verdad? Desde una perspectiva de ingeniería, nos aseguramos de que, bien, puedes hacer esos módulos, puedes conectarlos y desconectarlos, ¿verdad? Pero bien, lo que enviamos al cliente es en realidad, bien, lo que el cliente quiere, lo que el cliente necesita, ¿verdad? Así que, ahí es donde reside la decisión. Y es diferente para esos casos. Por supuesto. Sí, realmente, creo que escuchar al cliente es la respuesta allí.

De acuerdo. Y la siguiente es de Ryan. ¿Cómo escala este enfoque cuando tienes clientes cambiando constantemente los requisitos del producto que requieren banderas de características, cambios incrementales menores? ¿Estás duplicando mucho código para pequeños ajustes? Bueno, no creo que estemos duplicando mucho código, diría, bueno, para pequeños ajustes. Bien, una cosa, este es un caso de uso específico, ¿verdad? No es necesariamente un reemplazo para todas las banderas de características, todavía tienen un uso a veces, pero para nuestro tipo de producto, esto fue posible. No creo que estemos duplicando el código. Los principales desafíos que encontramos fueron, bien, si hay un plugin que modifica el mismo componente, bien, tal vez hay diferentes versiones de él, ¿verdad? Así que, esto fue probablemente algún desafío, pero no creo que tuviéramos desafíos con la aplicación del código. Genial.

De acuerdo, así que busca lo que tienen en común, intenta extraer el código compartido. Sí. Bien. De acuerdo. Muy bien. Entonces, si tienes componentes plug and play y muchos clientes, ¿cómo mantienes un seguimiento de todas las versiones, como una para Netflix, dos para Apple, tres para Paramount, es eso problemático para ti? Bueno, puede ser problemático, me imagino. Ahora mismo el enfoque que tenemos es que esencialmente la forma en que enviamos trabajo para builder ahora mismo es que enviamos el código, ¿verdad? Y llega a un cliente y puede ser modificado después, ¿verdad? Así que, lo que tenemos es en nuestro sistema de construcción es que con ciertas características, en realidad construimos una versión separada y la enviamos allí, ¿verdad? Y no está impactando a los otros clientes, ¿verdad? Así que, está algo separado allí. Pero sí, tal vez en el futuro tengamos algunos problemas con gestionarlos. Ahora mismo creo que no hay tantos plugins aún, así que es manejable. Bien. Muy bien.

De Mohan, ¿cómo haces pruebas automatizadas con tantas posibles combinaciones de plugins? Sí, ese es un desafío, ¿verdad? Pero no creo que tengamos una buena respuesta para esto para probar todas las combinaciones porque sí, puede haber lugares si te gustaría probarlo todo donde tienes un plugin agregando un componente, otro plugin agregando otro componente debajo de él, ¿verdad? Y pueden interactuar con algo. Así que, no creo que tengamos una buena respuesta sobre cómo hacerlo. Pero al mismo tiempo, todavía estamos desarrollando esta solución. Así que, creo que llegaremos allí eventualmente. Sí. Así que, ahora mismo es solo duplicación, pero será TBD. Sí. Si quieres probar todo, necesitas escribir muchas pruebas. De acuerdo.

Tenemos una pregunta de Brandon. ¿Puede esto ser usado para desactivar ciertas características dependiendo del entorno? Sí, creo que sí, ¿verdad? Bueno, puede ser integrado dentro de un proceso de construcción. Así que, por ejemplo, la versión que la versión funcional que tenemos en GitHub que es edición comunitaria que está disponible para todos no tiene todos los plugins. Pero la forma en que lo tenemos es que tenemos otro repositorio donde dentro del proceso de construcción, simplemente eliminamos algunos de esos plugins y esto se envía a este otro repositorio, ¿verdad? Así que, me imagino que esto podría hacerse basado en variables de entorno dentro del proceso de construcción básicamente solo borrando algunos archivos. Sí. De acuerdo. Así que, teóricamente posible. De acuerdo. Y tenemos una pregunta de Kiran. ¿Cómo gestionas la compatibilidad cuando el adaptador necesita cambiar? Sí.

Buena pregunta. No sé la respuesta a eso todavía. Lo que puedo añadir es que no he construido toda esta lógica. Solo he hecho ajustes aquí y allá. Pero sí, definitivamente tuvimos varias iteraciones de ello. Por ahora, no teníamos tantos plugins. Así que, cuando cambiamos adaptadores, cambiamos todos los plugins que usaban esos adaptadores. Fueron principalmente cambios cosméticos. Pero sí, esto se estaba propagando a esos plugins. Pero quiero decir, por ahora, creo que con el camino que hemos recorrido hasta ahora, creemos que estamos bastante seguros de que los adaptadores no deberían necesitar cambiar tanto. Sí. Así que, está funcionando hasta ahora. Pero creo que toda la audiencia te está ayudando a definir tu hoja de ruta del producto, ¿eh? Sí. Seguro.

Bien. Entonces, ¿cómo se puede lograr esto sin reinventar la rueda? ¿Hay algo que podamos reutilizar del proceso? ¿Sin reinventar la rueda? No estoy seguro de haber entendido bien la pregunta. Sí. Así que, creo... Y la persona puede salir del anonimato, por cierto. Pero creo que creen que tal vez implementar esto es como re... Bien. Así que, sí. Como mencioné, había un enlace allí, una presentación donde puedes ver una demostración de ello. Así que, podemos probarlo. Tal vez haya algo que puedas aprovechar de ello. Bueno, una cosa que incluso sin entrar en todo ese asunto con adaptadores y demás, creo que una cosa que es muy fácil de implementar es este plugin SLint que puede ayudar sin entrar en este diseño plug and play puede realmente ayudar a gestionar las importaciones dentro de la aplicación. Como si supieras, bien, al construir una nueva característica, debería permanecer dentro de estas carpetas, ¿verdad? Puedes implementar solo estos plugins que obligarán a tu equipo de desarrollo a mantener este código que está relacionado consigo mismo en un solo lugar. Creo que eso es lo más fácil que puedes tomar de esto, incluso si no quieres entrar en toda la complejidad allí. Sí. Sí, seguro.

Bien. Tenemos una pregunta de Melinda. Mi equipo no envía compilaciones separadas para múltiples clientes. ¿Recomendarías esta configuración solo para el caso de uso de querer hacer fácil eliminar pruebas A-B antiguas o feature flags, o es demasiado trabajo adicional? Bueno, no sé cómo es tu proyecto, ¿verdad? Creo que hay muchas consideraciones allí. Fue útil para nosotros, pero realmente no puedo decirte si será útil en cualquier proyecto, ¿verdad? Si tienes un conjunto diferente de restricciones. Sí, su restricción es que no tienen compilaciones separadas para múltiples clientes, solo una compilación. Sí. También pensaría en términos de, porque hay otros pros como, está bien, no envías el código. Así que un tamaño de paquete más pequeño y así sucesivamente. ¿Qué tan importante es eso? Eso podría ayudarte con la decisión. Sí. Una vez más, definitivamente es más fácil probarlo con algo como una nueva característica, porque si tienes una característica existente y te gustaría separarla en un plugin, esto puede ser realmente más trabajo. Así que diría para resolver esto, ¿verdad?, lo que haría si estuviera en tal decisión, tal vez probaría con una sola cosa, ¿verdad? Porque no tienes que usarlo en ningún lugar. Tal vez puedas probarlo y ver, está bien, ¿es realmente suficiente trabajo adicional para nuestro caso de uso? ¿Es la experiencia del desarrollador lo suficientemente buena para nuestro equipo? Todo es un poco diferente, ¿verdad? Sí. Así que quien sea, o Melinda puede seguir contigo después y compartir más sobre cómo son sus entornos. Sí. Sí.

Eso es bueno. Bien. Tenemos tiempo para una pregunta más. ¿Pueden los plugins ser divididos en código por el empaquetador o siempre terminarán en el paquete principal? ¿Podrías repetir eso? Sí, por supuesto. ¿Pueden los plugins ser divididos en código por el empaquetador o siempre terminarán en el paquete principal? Sí, podrían ser divididos en código. Es solo una cuestión de cómo configuras la compilación, creo. Sí. Sí. Bien. Entonces la respuesta es sí. Muy bien. Bien. Esas son todas las preguntas que vamos a abordar. Habla con él después. Así que todos denle un aplauso.