EventEmitter и а-синхронность?

Question

[vasIvas]

Возможно ли при помощи EventEmitter.. не знаю, как сказать... создать асинхронную цепочку событий?

Comments

[Юрий Пузыня]

Приведите более подробное описание пожалуйста... Имея больше информации, думаю я смогу ответить на ваш вопрос.

[vasIvas]

Юрий Пузыня: дело какое... Делаю для gulp который редактирует файл.
Структура такая, что поймав событие от gulp я хочу послать свое,
чтобы последовательно редактировать файл. Тут все просто, но есть
мнение, что если мое событие не будет синхронным, то какой-то другой
плагин может отредактировать файл в промежуток между моим изменением,
тем самым нарушит роботу моего плагина.

Answer 1

[Юрий Пузыня]

Сам по себе EventEmitter.emit - синхронная функция, что может многих удивить.

process.on('ev', function() {
  console.log('ev');
});
(function() {
  console.log('a');
  process.emit('ev');
  console.log('b');
} ());
//a
//ev
//b

Но на этом синхронность заканчивается. Т.е. например если process.on('ev', cb) был вызван не столь тривиально и в нескольких местах в асинхронном коде, я бы не советовал вам даже пытаться понять какой из cb будет вызван первым. Я не утверждаю, что у вас не получится вычислить последовательность вызова, но говорю что вычислять ее в корне неправильно - это антипаттерн. Если вы хотите быть уверенным в последовательности вызова используйте коллбеки или промизы, но не события.

Comments

[vasIvas]

Спасибо за ответ и объясните ещё вот какую вещь.
Почему очередь в событиях, это антипатерн?

Для примера, если взять обычный observer, то добавление
слушателей происходит в массив. При возникновении события
массив будет перебираться по порядку. Это уже антипатерн получается?
Или вот если я возьму и объектам задам приоритет, а затем
буду добавлять их в observer при помощи адаптера, в котором они,
эти объекты, будут сортироваться по приоритетам. Это по Вашему тоже антипатерн?

[Юрий Пузыня]

Очередь в событийной модели сама по себе не является антипаттерном.

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

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

Шаблон "Обозреватель", который вы упомянули в вопросе, характеризуется, в числе прочего, слабой связью с подчиненными, т.е. он почти ничего (а в идеале вообще ничего) не знает о структуре подчиненных. Событийная модель, как частный случай обозревателя - это как раз та идеальная ситуация.

[vasIvas]

Юрий Пузыня: Спасибо! И напоследок, не могли бы Вы сказать, какие promises нужно использовать? Гугл их много версий выдает, а вот какие самые лучшие?

[Юрий Пузыня]

Я бы посоветовал начать с тех, которые npm install promise. Это основа основ. Если вы поймете, что вам в них чего-то не хватает, то скорее всего сами придете к библиотеке Q.

[vasIvas]

Юрий Пузыня: Спасибо.