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中，将用户重定向到"HOME"页面，然后我们可以使用DI来将AuthService注入需要获取userInfo的任何组件中，只需一个文件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存储的这两篇文章:
I think you should read those two posts about Ngrx store:
- Angular Service Layers: Redux, RxJs and Ngrx Store - When to Use a Store And Why?
- Ngrx Store - An Architecture Guide
如果第一个解释了Ngrx Store解决的主要问题，它还引用了React How-To的这一声明似乎同样适用于原始的Flux，Redux，Ngrx Store或任何一般的商店解决方案":/p>
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":
您将知道何时需要助焊剂.如果不确定是否需要它，就不需要它.
You’ll know when you need Flux. If you aren’t sure if you need it, you don’t need it.
对我来说，Ngrx商店解决了多个问题.例如，当您必须处理可观察对象时，以及某些可观察数据的责任在不同组件之间共享时.在这种情况下，存储操作和减速器可确保始终以正确方式"执行数据修改.
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.
第二篇文章是关于如何通过Facebook的未读消息计数器问题使此类解决方案出现在React世界中的.
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:
- 具有私有主题public可观察和下一个功能的观察者模式
- Ngrx商店
这篇关于Angular 6-为什么使用@ ngrx/store而不是服务注入的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
