Angular 6 - 为什么使用 @ngrx/store 而不是服务注入 [英] Angular 6 - Why use @ngrx/store rather than service injection
问题描述
我最近正在使用@ngrx/store 学习 Angular 6，其中一个教程是使用 @ngrx/store 进行状态管理，但是我不明白在幕后使用 @ngrx/store 的好处.
I am recently learning Angular 6 with @ngrx/store while one of the tutorial is to use @ngrx/store for state management, however I don't understand the benefit of using @ngrx/store behind the scene.
例如，对于简单的登录和注册操作，之前通过使用服务(我们称之为 AuthService) 我们可能会使用它来调用后端 api，存储userInfo"或token"在 AuthService 中，将用户重定向到主页"页面，我们可以在需要使用 DI 获取用户信息的任何组件中注入 AuthService，这只是一个文件 AuthService 处理所有事情.
For example, for a simple login and signup action, previously by using the service(Let's call it AuthService) we might use it to call the backend api, store "userInfo" or "token" in the AuthService, redirect user to "HOME" page and we can inject AuthService in any component where we need to get the userInfo by using DI, which simply that one file AuthService handles everything.
现在如果我们使用@ngrx/store，我们需要定义Action/State/Reducer/Effects/Selector，它可能需要写入4或5个文件来处理上述动作或事件，那么有时我们仍然需要使用服务调用后端 api，这似乎要复杂得多和多余...
Now if we are using @ngrx/store, we need to define the Action/State/Reducer/Effects/Selector which probably need to write in 4 or 5 files to handle above action or event, then sometimes still we need to call backend api using service, which seems much much more complicated and redundant...
在其他一些场景中，我什至看到一些页面使用@ngrx/store 来存储对象或对象列表，如网格数据.，是用于某种内存存储使用情况?
回到这个问题，为什么我们在 Angular 项目中使用 @ngrx/store 而不是服务注册存储?我知道这是用于状态管理"的用法，但究竟什么是国家管理"?那是类似于事务日志的东西吗?我们什么时候需要它?我们为什么要在前端管理? 欢迎在@ngrx/store 专区分享您的建议或经验！
So back to the question, why are we using @ngrx/store over service registration store here in Angular project? I know it's for "STATE MANAGEMENT" usage, but what exactly is the "STATE MANAGEMENT"? Is that something like transaction log and When do we need it? Why would we manage it on the front end? Please feel free to share your suggestion or experience in the @ngrx/store area!
推荐答案
我觉得你应该看看这两篇关于 Ngrx store 的帖子:
I think you should read those two posts about Ngrx store:
如果第一个解释了 Ngrx Store 解决的主要问题，它还引用了 React How-To 中的声明这似乎同样适用于原始 Flux、Redux、Ngrx Store 或任何一般的商店解决方案":
If the first one explains the main issues solved by Ngrx Store, it also quote this statement from the React How-To "that seems to apply equally to original Flux, Redux, Ngrx Store or any store solution in general":
您会知道何时需要 Flux.如果您不确定是否需要它，那么您就不需要它.
You’ll know when you need Flux. If you aren’t sure if you need it, you don’t need it.
对我来说，Ngrx 商店解决了多个问题.例如，当您必须处理 observable 以及在不同组件之间共享某些 observable 数据的责任时.在这种情况下，存储操作和化简器确保数据修改始终以正确的方式"执行.
To me Ngrx store solves multiple issues. For example when you have to deal with observables and when responsability for some observable data is shared between different components. In this case store actions and reducer ensure that data modifications will always be performed "the right way".
它还为http请求缓存提供了可靠的解决方案.您将能够存储请求及其响应，以便验证您发出的请求尚未存储响应.
It also provides a reliable solution for http requests caching. You will be able to store the requests and their responses, so that you could verify that the request you're making has not a stored response yet.
第二篇文章是关于是什么让这样的解决方案出现在 React 世界中，并带有 Facebook 的未读消息计数器问题.
The second post is about what made such solutions appear in the React world with Facebook's unread message counter issue.
关于您在服务中存储不可观察数据的解决方案.当您处理常量数据时，它工作正常.但是当多个组件必须更新这些数据时，您可能会遇到变更检测问题和不正确的更新问题，您可以通过以下方式解决:
Concerning your solution of storing non-obvervable data in services. It works fine when you're dealing with constant data. But when several components will have to update this data you will probably encounter change detection issues and improper update issues, that you could solve with:
- 具有私有主题、公共可观察对象和下一个函数的观察者模式
- Ngrx 商店
这篇关于Angular 6 - 为什么使用 @ngrx/store 而不是服务注入的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
