Что такое Event Emitter и почему его спрашивают на собеседовании?

• Евгений Парома, сеньор-фронтенд-разработчик с 6-летним опытом, обсуждает важность паттерна EventEmitter.  

• Объясняет, что на собеседованиях часто спрашивают об EventEmitter, и обещает разобрать его использование и реализацию.  

• EventEmitter создаёт объекты с событиями, которые могут иметь название и данные.  

• Подписчики могут подписаться на события несколько раз в разных частях приложения.  

• EventEmitter вызывает обработчики событий в порядке добавления.  

• EventEmitter используется для синхронизации кэшей и инверсии управления.  

• Кэш — это копия данных, которая может храниться в разных местах, например, в LocalStorage или DOM.  

• Данные — это источник истины, например, массив пользователей.  

• Два основных способа синхронизации кэшей: обновление данных и кэша отдельно или одновременное обновление данных и кэша.  

• Оба способа имеют недостатки при большом количестве кэшей и данных.  

• EventEmitter позволяет кэшам самостоятельно синхронизироваться с данными без необходимости ручного обновления.  

• Пример с TodoList показывает, как EventEmitter может быть использован для обновления кэшей.  

• Класс Store содержит основные данные, а классы отображения — кэши.  

• При изменении данных EventEmitter оповещает кэши об обновлениях.  

• Текущий подход требует ручного обновления всех кэшей при каждом изменении данных.  

• Это приводит к ошибкам и неудобству в управлении кэшами.  

• EventEmitter помогает избежать необходимости ручного обновления всех кэшей.  

• EventEmitter реализует инверсию управления, аналогичную Dependency Injection и Containers.  

• Это позволяет разделить управление данными и отображением, что улучшает структуру приложения.  

• Модули могут быть связаны напрямую, вызывая функции друг друга.  

• В крупных приложениях это создаёт хаос и усложняет отладку.  

• Хаотическая связанность модулей затрудняет внесение изменений.  

• EventEmitter позволяет модулям общаться через события, а не напрямую.  

• Модули становятся независимыми друг от друга, что упрощает отладку.  

• Паттерн EventEmitter реализует Low-Coupling.  

• Плюсы: каждый модуль можно рассматривать по отдельности.  

• Минусы: система становится сложнее для понимания.  

• Паттерн EventEmitter полезен для управления событиями в приложении.  

• В примере кода методы Store вызывают другие классы, создавая циклические зависимости.  

• Циклические зависимости плохо обрабатываются сборщиками и могут привести к бесконечным циклам.  

• Пример показывает, как зависимости могут заплетаться в клубок в больших приложениях.  

• Создаём класс EventEmitter с методами on и emit.  

• Метод on принимает событие и callback, метод emit вызывает все callback.  

• Метод unsubscribe может возвращать функцию для отписки от события.  

• Используем map для хранения обработчиков по событиям.  

• Создаём тип Listener для хранения обработчиков.  

• Метод on добавляет обработчики в map, метод emit вызывает нужные обработчики.  

• Получаем множество линеров по ивенту.  

• Если список линеров не существует, создаём новый сет с одним коллбеком.  

• При наличии списка добавляем коллбек в существующий сет.  

• Отписываемся, вызывая функцию, возвращённую из метода `on`.  

• Удаляем коллбек из сета линеров.  

• Получаем сет линеров из карты.  

• Итерируемся по сету и вызываем коллбеки.  

• Слабая типизация неудобна в использовании.  

• Легко допустить ошибки при передаче данных.  

• Нет автодополнения типов.  

• Импортируем `EventEmitter`.  

• Тестируем работу обработчиков в консоли.  

• Используем дженерики для строгой типизации.  

• Создаём структуру для хранения типов событий.  

• Применяем автодополнение типов.  

• Получаем тип значения по ключу из структуры событий.  

• Связываем параметры с помощью дженериков.  

• Для событий с типом `void` нужно явно указывать `undefined`.  

• Решаем проблему с помощью условного выражения.  

• Используем EventEmitter для оповещения при изменении данных.  

• Создаём публичное поле `events` в классе.  

• Указываем необходимые события для оповещения.  

• Оповещаем о изменении данных с помощью `events.emit`.  

• Подчёркивается удобство использования EventEmitter.  

• Разделение изменений списка от обновлений.  

• Использование событий для уведомления о изменениях.  

• Пример использования событий: `emit('tudoListChange')` и `emit('sortChange')` .  

• Добавление события в `store.events` для перерисовки компонента.  

• Пример кода: `store.events.on('tudoListChange', renderCount)` .  

• Удаление зависимости между `store` и `interview`.  

• `interview` подписывается на события `store` и читает данные.  

• `store` больше не знает о существовании `tudoView`.  

• Подписка на события `tudoListChange` и `sortChange` в `tudoView`.  

• Объяснение необходимости двух отдельных событий для простоты.  

• Упоминание о возможности отписки от событий в `useEffect`.  

• Выпрямление зависимостей в приложении.  

• Добавление новых кэшей и подписок без изменения `store`.  

• Принцип работы реактивности: `reactor-render` сравнивает результаты и перерисовывает кэши.  

• Проверка работы системы при добавлении и изменении данных.  

• Подтверждение синхронизации кэшей с источником истины.  

• Вынесение событий из `store` в `eventBus`.  

• Использование `eventBus` для взаимодействия компонентов.  

• Пример разделения `store` на `tudoStore` и `sortStore`.  

• Модули не связаны напрямую, зависят от `eventBus`.  

• Паттерн `eventBus` позволяет связывать элементы через общую шину событий.  

• Важность знания паттернов для улучшения кода.  

• Аккуратное использование паттернов для избежания ухудшения приложения.  

• Рекомендация курсов по паттернам в сообществе Evolution Community.  

• Призыв использовать классные паттерны.  

• Благодарность за внимание.