Есть ли в Angular 1 отдельная система событий?

Question

[mitaichik]

Всем привет. Юзаем Angular 1 (1.4.8). Нужно организовать систему событий (on, off, emit), например, чтоб какой-нить сервис создавал свою шину, эмитил туда события, а другие компоненты могли на них подписаться.

Есть ли в Angular что-нить для этого из коробки? Как я понял, в нем подобный функционал имеется только в $scope, но нам нужно организовать это не в контексте скоупов.

Заранее спасибо!

Answer 1

[Сергей Протько]

в нем подобный функционал имеется только в $scope

это внутренний механизм, лучше его вообще не использовать просто так.

Из коробки ничего нет, но есть довольно много модулей.

p.s. завязывать UI на ивенты не стоит (почитайте про redux и посмотрите ngRedux, там в принципе есть диспатчер экшенов).

Comments

[copal]

а можно поинтересоваться чем Event от Action отличаются? Я просто смотрел несколько презентаций и отличия не увидел. Единственное на что я обратил внимание, это на возможность вставлять код, который будет что-то делать на месте получатели. То есть в Event ещё засунули код.

[Сергей Протько]

copal: почитайте/посмотрите лекции Грега Янга о EventSourcing.

[copal]

Сергей Протько: начал читать статью, которая побудила меня нангуглить о Greg Young. В его резюме доминируют теги .NET, C#, вобщем MS.... И вот у меня вопрос к Вам - почему все смеются на MS и OC Windows, превознося unix, но идут или ведут на поклон к проповеднику MS? не странно?

[copal]

Ведь на сколько мне известно, сумашедший биндинг придумала именно MS из-за каких-то особенностей своей платформы. И мне было немного неловко видеть как её пытаются сделать в других языках. и вот теперь они ещё процедурный подход стали продвигать, который тоже наверное особенностями MS серверов вызван... Мне просто что странно, что все боятся подмены данных, а подмена логики они боятся меньше?

[Сергей Протько]

copal: заговор рептилойдов.

Грег Янг в индустрии провел лет 20, было бы странно если бы его как гражданина США не занесло в Microsoft или он не сталкнулся с работой в .NET (как никак половина банков используют именно .NET как основной стэк технологий). (причем я не припоминаю что бы он в microsoft работал, да и мне это не интересно).

У Microsoft еще относительно недавно была весьма странная политика. Взять тот же C# .NET. Это очень мощный инструмент, а язык весьма выразительный и красивый. Так же есть F# для любителей функциональщины.

Если бы изначально microsoft не была столь привязана к своей платформе, то кто знает что было бы с Java и какую долю оно бы занимало в энтерпрайз сегменте рынка. Но последние пару лет microsoft активно выкладывает все наработки по своей платформе в опенсурс, что подразумевает что ближайшие пару лет можно ожидать роста .NET платформы.

Ну и в целом политика компании со сменой руководства мне лично нравится.

А те кто смеются с шиндусятников... они с шиндусятников смеются а не с windows там.

[Сергей Протько]

copal: и что за чушь про "поклон" и т.д.?

Знаете, есть такая штука как "научный подход". Описать его можно так: Научный метод познания – эксперимент и логика, а не вера и авторитеты.

[copal]

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

[Сергей Протько]

copal: кругом заговор, рептилойды придумали MVVM что бы снизить продуктивноть а ведь можно все проблемы решать единый православным ECS на который фапают в геймдеве. Ведь то что решает их проблемы решает проблемы всех! Еритики! Есть только один верный путь!

Вот как-то так ваши доводы звучат.

p.s. И не путайте импреративную процедурщину и функциональщину. Если вы к этому всему плохо относитесь то это от незнания.

[Сергей Протько]

copal: Хватит делать глупые догадки о вещах которые вы не понимаете. Посмотрите лучше лекцию. Займет час вашей жизни и вы сможете наконец понять что такое EventSourcing, что такое CQRS и когда это все нужно, для чего нете профит и т.д.

https://www.youtube.com/watch?v=JHGkaShoyNs

[copal]

Сергей Протько: про поклон это из темы о заговоре :) И хочу заметить что что вместе с открытием исходников MS получила и армию сырых новичков, замбировав которых она разнесла свою религию. То есть если я начинал и мне вдалбливали ооп и архитектуру, то им что-то свое вкладывают. А они... а на их рассказы смотрят вдвое внимательней, ведь они на огого каком языке пишут.

[copal]

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

[Сергей Протько]

copal: расширяйте кругозор. Все идеи которые популярные сегодня продвигаются с 60-х.

По поводу различий в подходах и тд. Есть ООП допустим и есть функциональное программирование котороые сейчас набирает популярность. Так вот, функциональное программирование старше! Просто 50 лет назад оно было неприменимо на практике потому что для имутабельности данных это было банально слишком дорого и неэффективно. Но сегодня - это нормально. Оперативки стало больше, появилась возможность паралелить выполнение и с этим возникли вопросы синхронизации мутаций и тд. А если у нас данные не меняются - то нет проблем с отслеживанием изменений.

Теперь о задачах и различиях в них. Если брать игрушку - то текущее состояние - это огромное множество переменных и тд. которые меняются по десятку раз в секунду и могут достигать по сотне мегабайт на кадр. Согласитесь, мутировать состояние в этом контексте явно эффективнее чем 60 раз в секунду копировать все состояние и строить его по новой. Да, это возможно с функциональными подходами но добавляет очень много сложности с мемоизацией и т.д. и в итоге игры могли бы писать только люди со степенями в CS (Computer Sience).

Но если мы берем типичное web приложение - там состояние меняется намного реже, и все состояние на странице можно уложить в мегабайт, а копирование мегабайта раз в секунду - это копейки. Потому с подходами с имутабельными данными можно здорово так понизить сложность приложения. То есть в этом плане состояние это предыдущее состояние + экшен. И мы так можем продолжать рекурсивно разбивать это до state = null + action. Цепочка состояний, цепочка ивентов, цепочка действий, цепочка команд... называйте как хотите.

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

Как-то так. На этом предлагаю завершить дискуссию. Если вам интересно - переходите в личку.

[Сергей Протько]

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

Но биндинги это попытка упростить отслеживание изменений в моделях. React с его Flux-ом пошли чуть дальше - если нет "изменений состояния" то биндинги предельно упрощаются. Вместо изменения состояния мы просто получаем новое состояние на основе предыдущего и какого-то экшена. То есть - идея event sourcing в действии.

Повторюсь - развитие всех этих идей надо привязывать исключительно к ограничениям, с которыми эти вещи призваны бороться. 40 лет назад Flux для построения UI было слишком не эффективно так как стоимость памяти была слишком высока. Проще было мутировать состояния. Сегодня - проще генерить состояние как измененнную копию старого.

[Сергей Протько]

copal: еще рекомендую посмотреть лекцию Failure of state

[copal]

Сергей Протько: искреннее Вам спасибо, вы вообще единственный человек в интеренете, от которого можно подчерпнуть что-то новое, что-то полезное.
Но хочу заметить, что flux, это концепция была предложена FB, описывает не action's, она говорит о обычных событиях change от store. Но возможно что Вы с Redux перепутали, о котором говорили ранее. А redux как мне показалось проповедует структуру графов, в роли листьев выступают какие-то редюсеры. И вот граф состоит из тысячи редусеров и только один обновился, но прогоняются все редюсеры и сверяются на изменение данные.

[Сергей Протько]

copal: flux это не новая концепция. Это набор известных идей которые скопоновали в единую кучу. Можно воспринимать flux как MVC + Event Sourcing.

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

Если у нас состояние не мутируется - то все предельно упрощается.

Redux - это реализация Flux. Термины - не столь важны, важна идея. Состояние системы формируется (редьюсерами) из последовательности действий (ивентов, экшенов, команд, термин не важен). Это не измененное предыдущее состояние, это новое состояние которое ничего не знает о предыдущем.

в итоге приходим к простой функции - UI = f(state); где f - это чистая функция которая не имеет состояния. В этом случае нет возможности получить побочные эффекты изменения состояния где-то внутри UI компонентов. Ну и конечно же все красиво только в теории, на практике прокидывать вообще все состояние может быть не столь эффективным. Пример - кропалка картинок. По хорошему вы на каждое смещение курсора должны формировать заного состояние всей системы. Согласитесь, это не очень эффективный подход.

Вывод - функциональное программирование работает (как красивая математическая теория) исключительно в условиях неограниченности вычислительных ресурсов. Для 95% задач WEB-а это достаточно, для оставшихся 5-ти приходится мутировать состояние поближе к источнику экшенов.

[copal]

Сергей Протько: извиняюсь что немного не в тему, но другого выхода чтоль у меня нету...
Лазил в гугле и увидел Ваш пост на хабре, где Вы говорили что js-data лучше чем ember-data... А Вы знаете что-нибудь очень похожее на js-data но изоморфное?

[copal]

Сергей Протько: просто не понятно, зачем автор использует изоморфное основание для неизоморфного js-data-http адаптера. Меня это и запутало. Я думал что ну раз используетеся изоморфное основание, то значит и работать будет везде. А на деле фига! И более того он не собирается делать изоморфно, он хочет сделать js-data-http-node и по моему тем самым поставит крест на своем проекте.

[Сергей Протько]

copal: изоморфные приложения - это не так просто.

Что до js-data - увы я им попользовался и пока не использую (нет смысла пока на бэкэнде не начнем jsonapi юзать на полную).

[mitaichik]

Сергей Протько: Спасибо. Странно, конечно, что ангуляр не имеет подобного механизма из коробки.

[Сергей Протько]

mitaichik: на самом деле ничего странного, это весьма специфичная штука для организации логики.