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

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

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

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

11
angular event-delegation ngrx redux tradeoff

5 ответов

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

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

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

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

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

3

во-первых, я не эксперт по теме Отказ.

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

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

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

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

3

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

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

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

1

Я не нашел никаких ссылок на события" bubble up " для верхних компонентов в ngrx / пример-app. Также на переговорах Роба я этого не понял (я мог что-то пропустить).

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

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

0