Angular 6. Зачем использовать @ ngrx / store, а не внедрение службы

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

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

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

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

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

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

• Уровни сервисов Angular: Redux, RxJs и Ngrx Store - когда использовать хранилище и почему?
• Магазин Ngrx - Руководство по архитектуре

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

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

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

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

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

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

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

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

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

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

В какой-то момент вам нужно будет написать какой-то api для ваших служб данных, как получать и отправлять данные, запросы и т. Д. Множество правил, таких как неизменность данных, и четко определенные единые пути для изменения данных. Не похоже на серверную часть, но намного быстрее и быстрее, чем вызовы API.

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