Event bus что это
Использование Event Bus для обмена свойствами между компонентами Vue
Дата публикации: 2018-10-17
От автора: для чего можно использовать в Vue Event Bus? По умолчанию связь между компонентами Vue происходит с использованием свойств. Эти свойства передаются из родительского компонента в дочерний.
Например, вот компонент, в котором title является свойством:
Свойства всегда передаются от родительского компонента к дочернему. По мере того, как ваше приложение увеличивается, вы постепенно подходите к тому, что называется сквозной передачей. Сквозная передача свойств — это идея передачи свойств вниз и далее вниз по дочерним компонентам — и, как вы можете себе представить, это, как правило, утомительный процесс.
Фреймворк VUE JS: быстрый старт
Получите бесплатный курс и узнайте, как создать веб-приложение на трендовой Frontend-технологии VUE JS с полного нуля
Таким образом, сквозная передача может быть одной из потенциальных проблем. Другая — взаимодействие между несвязанными компонентами. Мы можем решить все это, используя Event Bus.
Что такое Event Bus? Ну, это в основном раскрыто в самом названии. Это способ транспортировки для компонента с целью передачи свойства от одного компонента другому — независимо от того, где эти компоненты расположены в дереве.
Практическая задача: создание счетчика
Давайте рассмотрим реальный пример, чтобы продемонстрировать концепцию Event Bus. Счетчик, который добавляет или вычитает предоставленное значение и подсчитывает общую сумму, является подходящим для рассмотрения случаем:
Чтобы использовать Event Bus, сначала необходимо инициализировать его:
Это задает экземпляр Vue для eventBus. Вы можете назвать его, как угодно. Если вы используете однофайловый компонент, то у вас должен быть сниппет в отдельном файле, так как вам в любом случае придется экспортировать экземпляр Vue, назначенный как eventBus:
После этого мы можем начать использовать его в компоненте счетчика. Вот что мы хотим сделать:
Мы хотим получить счетчик с начальным значением 0.
Мы хотим добавить поле ввода, которое принимает числовые значения.
Нам нужны две кнопки: одна при нажатии будет добавлять переданное числовое значение, а другая — вычитать указанное числовое значение.
Мы хотим получать подтверждение того, что произошло, когда сумма изменится.
Так выглядит шаблон с каждым из этих элементов:
Фреймворк VUE JS: быстрый старт, первые результаты
Получите бесплатный курс и узнайте, как создать веб-приложение на трендовой Frontend-технологии VUE JS с полного нуля
Мы привязываем поле ввода к значению, называемому entry, которое мы будем использовать для увеличения или уменьшения суммы, в зависимости от того, что выбрал пользователь. Когда нажата любая кнопка, мы запускаем метод, который должен либо увеличивать, либо уменьшать значение счетчика. Наконец, <
, является сообщением, которое мы выводим, оно подытоживает внесенные изменения. Вот как все это происходит в нашем скрипте:
Возможно, просмотрев этот код, вы заметили, как мы собираемся использовать Event Bus.
Первое, что нам нужно сделать, это установить путь для отправки события от одного компонента к другому. Мы можем проложить этот путь с помощью eventBus.$Emit() (при этом emit является причудливым словом для обозначения отправки). Эта передача включена в два метода: handleIncrement и handleDecrement, которые прослушивают ввод данных. И, как только это произойдет, наш автобус событий отправляется к любому компоненту, который запрашивает данные, и перевозит свойство.
Возможно, вы заметили, что с помощью eventBus.$on() мы прослушиваем оба события в хуке жизненного цикла created(). В обоих случаях мы должны передать строку, соответствующую событию, которое мы запустили. Это похоже на идентификатор для конкретного события, вся суть заключается в том, чтобы установить способ получения данных компонента. Когда eventBus распознает определенное событие, которое было объявлено, вызывается следующая функция: мы устанавливаем текст для отображения того, что произошло, и скрываем его через три секунды.
Практическая задача: обработка нескольких компонентов
Предположим, мы работаем над страницей профиля, где пользователи могут обновлять свое имя и адрес электронной почты для приложения, а затем просматривать обновления без перезагрузки страницы. Это можно просто сделать с использованием Event Bus, хотя на этот раз мы имеем дело с двумя компонентами: профилем пользователя и формой, через которую предоставляются изменения профиля.
EventBus — Система событий для Unity
В этой статье я расскажу вам о том, что такое система событий применительно к Unity. Изучим популярные методы и подробно разберем реализацию на интерфейсах, с которой я познакомился, работая в Owlcat Games.
Содержание
1. Что такое система событий?
Любая игра состоит из множества систем: UI, звук, графика, ввод и тд и тп. Эти системы неизбежно взаимодействуют:
Некоторые системы могут быть сильно связаны, например ввод и движение персонажа. В таких случаях можно вызывать нужный метод напрямую. Но если системы связаны слабо, гораздо лучше использовать систему событий. Давайте посмотрим, как это может работать на примере с сохранением.
Такая реализация системы служит лишь примером. Использование строк, как меток событий очень багоопасно и неудобно.
В широком смысле система событий — это общедоступный объект, чаще всего статический класс. У него есть метод подписки на определенные события и метод вызова этих событий. Все остальное — детали.
2. Существующие реализации
В большинстве случаев методы подписки и вызова будут выглядеть примерно следующим образом:
Рассмотрим самые популярные реализации, опираясь на эту схему.
2.1. Подписка по ключу
2.2. Подписка по типу события
Этот метод использует обобщенные методы, что позволяет нам жестко задать аргументы.
2.3. Подписка по типу подписчика
Этот способ как раз используется в нашем проекте. В нем мы опираемся на интерфейсы, которые реализует подписчик. Объяснение принципа его работы оставлю для следующей главы, здесь покажу лишь пример.
3. Реализация на интерфейсах
В угоду понятности и краткости в выкладках ниже убраны некоторые детали. Без них система будет багоопасной, но для понимания основного принципа они не важны. Тем не менее мы рассмотрим их в разделе «Тонкости реализации».
3.1. Подписка на событие
В нашем случае в качестве ключа выступает тип подписчика, а точнее интерфейсов, который этот тип реализует.
Рассмотрим на примере быстрого сохранения. Создадим интерфейс, который будет выступать в роли ключа для такого события:
Для того, чтобы интерфейс мог выступать ключом, он должен наследовать IGlobalSubscriber. Этот позволит системе отличать интерфейсы-ключи от всех остальных, скоро увидим как именно. Сам интерфейс IGlobalSubscriber не содержит никаких свойств и методов, он лишь метка.
Теперь подписка и отписка будут выглядеть очень просто:
Метод GetSubscriberTypes будет описан чуть ниже. Он возвращает список типов интерфейсов-ключей, которые реализует подписчик. В нашем случае это будет список из одного элемента: IQiuckSaveHandler — хотя в реальности SaveLoadManager может реализовать несколько интерфейсов.
А вот и реализация GetSubscribersTypes :
Итак, в качества ключей в EventBus выступают интерфейсы, которые реализует подписчик.
3.2. Вызов события
Напомню, что мы все еще рассматриваем пример с быстрым сохранением. InputManager отслеживает нажатие на кнопку ‘S’, после чего вызывает событие быстрого сохранения.
Вот как это будет выглядеть в нашей реализации:
Давайте посмотрим на метод RaiseEvent :
Описание интерфейсов в итоге определяет события, которые мы можем вызывать.
3.3. В чем прелесть интерфейсов
Интерфейс может реализовать более одного метода. Для нашего примера в реальности более логичным мог бы оказаться такой интерфейс:
Таким образом мы подписываемся не по одному методу, а сразу группой методов, которые объединены в один интерфейс.
Также важно отметить, что передавать какие-либо параметры в такой реализации как никогда просто. Рассмотрим пример 1 из начала статьи про онлайн шутер. Работа системы событий могла бы выглядеть следующим образом.
Интерфейсы позволяют очень гибко определять набор возможных событий и их сигнатуру.
4. Тонкости реализации
Как и обещал, рассмотрим некоторые технические детали, пропущенные в прошлом разделе.
4.1. Отказоустойчивость
Код внутри любого из подписчиков может привести к ошибке. Чтобы это не оборвало цепочку вызовов, обнесем это место try catch :
4.2. Кеширование типов подписчиков
Функция GetSubscribersTypes работает при помощи рефлексии, а рефлексия всегда работает очень медленно. Мы не можем полностью избавиться от этих вызовов, но можем закешировать уже пройденные значения.
4.3. Отписка во время события
Мы еще не описывали здесь метод отписки, но скорее всего он мог бы выглядеть как-то так:
И такой метод будет работать в большинстве случаев. Но рано или поздно при вызове очередного события мы можем получить ошибку вида
Такая ошибка возникает, если внутри прохода по какой-то коллекции при помощи foreach мы удалим элемент из этой коллекции.
В нашем случае проблема возникает, если во время вызова события один из подписчиков отписывается.
Теперь обновим наш словарь в EventBus :
После этого обновим метод вызова события RaiseEvent :
В теории этой ситуации может и не возникнуть, но на практике рано или поздно это происходит. Вы можете заметить, что мы беспокоимся только об удалении из коллекции, но не думаем о добавлении во время прохода. Вообще было бы правильно и этот случай обработать, но на практике у нас этой проблемы ни разу не возникало. Но если возникнет у вас, вы уже будете знать в чем дело.
5. Завершение
Большинство систем событий похожи друг на друга. Они имеют в основе такую же подписку по ключу и реализованы внутри тоже при помощи словаря. Проблема удаления во время перебора для них тоже актуальна.
Наше решение отличается использованием интерфейсов. Если немного задуматься, то использование интерфейсов в системе событий является очень логичным. Ведь интерфейсы изначально придуманы для определения возможностей объекта. В нашем случае речь идет о возможностях реагировать на те или иные события в игре.
В дальнейшем систему можно развивать под конкретный проект. Например в нашей игре существуют подписки на события конкретного юнита. Еще на вызов и завершение какого-то механического события.
Русские Блоги
Подробное объяснение использования EventBus в структуре шины событий публикации / подписки Android
1. Введение
Однажды слой за слоем бизнес-логики приводил меня в недоумение, один обратный вызов за другим вызывали у вас головокружение, а один параметр за другим сбивали вас с толку. EventBus, фреймворк с низкой степенью связи, который пугает.
2. Что такое EventBus
3. Сравнение похожих товаров.
Используйте трилогию EventBus3.0
1. Определите событие
2. Подготовьте подписчиков
3. Отправить мероприятие
понять глубже
1. ThreadMode связь потоков
EventBus может легко переключаться между потоками, включая фоновые потоки, потоки пользовательского интерфейса и асинхронные потоки.
2. Настройте EventBusBuilder.
3.StickyEvent
StickyEvent сохраняет последнее сообщение в памяти, отменяет исходное сообщение и выполняет последнее сообщение. Оно будет выполнено только после регистрации. Если регистрации нет, сообщение всегда будет храниться в памяти.
Вы также можете управлять StickyEvent вручную
Здесь у вас может возникнуть вопрос,
Могут ли подписчики с StickyEvent = true получать события публикации?
Могут ли подписчики StickyEvent = false получать события postSticky?
Просмотр обнаружения исходного кода
Обнаружено, что метод post не фильтрует StickyEvent, а postSticky вызывает метод post, поэтому независимо от того, является ли post или postSticky StickyEvent истинным или ложным, он будет выполнен
4. приоритет приоритетного события
5. Прервать доставку события.
6. ускорение индекса индекса
EventBus использует аннотацию, которая по умолчанию генерирует код и индексы во время компиляции.
После добавления индекса он будет запущен во время компиляции, и соответствующий код будет автоматически сгенерирован.
ps: из-за ограничений apt аннотации в анонимном внутреннем классе не будут распознаваться и будут автоматически ухудшены, чтобы отражать их во время выполнения. В это время эффективность будет снижена
Адрес официального сайта EventBus
Поскольку kotlin использует аннотации по-разному, вам нужно использовать kapt
ps: если необходимо проиндексировать несколько модулей, указанные выше три apts должны быть добавлены к каждому модулю, и импорт пакета не нужно повторять
Таким образом, код будет автоматически сгенерирован после компиляции.
Метод события создается путем отражения во время компиляции и сохраняется на карте. Когда событие отправляется, вызывается getSubscriberInfo для получения карты.
7.NoSubscriberEvent
Если событие подписчика не найдено, вы можете указать, следует ли отправлять NoSubscriberEvent по умолчанию через EventBusBuilder, который по умолчанию включен.
8. Замешательство
9. Плюсы и минусы
Простая, удобная, компактная, понятная документация, низкое энергопотребление, настраиваемая прочность линии, низкое сцепление
Это определенно не шутка. Связь EventBus слишком мала. Если она не контролируется и не управляется, вы не будете знать, куда идет отправленное вами сообщение. Я не знаю, куда будет отправлено ваше сообщение. Если у вас нет хорошего способа решить эту проблему, рекомендуется не использовать слишком много.
Рекомендации
1. Управление EventBus
EventBus запускается для создания нескольких, затем, чтобы уточнить жизненный цикл события, использовать разные EventBus в соответствии с разными жизненными циклами?
2. Целевые события
Инкапсулируйте данные в класс событий. Все события помещены в один пакет. Если событий слишком много, события одного модуля можно рассматривать с помощью статических внутренних классов или субподряда.
Обратите внимание, что если они не одного типа, они должны быть упакованы как событие. Необходимо учитывать определенные бизнес-сценарии и условия кода. Например, поведение событий и жизненные циклы событий различаются. При необходимости лучше записать пакеты в два события.
Руководство по фоновой работе в Android. Часть 3: Executors и EventBus
Приветствую, коллеги. Рад видеть вас снова в третьей части «Руководства по фоновой работе в Android». Если не видели предыдущие части, вот они:
Давайте вспомним, в чём главная загвоздка: времязатратные операции вроде сетевых вызовов должны осуществляться в фоновом потоке, но публикация результата может происходить только в главном UI-потоке.
Также было бы здорово сохранять результат продолжительной операции при изменении конфигурации.
В предыдущих текстах мы разобрались, как делать это с помощью AsyncTasks и Loaders. Однако у этих API есть свои недостатки, из-за которых приходится реализовывать довольно сложные интерфейсы и абстрактные классы. Кроме того, они не позволяют нам писать модули с асинхронной работой на чистой Java из-за использования Android-специфичных API.
Из-за этих ограничений возник подход, опирающийся на executors. Давайте рассмотрим его. Для начала, понятно, нам надо разжиться потоками, куда мы сможем отправлять свои задачи для фоновой работы. Давайте создадим для этого класс Background:
Итак, у нас есть executor, и есть метод, позволяющий запустить какой-то код асинхронно, обернув его в Runnable или Callable.
Здорово, давайте попробуем засунуть результат операции в UI-поток. Не проблема, мы знаем, что нам требуется только Handler:
Но подождите, мы не знаем, существует ли в этот момент вообще наш UI, и если да, как он узнает, что надо что-то изменить?
Тут на помощь и приходит подход, называемый «шина событий» или event bus. Общая идея в том, что есть некая общая шина (или даже несколько), куда публикуются события. Кто угодно может в любое время начать слушать шину, получать события, а затем прекращать слушать (звучит похоже на RxJava, да? Дождитесь следующей статьи!)
В общем, нам нужны три составляющих:
Сама шина
Источник (или источники) событий
Слушатель (или слушатели) событий
Можно отразить эту структуру такой диаграммой:
Принципиальная схема передачи событий по шине
Шина событий
Никто не требует самостоятельно реализовывать шину с нуля. Можно выбрать одну из существующих реализаций: Google Guava, Otto или EventBus от greenrobot (у последнего есть стильная поддержка отправки событий на разные потоки с помощью аннотаций).
Объект шины мы можем использовать напрямую в наших презентерах, активностях, фрагментах и так далее, но я предпочитаю инкапсулировать его в том же классе Background:
Давайте напишем клиентский код, использующий конструкцию, которую мы соорудили. Предположим, что мы хотим инициализировать базу данных перед использованием приложения, и это, конечно, занимает время. Так что внутри приложения мы запускаем инициализацию в фоне и публикуем событие о том, что инициализация базы завершилась:
Так что, например, мы можем спрятать прогресс-бар и перейти к нашей MainActivity:
Проблема тут нам уже хорошо известна: нельзя модифицировать UI из фонового потока, а код выше пытается сделать именно это.
Так что нам надо либо воспользоваться возможностями работы с потоком из библиотеки greenrobot, либо сделать всё самим. Не стоит изобретать велосипед в продакшн-приложении, но в целях обучения давайте попробуем сделать это голыми руками, тем более, что это очень просто.
Но перед этим давайте немного закопаемся в сорцы и посмотрим, как вызывается метод, помеченный аннотацией Subscribe, когда событие публикуется.
Заглянем в исходный код шины событий Google Guava:
Обращение с потоками зависит от объекта dispatcher, который по умолчанию выставлен на Dispatcher.perThreadDispatchQueue().
Что же происходит внутри dispatcher:
Главное тут: PerThreadQueuedDispatcher использует ThreadLocal для хранения очереди событий. По сути, это означает, что метод подписчика будет вызван в том же самом потоке, в котором было опубликовано событие.
И что нам с этим делать? Решение нехитрое — просто публиковать события в том потоке, в котором хотите их обрабатывать:
Это работает, но привносит ту проблему, которую шина событий вроде как должна решать: понижение связности с помощью разделения публикации и обработки событий. С таким решением мы обязываем код, публикующий события, знать, в каком потоке клиент хотел бы обработать код.
Другим решением стало бы использование Handlers прямо в UI:
Это тоже не выглядит полноценным решением. И в этом состоит ограничение шины событий. Как с этим можно справиться? Конечно, с помощью RxJava! Но об этом — в следующей части.
От автора: Я вхожу в программный комитет конференции Mobius, и её программа на 90% готова. Скорее смотрите, что вам приготовила конференция, и ждите новостей о финализации программы!
5 приемов в помощь разработке на vue.js + vuex
Недавно решил разобраться с vue.js. Лучший способ изучить технологию — что-нибудь на ней написать. С этой целью был переписан мой старый планировщик маршрутов, и получился вот такой проект. Код получился достаточно большим для того, чтобы столкнуться с задачей масштабирования.
В этой статье приведу ряд приемов, которые, на мой взгляд, помогут в разработке любого крупного проекта. Этот материал для вас, если вы уже написали свой todo лист на vue.js+vuex, но еще не зарылись в крупное велосипедостроение.
1. Централизованная шина событий (Event Bus)
Любой проект на vue.js состоит из вложенных компонентов. Основной принцип — props down, events up. Подкомпонент получает от родителя данные, которые он не может менять, и список событий родителя, которые он может запустить.
Принцип годный, но создает сильную связность. Если целевой компонент глубоко вложен, приходится протаскивать данные и события через все обертки.
Разберемся с событиями. Зачастую полезно иметь глобальный event emitter, с которым может общаться любой компонент независимо от иерархии. Его очень легко сделать, дополнительные библиотеки не нужны:
После этого в любом компоненте появляется доступ к this.$bus, можно подписываться на события через this.$bus.$on() и вызывать их через this.$bus.$emit(). Вот пример.
Очень важно понимать, что this.$bus — глобальный объект на все приложение. Если забывать отписываться, компоненты остаются в памяти этого объекта. Поэтому на каждый this.$bus.$on в mounted должен быть соответствующий this.$bus.$off в beforeDestroy. Например, так:
2. Централизованная шина промисов (Promises Bus)
Иногда в компоненте нужно инициализировать некую асинхронную штуку (например, инстанц google maps), к которой хочется обращаться из других компонентов. Для этого можно организовать объект, который будет хранить промисы. Например, такой. Как и в случае в event bus, не забываем удаляться при деинициализации компонента. И вообще, указанным выше способом к vue можно прицепить любой внешний объект с любой логикой.
3. Плоские структуры (flatten store)
В сложном проекте данные зачастую сильно вложены. Работать с такими данными неудобно как в vuex, так и в redux. Рекомендуется уменьшать вложенность, например, воспользовавшись утилитой normalizr. Утилита — это хорошо, но еще лучше понимать, что она делает. Я не сразу пришел к пониманию плоской структуры, для таких же типа себя рассмотрю подробный пример.
Имеем проекты, в каждом — массив слоев, в каждом слое — массив страниц: projects > layers > pages. Как организовать хранилище?
Первое, что приходит в голову — обычная вложенная структура:
Можно указывать полный путь, типа
Но это значит, что в каждый маленький компонент рендеринга страницы нужно протаскивать всю иерархию, и projectId, и layerId. Неудобно.
Вторая попытка, из sql:
Теперь данные легко менять. Но тяжело бегать. Чтобы вывести все страницы в одном слое, нужно пробежать по вообще всем страницам. Это может быть спрятано в getter-е, или в рендеринге шаблона, но пробежка все равно будет.
Третья попытка, подход normalizr:
Теперь все страницы слоя могут быть получены через тривиальный геттер
Заметим, что геттер не бегает по списку всех страниц. Данные легко менять. Порядок страниц в слое задан в объекте layer, и это тоже правильно, поскольку процедура пересортировки как правило находится в компоненте, который выводит список объектов, в нашем случае это компонент, который рендерит layer.
4. Мутации не нужны
Согласно правилам vuex, изменения данных хранилища должны происходить только в функциях-мутациях, мутации должны быть синхронными. В vuex находится основная логика приложения. Поэтому блок валидации данных тоже будет логичным включить в хранилище.
Но валидация далеко не всегда синхронна. Следовательно, по крайней мере часть валидационной логики будет находится не в мутациях, а в действиях (actions).
Предлагаю не разбивать логику, и хранить в actions вообще всю валидацию. Мутации становятся примитивными, состоят из элементарных присваиваний. Но тогда к ним нельзя обращаться напрямую из приложения. Т.е. мутации — некая утилитарная штука внутри хранилища, которая полезна разве что для vuex-дебаггера. Общение приложения с хранилищем происходит через исключительно действия. В моем приложении любое действие, даже синхронное, всегда возвращает промис. Мне кажется, что заведомо считать все действия асинхронными (и работать с ними как с промисами) проще, чем помнить что есть что.
5. Ограничение реактивности
Иногда бывает, что данные в хранилище не меняются. Например, это могут быть результаты поиска объектов на карте, запрошенные из внешнего api. Каждый результат — это сложный объект с множеством полей и методов. Нужно выводить список результатов. Нужна реактивность списка. Но данные внутри самих объектов постоянны, и незачем отслеживать изменение каждого свойства. Чтобы ограничить реактивность, можно использовать Object.freeze.
Но я предпочитаю более тупой метод: пусть state хранит только список id-шников, а сами результаты лежат рядом в массиве. Типа:
Вопросы
Кое-что у меня получилось не настолько красиво, как хотелось. Вот мои вопросы к сообществу:
— Как победить css анимации сложнее изменения opacity? Часто хочется анимировать появление какого-то блока неизвестных размеров, т.е. изменить его высоту с height: 0 до height: auto.
Это легко решается с javascript — просто оборачиваем в контейнер с overflow: hidden, смотрим высоту обернутого элемента и анимируем высоту контейнера. Это можно решить через css?
— Ищу нормальный способ работы с иконками в webpack, пока безуспешно (поэтому продолжаю пользоваться fontello). Нравятся иконки whhg. Вытащил svg, разбил на файлы. Хочу выбрать несколько файлов и автоматически собирать в inline шрифт + классы на основе названий файлов. Чем это можно делать?