Обмен данными между компонентами Angular
Проблема
В результате работы с фреймворком Angular, мы декомпозируем наше web-приложение. И по этому у нас возникает ситуация, когда нам нужно передавать данные между компонентами.
@Input()
Осталось только передать параметр title в дочерний компонент из родительского:
@Output()
Благодаря директиве @Output() мы можем привязаться к событиям дочернего компонента. На первый взгляд не очень понятно, так что давайте рассмотрим пример:
Но есть одно «но», мы не передали никакую информацию в родительский компонент. Рассмотрим уже другой вариант в котором мы будем передавать информацию в родительский компонент:
Давайте рассмотрим список внесенных изменений:
Добавили тип передаваемых данных new EventEmitter boolean >()
В метод emit передали нужную информацию this.buttonClick.emit(change)
@Input() и @Output() достаточно удобно, но не в ситуации, когда на надо передать данные в дочерний компонент, дочернего компонента и т.д., или же компоненты находятся в разных частях приложения.
Сервисы и RxJs
Одними из лучших вариантов обмена данных остаются сервисы. Создадим простой сервис который бы мог оповещать компоненты про изменение данных, а так же передавать значения:
Мы передали результат Math.random() и пустили его по всем подписчикам. Теперь посмотрим как следить за этими изменениями:
Мы можем подписаться на множество Subject из компонента, подписаться на один и тот же Subject из разных компонентов.
Различные способы передачи данных в компоненты Angular
Привет, Хабр! Представляю вашему вниманию перевод статьи «Different Ways to Pass Inputs to a Component in Angular» автора Netanel Basal.
В этой статье, мы разберём три разных способа передачи данных в компонент. В следующем примере мы будем использовать select как главный компонент, но методы, используемые в нём релевантны и в других компонентах.
Создадим компонент select, который получает следующие входные данные — size и placement.
Использование Inputs
Первый метод, с которым мы все знакомы — использование декорантора Input.
И этот код отлично работает, за исключением того, что он не такой гибкий. Например нам нужно задать переменной size значение large для любого select в нашем приложении. Таким образом мы должны разрешить клиетну переписать любой input на глобальном уровне.
Использование зависимости Injection
Для этого мы можем использовать функцию внедрения зависимостей Angular.
Для начала нам нужно создать конфигурацию провайдера. Этот провайдер может быть использован как token, type, а также задавать значения по умолчанию для каждого input. Используем это в нашем компоненте select:
Теперь мы можем переписать выбранные inputs на уровне нашего приложения:
Но это не всё. Так же мы можем использовать это для передачи различных inputs на уровне компонентов. Например у нас есть компонент, который мы используем несколько раз в приложении. В каждом случае нам нужно использовать величину small:
Мы можем добавить это в компонет providers и эта величина будет использована для всех компонентов, объявленных и дочерних в шаблонах. Но мы всё ещё можем переписать эту переменную, напрямую следующим образом:
Такую же стратегию применяют для lazy modules потому что она создают новую инъекцию.
Использование Directives
Предположим у нас есть компоненты с множеством входных данных. Мы устанавливаем одинаковые значения для большинства из них. В примере это будет выглядеть так:
Мы можем повторять эти значения, но можем создать директиву, которая передаст необходимые значения всех переменных:
И мы можем использовать эту директиву где нам нужно:
Взаимодействие между компонентами Angular с использованием RxJS
Руководство о том, как использовать Subject RxJS и BehaviourSubject RxJS для связи между компонентами Angular.
В этой статье я буду использовать RxJS, чтобы показать как компоненты взаимодействуют, когда они не знают друг друга или не имеют общих родительских / дочерних отношений.
Содержание:
Проблема
Во многих фрэймворках, включая Angular, всегда возникает проблема взаимодействия компонентов, когда мы разделяем приложение на множество маленьких UI компонентов и привязываемся к родительскому элементу родительского элемента, чтобы слушать события.
В Angular мы используем Output() и Input(). В стандартных случаях этого достаточно, но когда нужно связать входящие данные и исходящие события с родительским компонентом, управление этим всем превращается в кошмар.
Нужно добавить кучу Input() и Output() ко многим уровням компонента – это требует больших усилий, рискованно и не всегда работает.
Одно из решений – использовать мэнеджер состояния – такой как Redux, NGRX или NGXS, чтобы помочь несвязанным компонентам обмениваться данными.
В этой статье я представлю два дополнительных способа для решения этой проблемы, не требующих использования дополнительных библиотек.
Способ 1: Транспорт событий
Концепция очень проста. Вы создаёте сервис, события которого будут доступны везде.
Сервис распространяет события, а подписчики могут выполнить функцию обратного вызова, когда событие произошло. В этой статье я создам Транспорт событий с помощью RsJS Subject.
Каждый раз, когда пользователь нажимает на элемент списка статей, он генерирует событие и передает его с помощью Транспорта событий.
Этот код означает, что мы отправляем событие SelectArticleDetail вместе с информацией о статье.
Слушатель прослушает SelectArticleDetail и выполнит обратный вызов, передаст данные статьи в локальную переменную и отобразит их в пользовательском интерфейсе.
Способ 2: Сервис-наблюдатель
Идея в том, чтобы просто создать способ для передачи данных изнутри. То есть каждый раз при изменении какого-то значения наблюдатель узнает об этом и выполняет функцию обратного вызова.
Каждый раз, когда пользователь нажимает на элемент списка, он добавляет статью в хранилище.
Теперь, в компоненте детали, мы подпишемся на обновление хранилища, чтобы получить новое значение.
Применение
Я применял эти подходы во многих проектах. Вот несколько примеров, где это очень уместно:
Подводя итог
Эта статья о двух способах взаимодействия между двумя или более несвязанными компонентами.
Мы используем Сервис-наблюдатель, чтобы подписаться на данные для простых случаев, и используем Транспорт событий, чтобы отправлять разные события разным слушателям.
Надеюсь, статья была полезна! Подписывайтесь на меня в Medium и Twitter. Не стесняйтесь комментировать и задавать вопросы. Буду рад помочь!
Шаблоны коммуникаций в Angular
Angular следует двусторонней схеме потока данных, то есть вы можете отправлять данные вверх и вниз по дереву компонентов. Поскольку все в Angular является компонентом, понимание связи между компонентами имеет решающее значение для каждого успешного проекта Angular.
В этом посте я расскажу обо всех способах взаимодействия между компонентами. Вот темы, которые мы пройдем:
Пример проекта
Вот пример проекта, поэтому вы можете увидеть все коммуникации в действии. Вы можете клонировать этот проект, чтобы протестировать его на своей машине.
Основы компонентов
Я хочу пройтись по основам компонентов, прежде чем углубляться в связи между ними. Если вы уже знакомы с этими понятиями, можете перейти к следующему разделу.
Angular следует шаблону проектирования компонентов, что означает, что в Angular все является компонентом. Все ваше приложение разделено на модули, и каждый модуль можно разделить на небольшие, повторно используемые компоненты. Если вы посмотрите на диаграмму ниже, мы определили три модуля, и каждый модуль имеет несколько компонентов. Эта модульная система помогает быстрее загружать приложение, так как в браузере загружаются только необходимые модули.
Модуль
Компонент
Каждый компонент имеет три важных файла: файл класса app.component.ts для логики, html-файл app.component.html для представления и файл CSS app.component.css для стилей.
Обратите внимание на selector в приведенный выше файле. Значение, app-root используется для размещения компонента в DOM следующим образом:
Интерполирование
Привязка свойств
Привязка событий
Разобравшись немного с основами, давайте погрузимся в модели коммуникации в Angular.
Общение родителей с потомками
Давайте посмотрим, как мы можем передавать информацию из родительского компонента в дочерний компонент. У нас есть заголовок, который будет передан из родительского компонента (app) в дочерний (header) компонента.
Мы определяем title в компоненте app, как показано ниже. Посмотрим, как мы передадим этот title компоненту header.
У нас есть @Input() headerTitle в компоненте header, и мы используем привязку свойства [headerTitle] в компоненте app, чтобы передать title.
Итак, с помощью декоратора @Input() мы можем передавать данные дочернему компоненту.
Общение потомка с родителем
Давайте посмотрим, как мы передаем информацию из дочернего компонента в родительский.
У нас есть декоратор @Output и класс EventEmitter для отправки информации из дочернего компонента в родительский.
Связь одноуровневых компонентов с помощью сервисов
Компоненты на одном уровне называются родственными компонентами. В нашем примере Header и Footer являются родственными компонентами. В этом разделе давайте посмотрим, как мы можем общаться между одноуровневыми компонентами с помощью сервисов.
Давайте посмотрим это в действии. У нас есть ссылки в Header и те же ссылки в Footer. Но у нас нет ссылки на dashboard в Footer, потому что пользователь не вошел в систему.
При нажатии на ссылку Login в заголовке пользователь входит в систему и ссылка Login меняется на Logout. Нам нужно связаться с Footer, чтобы он отображал ссылку на dashboard и Logout вместо Login. Ниже приведено состояние после нажатия на ссылку Login:
Вот пример нашего сервиса. Мы определяем параметр isUserLoggedIn и setUserLoggedIn метод:
Вот компоненты Footer и Header. Я удалил другой код для краткости. Мы внедрили сервис в обоих компонентах и используем его в компоненте Header для отправки данных a в Footer для получения данных.
Связь с помощью EventEmitter
В приведенном выше разделе мы увидели, как мы можем общаться между одноуровневыми компонентами с помощью сервисов. Давайте посмотрим, как мы можем сделать то же самое с EventEmitter.
Если мы посмотрим на диаграмму ниже, мы отправим данные с помощью EventEmitter в компонент App. Мы устанавливаем свойства app с данными, полученными из Header. Как только свойства app установлены, Footer получает данные в качестве входных данных.
Заголовок отправляет событие setLoggedInFlag и loginFlag передается в Footer:
Вот компонент Footer с геттерами и сеттерами для @Input, чтобы найти изменения:
Связь с использованием декоратора @ViewChild
@ViewChild является одним из распространенных декораторов, которые мы используем в Angular. При этом мы можем получить ссылку на пользовательский компонент, запросив шаблон.
Вот дочерний компонент:
Когда мы размещаем parent компонент в компоненте app:
Общение с использованием контент-проекции
Это код для app-welcome-message компонента HTML:
Мы можем спроектировать контент на компоненты с помощью ng-content :
Вот вывод в браузере:
Связь с NGRX Store
Связь с NGRX Store
Связь с NGRX Store в деталях
Давайте рассмотрим наиболее важные аспекты того, как данные на самом деле передаются в NGRX Store.
Поток данных с NGRX Store
Вот пример. В нижней части файла расположены селекторы, которые представляют собой специальные функции, которые дают вам определенный фрагмент состояния:
Связь между модулями
Все приложение Angular разделено на модули, основанные на функциях приложения. Иногда нам также необходимо общение между модулями.
Есть несколько способов сделать это.
NGRX Store
Как мы уже говорили ранее, мы можем подписаться на store из компонентов и обмениваться данными. Любой компонент из любого модуля, который может получить доступ к хранилищу и отправить action, получает данные.
Посмотрите на диаграмму ниже. Мы можем отправить действие из компонента A в Модуль A с данными, чтобы внести изменения в состояние NGRX. Компонент B из модуля B подписывается на хранилище и получает эти данные по мере изменения состояния.
Связь между модулями с NGRX Store
Общий модуль
У нас может быть общий модуль, который импортируется в другие Модули, и мы используем сервисы для обмена данными. Как вы можете видеть на следующей диаграмме, у нас есть общий модуль с сервисами, в котором могут использоваться все модули, при условии, что мы импортируем общий модуль в функциональные модули.
Связь между модулями с помощью общего модуля
Резюме
Заключение
Поток данных важен в одностраничных приложениях. Понимание этих шаблонов коммуникации имеет решающее значение для успеха вашего проекта. Без этих базовых концепций вы получите «спагетти код»: его трудно отлаживать, читать и расширять.
Angular компоненты со встраиваемым контентом
Когда создаешь новые компоненты при разработке на Angular, стремишься их создать таким образом, чтобы их можно было переиспользовать много раз. Точно так же, как и при разработке ПО, программист стремится сделать свой код максимально переиспользуемым. При этом хочется иметь компоненты гибкие, но не слишком сложные.
Как правило, компоненты необходимо делать максимально «тупыми», чтобы их было проще поддерживать и тестировать. Но при этом настраиваемыми и гибкими, чтобы можно было их многократно переиспользовать, а не заниматься клонированием компонентов, которые похожи визуально и функционально, но всё-таки чем-то отличаются. Или не добавлять в компоненты кучу параметров, на основе которых включать или отключать какое-либо поведение компонента, но которые по факту будут использоваться в 1 из 100 случаев.
Создавать подводную лодку, которая должна погружаться на самое дно синего моря без риска для жизни экипажа, а потом доработать ее до полетов по голубому небу – задача не из легких.
Angular-компонент – это минимальная единица пользовательского интерфейса, которая должна выполнять одну простую задачу и ничего более. Создавать компоненты на все случаи жизни – это плохая практика. Поэтому приходится искать компромисс между гибкостью и простотой.
Предположим, необходимо создать компонент, состоящий из некоторой обертки, внутри которой есть заголовок и какой-то переключатель, а под ними какой-то контент. Что-то вроде этого:
Зеленым цветом обведен весь компонент, который будет называться виджетом. Переключатель с заголовком выделен красным, а контент – синим. Angular – невероятно мощный фреймворк, создать компонент, похожий на тот, который на картинке, — весьма тривиальная задача для Angular.
А что, если данный компонент сделать более гибким, например, чтобы контент менялся в зависимости от параметров компонента виджета?
Разрулить внешнее представление контента на основе параметра виджета можно, например, при помощи структурной директивы ngIf. Можно будет переключаться между разными представлением. А если представлений будет слишком много, можно воспользоваться еще одной структурной директивой ngSwitch.
А если разные представления будут по-разному реагировать на действия пользователя? Тогда и код компонента будет иметь кучу условных операторов. Но код, в котором много условных операторов, со временем становится тяжело поддерживать, устранять баги или расширять функциональность…
Можно создать компонент виджета таким образом, чтобы он получал любой контент, но при этом пробрасывал выбранные значения панели фильтров в компоненты контентной области. А также хотелось бы иметь возможность пробрасывать параметры из родительского компонента виджета в контент, при этом не затрагивая сам компонент виджета. Для решение этой задачи можно воспользоваться замечательной директивой ngTemplateOutlet, которая позволит «разрулить» визуальное представление компонента. За дополнительной информацией можно обратиться к документации, хотя на мой взгляд там не показана вся ее мощь.
В этом случае компонент виджета можно представить следующим образом:
Директива ngTemplateOutlet принимает объект TemplateRef, который считывается в компоненте при помощи @ContentChild. Для этого потребуется создать простую директиву. Вот ее код:
Параметры из переключателя виджета можно передать в контент при помощи объекта context. Чтобы параметры из context были корректно считаны компонентом, необходимо в родительском компоненте, в нашем случае это AppComponent, не забыть описать их следующим образом:
Таким образом, получился компонент виджета, который принимает и отображает любой контент, при этом сам компонент виджета ничего не обязан знать о контенте. Он просто пробрасывает параметры переключателя. Считывать их или нет – дело контента.