Продвинутая работа с подписками в еvent-driven архитектуре в JavaScript

[@bakhirev]

Круто конечно, но мне кажется тему раскрыл Миша Давыдов в феврале 2012 на Субботнике. Он говорил о песочнице для модулей. Вместо одного хранилища всех событий, возможно стоит создавать экземпляр песочницы для каждой группы модулей. К тому же, насколько я понял, у вас модули могут слушать события друг-друга, что не верно с точки зрения архитектуры.

1. Каждый модуль может только публиковать/слушать свои события
2. Есть песочница которая управляет группой модулей (она же устанавливает связи между их событиями)
3. Песочниц может быть много, в зависимости от масштабов приложения.

Получается что если у меня есть модуль Message, и он публикует Message_show, то это событие может быть только внутри файла Controller_Message, который разруливает все события модулей сообщения, всплывающих окон и т.п. Ну и для других соответственно. Например Controller_Data — точно не должен работать с модулями сообщений и связывает только события связанные с данными.

[@confa]

Действительно, локальные события в модулях не должны выходить за их пределы, и это правильно с точки зрения архитектуры.
Но, во-первых, наш модуль никоим образом не навязывает какой бы то ни было стиль программирования, а всего лишь
является инструментом для анализа уже существующих событий. Т.е. глядя на чужой проект, написанный в таком стиле,
знание о «песочницах» не поможет вам разобраться.
Во-вторых, в приложениях с единой точках входа информации единого медиатора избежать практически нереально.
Примером таких точек входа является общение между встроенными приложениями через их API, принятие информации
по WebSocket'ам и много другое.

[@azproduction]

Штука крутая! Только заголовок статьи очень смущает :) Читаешь его и думашь, что статья будет про кодописание, а не инструмент/документацию.

[@azproduction]

Кстати, с одной стороны песочница это крутая штука, но она может превратиться в большой слой бюрократии если постоянно все везде ограничивать. Те когда нужно получать какие-то новые данные приложения приходится добавить этот модуль в песочницу, а потом вызвать его в Модуле. Похоже на антипаттерн Павлик Морозов.

В свою очередь интерфейс CommonJS модулей так же является своеобразной песочницей и эта песочница положительно сказывается на качестве продукта и не вставляет палок в колеса.

[@bakhirev]

Насколько сложно поддерживать и модифицировать такой проект? Как выглядит код, где ядро определяет кто какие события получает?

[@bakhirev]

не навязывает какой бы то ни было стиль программирования

Тогда ещё вопрос. Если у меня синтаксис отличается, например слушатели и события объявляются как-нибудь вот так:
event.listen("something", function(data) { ... }); event.trigger("something", data);
Есть какой-нибудь функционал, чтобы без гемора и копания в коде начать искать вместо mediator.on / off -> event.listen / trigger?

[@confa]

Модуль capo поддерживает следующие методы для подписки: «on|listen|listenTo|listenToOnce|once|subscribe»,
для триггеров — «trigger|publish|emit». Поиск по этим шаблонам будет происходить по умолчанию, без
дополнительной конфигурации.
Имя же объекта-медиатора указывается опцией (по дефолту «mediator»). Пример для
консоли -o event, для работы через API — метод event:
capo(path).event('event')...
Плагин поддерживает расширение методов и триггеров через файл конфигурации.

[@confa]

Больше об event-driven архитектуре 6 Марта на Вебинаре от Binary Studio.

[@StreetStrider]

По-моему, наследником событий является FRP. Это, по сути, те же самые подписки, но «в другую сторону». Плюс в том, что FRP в коде как раз и выражает (практически дословно) кто на кого подписан.

А описанный вами минус — неопределенность триггеров и подписчиков — по мне вообще является плюсом событийной модели, потому что как раз независимость источника от приёмников события (да и наоборот) как раз постулируется как преимущество подписки в противовес прямому вызову.

[@confa]

С моей точки зрения и да и нет, поскольку взамен преимуществ слабосвязанной системы мы получаем некоторые сложности при разработке или адаптации на проекте.

[@StreetStrider]

Похоже, я вас не понял. Мой поинт в том, что если зависимость есть, то в FRP она будет выражена явно, в виде формулы. В событийной схеме — нет. А зависимости есть всегда. Если в нашей модели компонент Б зависит от компонента А, то в FRP, в коде, мы получим ровно эту зависимость. Это не является сильной связанностью.

мы получаем некоторые сложности при разработке или адаптации на проекте

О каких сложностях идёт речь?

[@confa]

FRP это немного другая парадигма, и я не затрагивал ее в своей статье. Она также имеет свои преимущества и недостатки.

Я имел в виду сложность отслеживания ивентов с ростом проекта в событийной модели. Событие триггерится и слушается сразу в нескольких компонентах. Следовательно части кода, отвечающие за это, находятся в разных файлах или и того хуже — проектах. Можно еще представить ситуацию, когда подписка на ивент влечет за собой триггер другого ивента. Исходя из личного опыта, такого рода «цепочки» порой очень трудно отслеживать.

[@bakhirev]

Скорее даже так: мы получаем сложности, когда система становиться очень большой. Иногда появляются магические баги и трудно понять кто сгенерировал лишнее событие. Автор спасибо, подтолкнул к некоторым идеям по оптимизации. В данный момент, например у меня, очень много такого трудно-читаемого кода:

    utils.event.listen("difficulty__update", function (index) {
        global.sudoku.difficulty = index;
    });

    utils.event.listen("helper__click", function () {
        utils.event.trigger("board__select_values");
    });

    utils.event.listen("popup_window__hidden", function () {
        utils.event.trigger("main_menu__show");
    });\\

    utils.event.listen("board__create", function (nodes) {
        utils.event.trigger("board_animation__init", nodes);
        utils.event.trigger("memory__load");
    });

    utils.event.listen("splash_screen__hidden", function () {
        utils.event.trigger("main_menu__show");
    });

[@turbo_exe]

на одном проекте юзал похожую библиотеку. называлась PubSub.js. правда, она была без такого инструментария, как в топике.