En este artículo, le presentaré Rete.js, un marco para crear editores de nodos con personalización y funciones integradas para el procesamiento. Desde su inicio hasta su estado actual (versión 2 beta), proporcionaré una breve historia del marco, destacando su evolución y crecimiento.

Si bien este artículo no profundizará en guías detalladas sobre cómo usar Rete.js, puede encontrarlas fácilmente en el sitio web oficial en retejs.org . En su lugar, puede dejar sus comentarios en la sección de comentarios a continuación o hacer preguntas en nuestro servidor de Discord .

Historia

Mi interés por la programación visual comenzó en 2017 cuando se me ocurrió la idea de crear una herramienta para el procesamiento de datos a través de una interfaz gráfica. En ese momento, ya estaba familiarizado con el editor de nodos de Blender y Blueprint de Unreal Engine, pero no pude encontrar ninguna solución lista para usar en JS que satisficiera mis necesidades.

Entonces, decidí desarrollar mi propia solución usando d3.js. Comencé con una interfaz gráfica de editor de nodos que tenía capacidades similares a las soluciones antes mencionadas. Luego me concentré en procesar estos esquemas. Mi objetivo era crear una biblioteca que me permitiera crear diferentes tipos de nodos sin preocuparme por nada más que los datos de entrada que el nodo debería recibir y la salida que debería proporcionar.

El d3-node-editorpaquete se creó para satisfacer mis necesidades de una interfaz que pudiera crear nodos de varios tipos y ofrecer funcionalidad de procesamiento de datos. La demostración todavía está disponible en Codepen. Pronto, después de que recibió algunas estrellas en el repositorio, noté que también estaba ganando el interés de otros. Esto me motivó a cambiar mi enfoque de mi proyecto original a la biblioteca, y comencé a considerar cómo podría mejorarse.

Uno de los primeros problemas que abordé fue cómo hacerlo personalizable y flexible. Era importante que se pudieran agregar nuevas funciones sin interrumpir el código base principal. Esto fue especialmente crucial porque los cambios importantes podrían causar problemas a los usuarios que confiaron en la biblioteca en sus proyectos. Para resolver este problema, decidí implementar una arquitectura basada en eventos.

Durante la implementación de la nueva arquitectura, decidí darle un nombre más corto que estaba disponible en NPM. Así nació el marco, completo con un paquete llamado rete. Además, se implementó el sistema de complementos que permite dividir la funcionalidad en diferentes paquetes e instalarlos bajo demanda. Con el tiempo, también agregué la capacidad de representar nodos usando una variedad de marcos, incluidos Angular, Vue.js y React.js.

A medida que se implementó la funcionalidad principal, el marco ganó popularidad con y sin mi participación (gracias a quienes lo mencionaron en artículos o enlaces compartidos). Dediqué tiempo a corregir errores y agregar funciones, pero esto se debió principalmente a la motivación y a factores externos.

Como resultado, ahora hemos llegado a una etapa en la que el marco tiene una segunda versión principal en versión beta.

Desventajas de v1

Después de varios años desde el primer lanzamiento puedo resumir sus desventajas. ¿Estoy diciendo que la primera versión no debe usarse? En parte sí, por eso me gustaría discutirlo aquí. ¿Vale la pena usar la v1 mientras la v2 todavía está en beta? Absolutamente, porque la primera versión ha sido probada extensamente por la comunidad.

tiempo y habilidades

Una de las desafortunadas verdades sobre los proyectos de código abierto: las bibliotecas o los marcos generalmente se proporcionan "tal cual", especialmente si se desarrollan únicamente por entusiasmo. La calidad de estas soluciones depende directamente del tiempo y las habilidades invertidas en ellas. Como resultado, existe la posibilidad de que su problema quede sin respuesta, o que un error no se solucione durante años. Por lo tanto, es crucial contribuir a un proyecto que te apasione de la manera correcta.

Diseño

Durante las primeras etapas, como la fase de diseño, algunos factores imprevistos pueden tener un impacto significativo en las etapas posteriores.

Repasemos los puntos críticos:

• TypeScript : no se usó desde el principio, desde la versión 1.0.0. Se podría mejorar la compatibilidad con la escritura estática, pero las mejoras significativas pueden requerir cambios importantes.
• Abstracción de componentes : permite la creación de nodos de diferentes tipos, simplificando el proceso de desarrollo pero también restringiendo a los desarrolladores. Aunque la función de importación/exportación está integrada, este enfoque puede causar confusión al distinguir entre nodos y componentes.
• Arquitectura basada en eventos y sistema de complementos : sin duda, han brindado una importante ayuda en términos de flexibilidad. Sin embargo, puede ser bastante difícil de depurar. Todos los eventos se concentraron en el núcleo. Los complementos pueden crear sus propios eventos, lo que genera una cantidad abrumadora de eventos que no están aislados. Además, los complementos conectados son solo una lista, donde el orden de conexión es crucial.
• Motor : el procesamiento de gráficos era un territorio previamente desconocido. Inicialmente, había planeado trabajar solo con el flujo de datos, pero debido a las limitaciones de implementación, el soporte de recursividad no fue posible. Eventualmente, se desarrolló el complemento de tareas , que resolvió parcialmente el problema de crear soluciones de flujo de control sobre el motor existente.

En las primeras versiones, usé GitHub Wiki para la documentación y luego cambié a Read the Docs. Sin embargo, todavía estaba luchando con algunas limitaciones de Markdown, así que decidí crear un sitio web llamado rete.js.org .

A pesar de que el sitio proporcionó algo de documentación y ejemplos, no cubría todo como descubrí a partir de preguntas en GitHub.

Construcción de paquetes

He descubierto una letanía de trampas. En primer lugar, confiar en el Rollup y esperar una integración perfecta fue ingenuo. He encontrado repetidamente errores no informativos al intentar usar los complementos. En segundo lugar, administrar múltiples paquetes mientras se trabaja con HMR es un desafío importante. Especialmente cuando se usa npm link, lo que puede causar problemas con la vinculación de dependencias que requieren varias horas de depuración. Como resultado, resolver estos problemas puede llevar mucho tiempo.

¿Lo que se ha hecho?

El desarrollo de la segunda versión del marco y los materiales que lo acompañan ha requerido muchos más esfuerzos que la primera versión. El código base fue completamente reescrito desde cero, con un enfoque en el soporte completo de TypeScript y la flexibilidad en la personalización. Lo único que se mantuvo sin cambios es el diseño visual reconocible.

En general, mi objetivo no era implementar muchas características. La flexibilidad y la extensibilidad tienen una prioridad más alta que una multitud de funciones que se pueden habilitar fácilmente con una bandera como enableThisCoolFeature. Por supuesto, es genial tener muchas funciones, pero junto con esto también terminaríamos con docenas de opciones, cada una de las cuales requiere de 5 a 10 opciones más para personalizar estas funciones.

Arquitectura

La nueva versión del marco presenta una arquitectura que es TypeScript primero y más escalable. Incluye dos componentes clave: una alternativa a la arquitectura basada en eventos y un sistema de complementos en cascada. En resumen, los complementos se pueden conectar no solo a la instancia del editor, sino también a otros complementos, como una cascada. Esto permite que los datos, también conocidos como señales, se transmitan desde el complemento principal a todos los complementos secundarios, donde se pueden transformar o evitar.

Para obtener más detalles, consulte la página del sistema de complementos .

Preajustes

La innovación clave en esta versión es la implementación de ajustes preestablecidos. Se trata de un conjunto de funciones listas para usar que se pueden usar de forma predeterminada o reemplazar con un ajuste preestablecido alternativo. En lugar de usar indicadores como enableThisCoolFeature, se pueden agregar ajustes preestablecidos sin necesidad de modificar el código fuente del complemento.

Para obtener más información, consulte la sección Presets .

Motor

El motor ahora se implementa en un paquete separado llamado rete-engine. Está diseñado para procesar esquemas utilizando enfoques de flujo de datos y flujo de control, así como sus combinaciones. Esta implementación es más flexible que la de la versión anterior y es más fácil de entender desde una perspectiva teórica sobre los diferentes problemas que resuelven estos enfoques.

Obtenga más información en el artículo Motor

Rete CLI

Esta herramienta existe desde la primera versión, pero en la nueva versión se han realizado mejoras significativas, incluida la resolución de algunos problemas. Esto es particularmente útil cuando un proyecto se divide en diferentes paquetes y repositorios. La herramienta ahora es compatible con TypeScript de forma predeterminada, junto con Linting y Test Runner. Se solucionó el problema con la integración de polyfill, por el cual los polyfills se excluían de los paquetes para reducir su tamaño, lo que provocaba errores en ciertos entornos donde no se incluían automáticamente, como regeneratorRuntime no está definido . Este problema ahora se ha resuelto utilizando @babel/runtime .

Para obtener más detalles, consulte la documentación de Rete CLI .

Kit Rete

La idea de crear esta herramienta no surgió de inmediato, pero demostró ser extremadamente útil tanto para fines de prueba como para familiarizar a otros desarrolladores con el proyecto en su pila preferida, como Angular, React.js o Vue.js.

Esta herramienta hace varias cosas: crea una base de complementos (lo que hizo la versión anterior de Rete CLI), crea una aplicación usando Rete.js y realiza una compilación masiva durante el desarrollo. Puedes leer más sobre esto en el artículo de Rete Kit . Aquí solo quiero destacar la creación de una aplicación para diferentes pilas con las características necesarias, que resultó ser una funcionalidad extremadamente útil. Usando solo un comando, rete-kit app --nextpuede obtener una aplicación que funcione con un editor.

Consulta los detalles en Rete Kit

control de calidad

Finalmente, se ha agregado otra herramienta al marco para mantener la calidad sin perder demasiado tiempo. Esta herramienta se presenta como un paquete separado llamado rete-qay es responsable de realizar pruebas de IU de regresión en diferentes pilas y navegadores. El primer aspecto lo logra Rete Kit, mientras que el segundo lo logra Playwright bajo el capó, que ejecuta todas las pruebas para cada pila en Chromium, WebKit y Firefox.

Se pueden encontrar más detalles en el artículo Garantía de calidad .

Documentación y ejemplos

Esta vez, se puso mucho esfuerzo en desarrollar documentación, ejemplos y el sitio web en sí. El sitio web se migró a Nuxt 3 con el uso de módulos adjuntos, lo que desafortunadamente tuvo un impacto en el tiempo de lanzamiento.

Se agregaron muchos artículos, que brindan una descripción general del ecosistema del proyecto y varias formalidades, así como una página de preguntas frecuentes y guías para diferentes partes de la funcionalidad, junto con enlaces a ejemplos.

Actualmente, hay 32 ejemplos, la mayoría de los cuales están alojados en Codesandbox.

Además, DocSearch de Algolia se ha integrado para mejorar la experiencia de búsqueda.

Conclusión

La historia de Rete.js comenzó hace varios años cuando era difícil encontrar soluciones JavaScript personalizables. Actualmente, Rete.js continúa evolucionando y ha mejorado significativamente, aunque todavía está en versión beta. Es más flexible y extensible que su versión anterior. Con un diseño más cuidado y la creación de herramientas de prueba, así como un enfoque en el soporte de TypeScript, Rete.js se ha convertido en una herramienta aún más confiable y flexible para crear editores de nodos.