Я недавно изучаю 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:
Если первый объясняет основные проблемы, решаемые Ngrx Store, он также цитирует это утверждение из React How-To, «которое, похоже, в равной степени применимо к исходному Flux, Redux, Ngrx Store или любому другому решению для магазина в целом»:
Для меня магазин Ngrx решает несколько проблем. Например, когда вам приходится иметь дело с наблюдаемыми объектами и когда ответственность за некоторые наблюдаемые данные распределяется между различными компонентами. В этом случае действия магазина и редуктор гарантируют, что изменения данных всегда будут выполняться «правильно».
Он также обеспечивает надежное решение для кеширования HTTP-запросов. Вы сможете сохранять запросы и их ответы, чтобы вы могли убедиться, что на запрос, который вы делаете, еще нет сохраненного ответа.
Второй пост о том, что заставило такие решения появиться в мире React из-за проблемы счетчика непрочитанных сообщений Facebook.
По поводу вашего решения по хранению ненаблюдаемых данных в сервисах. Он отлично работает, когда вы имеете дело с постоянными данными. Но когда несколько компонентов должны будут обновить эти данные, вы, вероятно, столкнетесь с проблемами обнаружения изменений и неправильными проблемами обновления, которые можно решить с помощью:
источник
Существует также третий вариант, например, наличие данных в сервисе и использование сервиса непосредственно в html
*ngFor="let item of userService.users"
. Поэтому, когда вы обновляетеuserService.users
службу после того, как действие добавления или обновления автоматически отображается в html, нет необходимости в каких-либо наблюдаемых, событиях или хранилище.источник
Если данные в вашем приложении используются в нескольких компонентах, то требуется какая-то служба для обмена данными. Есть много способов сделать это.
Умеренно сложное приложение в конечном итоге будет выглядеть как структура внешнего интерфейса, с обработкой данных в сервисах, предоставляя данные компонентам через наблюдаемые объекты.
В какой-то момент вам нужно будет написать какой-то api для ваших служб данных, как получать и отправлять данные, запросы и т. Д. Множество правил, таких как неизменность данных, и четко определенные единые пути для изменения данных. Не похоже на серверную часть, но намного быстрее и быстрее, чем вызовы API.
Ваш api в конечном итоге будет выглядеть как одна из многих уже существующих библиотек управления состоянием. Они существуют для решения сложных проблем. Они могут вам не понадобиться, если ваше приложение простое.
источник