Angular. Понимание @Input, @Output и EventEmitter

[@Vahman]

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

[@kussch]

Да, вы все правильно поняли. Хорошо что есть еще в этой жизни вещи, которые могут вас удивить. Но в то же время странно, ведь это не первый случай перевода статьи с медиума, увы. У вас есть публикации в профиле, которые мне интересны и я обязательно ознакомлюсь. В заключение: не у каждого найдется желание перевести статью. Я буду очень рад если найдутся люди для которых она будет полезна. Успехов.

[@Kanut]

Присоединюсь к предыдущему оратору. Думал здесь что-то интересное будет: особенности, отличия от стандартного/ожидаемого поведения, подводные камни.

Но перевод банального и не особо интересного туториала? Дамс…

[@kussch]

Благодарен за мнение. Напишите статью с указанными Вами нюансами и поделитесь. Будет здорово.

[@c_kotik]

Так этого ждали от вас. Я вот тоже думал — статья будет чуть более, чем банальной.

[@kussch]

Извините, но я не использовал рендер для привлечения Вашего внимания. Ищите — найдете не банальщину на данную тему. Я был лишь одним из пунктов вашего длительного плавания в поиске прекрасной земли под названием «Небанальщина».

[@Kanut]

Пока я ещё нахожусь в той стадии знания Angular когда логичнее искать ньюнасы чем ими делиться :)

Но по теме статьи могу например написать что для меня в своё время было полезно понять что объекты в «banana in the box» передаются по указателю и если меняешь только состояние объекта, то в такой ситуации сам объект через Output возвращать не надо. Из обычных мануалов/туториалов это было ну вообще не понятно. Но не думаю что ради этого стоит писать целую статью на хабре :)

[@serf]

Я вас наверно удивлю, но передача объекта по ссылке это обычное поведение в JS, здесь ведь нет встроенной иммутабельности. Если выполняется сериализация, то это уже часть логики приложения.

[@Kanut]

Абсолютно не удивите. Но на тот момент я не знал как конкретно ведёт себя data binding или ngModel в Ангуляре и поэтому везде ставил Output как это было в мануалах/туториалах :)

[@Vahman]

output надо ставить для того, чтобы оповестить родительский объект о том, что что-то произошло. EventEmitter названием как бы намекает на это. Дело в том, что изменив состояние, не изменяя ссылку, не имея обработчика на output и при стратегии onchange ваш родительский компонент никогда не узнает, что ему надо проверить свое состояние м перерендериться.

[@Kanut]

Это опять же зависит от того как сделан этот самый родительский объект. Если там всё работает с подходящим датабайндингом, то он и «рендериться» будет автоматом. Но это опять же всё зависит от конкретной имплемемнтации и у каждого есть свои предпочетения как он хочет это делать.

Я скорее о том что я поначалу просто не знал о существовании альтернативы и абсолютно всё делал через Output и эмиттеры. И мне бы в своё время сильно помогло если бы в моих первых мануалах/туториалах это было описано подробнее.

[@serf]

Нюансы. Ну например такой нюанс что организацию обмена данными между компонентами можно делать и без input/output, например через центральный стор (ngrx/redux подобные поделки). Ведь input/output часто не самый удобный вариант, например когда нужно перекидывать данные между компонентом верхнего уровня и сидящим глубоко в иерархии или между «глубокими сидящими» компонентами в разных ветвях иерархии. Ну и разумеется иммутабельный центральный стор довольно удобно использовать c «onPush» компонентами.

[@Vahman]

Да можно просто через сервис даже устроить обмен, благо внедрять зависимости можно и на уровне компонент

[@serf]

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