В этой статье я познакомлю вас с Rete.js, фреймворком для создания редакторов узлов с настройкой и встроенными функциями для обработки. С момента создания до текущего состояния (бета-версия 2) я представлю краткую историю фреймворка, подчеркнув его эволюцию и рост.
Хотя в этой статье мы не будем углубляться в подробные руководства по использованию Rete.js, вы можете легко найти их на официальном сайте по адресу retejs.org. Вместо этого вы можете оставить свой отзыв в разделе комментариев ниже или задать вопросы на нашем Discord сервере.
История
Мой интерес к визуальному программированию начался еще в 2017 году, когда мне пришла в голову идея создать инструмент для обработки данных через графический интерфейс. На тот момент я уже был знаком с редактором узлов Blender и Blueprint Unreal Engine, но не мог найти готовых решений на JS, отвечающих моим потребностям.
Итак, я решил разработать собственное решение с использованием d3.js. Я начал с графического интерфейса редактора узлов, который по возможностям был аналогичен вышеупомянутым решениям. Затем я сосредоточился на обработке этих схем. Моя цель состояла в том, чтобы создать библиотеку, которая позволила бы мне создавать различные типы узлов, не беспокоясь ни о чем, кроме входных данных, которые должен получить узел, и о выводе, который он должен предоставить.
Пакет d3-node-editor
был создан для удовлетворения моих потребностей в интерфейсе, который мог бы создавать узлы различных типов и предлагать функции обработки данных. Демо все еще доступно на Codepen. Вскоре после того, как он получил несколько звезд в репозитории, я заметил, что он вызывает интерес и у других. Это побудило меня переключить свое внимание с исходного проекта на библиотеку, и я начал думать, как ее можно улучшить.
Одним из первых вопросов, который я решил, было то, как сделать его настраиваемым и гибким. Было важно, чтобы новые функции можно было добавлять, не нарушая основной кодовой базы. Это было особенно важно, поскольку критические изменения могли вызвать проблемы у пользователей, которые полагались на библиотеку в своих проектах. Чтобы решить эту проблему, я решил реализовать событийную архитектуру.
Во время реализации новой архитектуры я решил дать ей более короткое имя, доступное на NPM. Так родился фреймворк в комплекте с пакетом под названием rete
. Кроме того, реализована система плагинов, позволяющая разбивать функционал на разные пакеты и устанавливать их по требованию. Со временем я также добавил возможность рендеринга узлов с использованием различных фреймворков, включая Angular, Vue.js и React.js.
По мере реализации основного функционала фреймворк набирал популярность как с моим участием, так и без него (спасибо тем, кто упомянул его в статьях или поделился ссылками). Я посвятил время исправлению ошибок и добавлению функций, но в основном это было обусловлено мотивацией и внешними факторами.
В результате мы достигли стадии, когда у фреймворка есть вторая основная версия в бета-версии.
Недостатки v1
По прошествии нескольких лет с момента выхода первого релиза могу подытожить его недостатки. Я говорю, что первую версию не следует использовать? Отчасти да, поэтому я хотел бы обсудить это здесь. Стоит ли использовать v1, пока v2 все еще находится в стадии бета-тестирования? Безусловно, потому что первая версия была тщательно протестирована сообществом.
Время и навыки
Одна из неприятных истин о проектах с открытым исходным кодом: библиотеки или фреймворки обычно предоставляются «как есть», особенно если они разрабатываются исключительно на энтузиазме. Качество этих решений напрямую зависит от времени и навыков, вложенных в них. В результате существует вероятность того, что ваша проблема может остаться без ответа или ошибка не будет исправлена годами. Поэтому очень важно правильно внести свой вклад в проект, которым вы увлечены.
Дизайн
На ранних этапах, таких как этап проектирования, некоторые непредвиденные факторы могут оказать существенное влияние на последующие этапы.
Давайте рассмотрим критические моменты:
- TypeScript: не использовался с самого начала, начиная с версии 1.0.0. Поддержка статической типизации может быть улучшена, но для значительных улучшений могут потребоваться критические изменения.
- Абстракция компонентов: позволяет создавать узлы различных типов, упрощая процесс разработки, но также ограничивая разработчиков. Хотя функция импорта/экспорта является встроенной, этот подход может привести к путанице при различении узлов и компонентов.
- Архитектура, основанная на событиях, и система плагинов: они, несомненно, оказали значительную помощь с точки зрения гибкости. Однако отладка может быть довольно сложной. Все события были сосредоточены в ядре. Плагины могут создавать свои собственные события, что приводит к огромному количеству неизолированных событий. Также подключенные плагины — это просто список, где порядок подключения имеет решающее значение.
- Движок: обработка графов была ранее неизведанной территорией. Изначально я планировал работать только с потоком данных, но из-за ограничений реализации поддержка рекурсии была невозможна. В итоге был разработан плагин задач, который частично решил проблему создания решений потока управления поверх существующего движка.
Документация
В первых версиях я использовал GitHub Wiki для документации, а позже переключился на Read the Docs. Однако я все еще боролся с некоторыми ограничениями Markdown, поэтому решил создать веб-сайт под названием rete.js.org.
Несмотря на то, что сайт предоставил некоторую документацию и примеры, он не охватывает всего, как я понял из вопросов на GitHub.
Сборка пакетов
Я обнаружил целый список подводных камней. Во-первых, полагаться на Rollup и надеяться на бесшовную интеграцию было наивно. Я неоднократно сталкивался с неинформативными ошибками при попытке использовать плагины. Во-вторых, управление несколькими пакетами при работе с HMR является серьезной проблемой. Особенно при использовании npm link
, что может вызвать проблемы со связыванием зависимостей, требующие нескольких часов отладки. В результате решение этих вопросов может занять много времени.
Что было сделано?
Разработка второй версии фреймворка и сопутствующих материалов потребовала во много раз больше усилий, чем первая версия. Кодовая база была полностью переписана с нуля с упором на полную поддержку TypeScript и гибкость настройки. Единственное, что осталось неизменным, это узнаваемое визуальное оформление.
В целом, моей целью не было реализовать множество функций. Гибкость и расширяемость имеют более высокий приоритет, чем множество функций, которые можно легко включить с помощью флага, например enableThisCoolFeature
. Конечно, здорово иметь много функций, но наряду с этим мы также получим десятки опций, каждая из которых требует еще 5-10 опций для настройки этих функций.
Архитектура
Новая версия фреймворка отличается архитектурой, ориентированной на TypeScript и более масштабируемой. Он включает в себя два ключевых компонента: альтернативу архитектуре, основанной на событиях, и каскадную систему плагинов. Короче говоря, плагины можно подключать не только к экземпляру редактора, но и к другим плагинам, напоминая каскад. Это позволяет передавать данные, также известные как сигналы, от родительского плагина ко всем дочерним плагинам, где их можно преобразовать или предотвратить.
Подробнее см. на странице Система плагинов.
Пресеты
Ключевым нововведением в этой версии является реализация пресетов. Это набор готовых функций, которые можно использовать по умолчанию или заменить альтернативным пресетом. Вместо использования таких флагов, как enableThisCoolFeature
, пресеты можно добавлять без необходимости изменять исходный код плагина.
Для получения дополнительной информации, пожалуйста, обратитесь к разделу Пресеты.
Двигатель
Движок теперь реализован в отдельном пакете под названием rete-engine
. Он предназначен для обработки схем с использованием подходов потока данных и потока управления, а также их комбинаций. Эта реализация более гибкая, чем в предыдущей версии, и ее легче понять с теоретической точки зрения в отношении различных проблем, решаемых этими подходами.
Подробнее в статье Двигатель
Rete CLI
Этот инструмент существует с первой версии, но в новой версии были внесены значительные улучшения, включая решение некоторых проблем. Это особенно полезно, когда проект разделен на разные пакеты и репозитории. Инструмент теперь по умолчанию поддерживает TypeScript, а также линтинг и средство запуска тестов. Устранена проблема с интеграцией полифиллов, из-за которой полифиллы исключались из пакетов, чтобы уменьшить их размер, что вызывало ошибки в определенных средах, где они не включались автоматически, например, regeneratorRuntime не определен. Теперь эта проблема решена с помощью @babel/runtime.
Подробнее см. в документации Rete CLI.
Рете Кит
Идея создания этого инструмента возникла не сразу, но он оказался чрезвычайно полезным как для целей тестирования, так и для ознакомления других разработчиков с проектом на предпочитаемом ими стеке, таком как Angular, React.js или Vue.js.
Этот инструмент делает несколько вещей: создает базу плагинов (что было сделано в предыдущей версии Rete CLI), создает приложение с использованием Rete.js и выполняет массовую сборку во время разработки. Подробнее об этом можно прочитать в статье Rete Kit. Здесь я просто хочу выделить создание приложения для разных стеков с необходимыми функциями, что оказалось чрезвычайно полезным функционалом. Всего одной командой rete-kit app --next
можно получить работающее приложение с редактором.
Узнать подробности о Rete Kit
Рете QA
Наконец, в структуру был добавлен еще один инструмент, чтобы поддерживать качество, не тратя слишком много времени. Этот инструмент представлен в виде отдельного пакета под названием rete-qa
и отвечает за выполнение регрессионных тестов пользовательского интерфейса в разных стеках и браузерах. Первый аспект достигается с помощью Rete Kit, а второй — с помощью Playwright под капотом, который запускает все тесты для каждого стека на Chromium, WebKit и Firefox.
Подробнее читайте в статье Обеспечение качества.
Документация и примеры
На этот раз много сил было вложено в разработку документации, примеров и самого сайта. Сайт был перенесен на Nuxt 3 с использованием сопутствующих модулей, что, к сожалению, повлияло на время релиза.
Добавлено множество статей, в которых представлен обзор экосистемы проекта и различных формальностей, а также страница часто задаваемых вопросов и руководства по различным частям функционала, а также ссылки на примеры.
В настоящее время существует 32 примера, большинство из которых размещены на Codesandbox.
Кроме того, для улучшения поиска был интегрирован DocSearch Algolia.
Заключение
История Rete.js началась несколько лет назад, когда трудно было найти настраиваемые решения JavaScript. В настоящее время Rete.js продолжает развиваться и значительно улучшился, хотя все еще находится в стадии бета-тестирования. Он более гибкий и расширяемый, чем его предыдущая версия. Благодаря более тщательному проектированию и созданию инструментов тестирования, а также упору на поддержку TypeScript, Rete.js стал еще более надежным и гибким инструментом для создания редакторов узлов.