Угловая 6 - Зачем использовать @ngrx/store, а не инъекцию услуг

Недавно я изучил Angular 6 с @ngrx/store, в то время как один из уроков - использовать @ngrx/store для управления состоянием, однако я не понимаю преимуществ использования @ngrx/store за сценой.

Например, для простого действия входа и регистрации, ранее используя службу (позвоните в AuthService), мы можем использовать ее для вызова backend api, сохранения "userInfo" или "токена" в AuthService, перенаправления пользователя на "HOME", и мы можем добавить AuthService в любой компонент, где нам нужно получить userInfo с помощью DI, который просто один файл AuthService обрабатывает все.

Теперь, если мы используем @ngrx/store, нам нужно определить Action/State/Reducer/Effects/Selector, которые, вероятно, необходимо записать в 4 или 5 файлах для обработки выше действия или события, тогда иногда нам еще нужно вызвать backend api используя сервис, который кажется намного более сложным и избыточным...

В некоторых других сценариях я даже вижу, что некоторые страницы используют @ngrx/store для хранения объекта или списка объектов, таких как данные сетки., Это для какого-то использования памяти в памяти?

Итак, вернемся к вопросу, почему мы используем хранилище @ngrx/store over service здесь в проекте Angular? Я знаю это для использования " ГОСУДАРСТВЕННОГО УПРАВЛЕНИЯ ", но что такое "ГОСУДАРСТВЕННОЕ УПРАВЛЕНИЕ"? Это что-то вроде журнала транзакций и когда нам это нужно? Зачем нам управлять им на передней панели? Пожалуйста, не стесняйтесь делиться своим предложением или опытом в области @ngrx/store!

Ответы

Ответ 1

Я думаю, вы должны прочитать эти два сообщения о магазине Ngrx:

Если первый из них объясняет основные проблемы, решаемые Ngrx Store, он также цитирует это выражение из React How-To, который, по-видимому, применим в равной степени к оригинальным Flux, Redux, Ngrx Store или любому решению магазина в целом ":

Вы будете знать, когда вам нужен Flux. Если вы не уверены, что вам это нужно, вам это не нужно.

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

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

Вторая статья - это то, что заставило такие решения появиться в мире React с проблемой чтения непрочитанных сообщений Facebook.

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

  • шаблон наблюдателя с частной тематикой Публикация Наблюдаемая и следующая функция
  • Магазин Ngrx

Ответ 2

Существует также 3-й вариант, когда данные *ngFor="let item of userService.users" в сервисе и используются напрямую в html, например *ngFor="let item of userService.users". Поэтому, когда вы обновляете userService.users в сервисе после того, как действие добавления или обновления автоматически отображается в html, нет необходимости в каких-либо наблюдаемых или событиях или хранилище.