Я пытаюсь найти правильный способ изменить свое состояние в приложении ngrx, так как состояние довольно сложное и зависит от многих факторов.Этот вопрос не о том, как правильно выполнить один фрагмент кода, а о том, как разработать такое программное обеспечение в целом, что нужно делать и чего не следует делать при поиске хакерских решений и обходных путей.
Приложение «эволюционировало»время, и я не хочу делиться этим процессом абстрактно, чтобы прояснить мою точку зрения:
Стадия 1
Состояние содержит сущности.Они представляют узлы в дереве и связаны идентификаторами.Модификация или добавление объекта требует проверки типа узлов, с которыми должны быть связаны новые / модифицированные.Также возможно, что после модификации узла другие узлы должны были быть обновлены.
Решение было: создать функции, которые выполняют эту работу.Вызывайте их прямо в редукторе, чтобы все всегда было актуально и синхронизировано при использовании (есть службы, которые могут изменять состояние).
Этап 2
Конфигурациядобавляется в состояние, влияющее на способ изменения / создания автоматически изменяемых узлов.Эта конфигурация сохраняется в своем собственном состоянии прямо в корневом состоянии.
Решение:
1) Измените действия, чтобы также взять необходимые данные из конфигурации.
2) Изменить места, где создаются / отправляются действия (добавить некрасивую оболочку
this.state.select(fromRoot.getX)
.first()
.(subscribe(element => {this.state.dispatch(new Action({...old_payload, newPayload: element}))})
вокруг диспетчерских вызовов)
3) изменять функции, выполняямодификация узла и
4) добавление передачи аргументов к вызовам функций внутри редуктора
Стадия 3
Теперь меня спросиличтобы снова добавить в процесс другую конфигурацию, также полученную с помощью бэкэнда и сохраненную в другом состоянии прямо под корневым состоянием
Состояние теперь выглядит так:
root
|__nodes
|__config_1
|__config_2
я только что собиралсяповторите шаги, как в шаге 2, но действия становятся действительно со всеми переданными данными, и функции должны переносить большое количество данных.Это кажется неправильным, когда я на самом деле отправляю действие на состояние, содержащее всю необходимую информацию.
Как я могу обработать это правильно?
Некоторые идеи уже были:
использовать эффекты: они могут получить все из того состояния, в котором они нуждаются, и могут создавать все - поэтому мне нужно только отправить действие только с полезной нагрузкой действий, после чего эффект может захватить все из состояния, в котором он нуждается,Мне не нравится эта идея, потому что она запускает асинхронные задачи для изменения состояния и добавления действий, не меняющих состояние.
использовать сервис: с состоянием удержания сервиса это было бы очень похоже на эффекты, но без использования действий просто для создания асинхронных вызовов, которые затем отправляли бы действия, которые действительно изменяют состояние.
делает всеНаполните компонент: на данный момент компоненты остаются довольно простыми, когда дело доходит до изменения состояния, так как я предпочитаю идею о том, что действия несут как можно меньше данных, так как редукторы могут получить доступ к состоянию, чтобы получить свои данные - но именно здесьпроблема, на этот раз я не могу получить нужные мне данные.