Архитектура Redux / ngrx/store: почему бы не отправлять действия из тупых компонентов?

Question

Я создаю приложение Angular 2 ngrx/store и пытаюсь понять лучшие практики.

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

Но я не понимаю, почему мы хотели бы "накапливать" события от глупых компонентов до интеллектуальных компонентов, прежде чем отправлять действие в магазин. Является ли единственной причиной иметь повторно используемые компоненты? Мне кажется, что большинство компонентов в любом случае не используются повторно, потому что не так много ситуаций, когда я бы хотел, чтобы все было идентично, включая CSS. Есть ли какие-то другие преимущества, которые мне не хватает? С точки зрения ремонтопригодности / читабельности, разве не лучше иметь возможность просто видеть действие, отправляемое прямо в компоненте, где происходит взаимодействие?

Answer 1

Я полностью согласен с вами, и у меня такое же сомнение.

Я ожидаю, что компонент испустит действие с помощью диспетчера (который для ngrx/store это само хранилище) вместо перемещения этой логики в контейнер (фактическое приложение).

Таким образом, компонент отделен от контейнера, и контейнеру не нужно знать о действиях: он просто прослушает изменение состояния и передаст возможные данные, если это необходимо.

С другой стороны, Введение в ngrx/store продвигает дизайн с более умным контейнером, который много знает о базовых компонентах.

Честно говоря, я пока не вижу явного победителя: я просто думаю, что диспетчеризация действий из компонента проще, чище и ближе к архитектуре Elm, которая была одним из вдохновителей Redux.

Answer 2

Во-первых, я не эксперт по этому вопросу.

• Я чувствую, что интеллектуальные компоненты, управляющие немыми компонентами, на самом деле называют паттерном посредника. Использование этого шаблона гарантирует, что меньшее количество компонентов будет иметь дело с store, тем самым усиливая вшивую связь.
• Простота обслуживания: если вам нужно выполнить рефакторинг и массовое переименование действий, это легче сделать, когда действие присутствует в меньшем количестве мест.
• Имея центральное место, которое имеет дело с actions позволяет для быстрого обзора архитектуры. Также горячая замена store логику доступа можно сделать проще.
• И как уже было сказано: повторное использование. Вы можете обмениваться и повторно использовать немые компоненты между проектами, которые имеют или не имеют архитектуру ngrx.
• Также используйте повторно в том же проекте, просто подключив разные inputs а также outputs, Пример: A dropdownComponent может иметь много вариантов использования, которые требуют различных входов и выходов.

Answer 3

Одной из основных причин является повторное использование.

С точки зрения MVC, думайте о своем интеллектуальном компоненте как о контроллере, а о своем немом компоненте как о своем представлении.

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

Answer 4

Я хотел бы расширить данные ответы.

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

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

Answer 5

Я не нашел никаких ссылок о событиях " всплытия " на верхние компоненты в https://github.com/ngrx/example-app. Кроме того, на выступлениях Роба я этого не понимаю (возможно, я что-то пропустил).

Я просто использую все ngrx, как в примере, и сейчас все в порядке. ngrx / store для хранения данных, ngrx / эффекты для цепных действий (как я могу упростить) и "промежуточное ПО" в образе "действий", описывающих все, что вы можете сделать с одной из частей магазина.

И затем, когда это кажется наиболее удобным, я использую действие (я просто проверяю, что все действия, используемые в файле, относятся к текущему классу).