我正在尝试将ngrx添加到我的角度项目中。但我不知道我是否还需要服务。因为组件可以发送动作。这是否意味着我不必使用除ngrx / store之外的任何其他服务?
答案 0 :(得分:4)
我仍然使用服务来封装逻辑。通常,组件与服务通信并且服务与商店通信。
我发现服务的作用范围不仅仅是存储,因此删除它们会将太多的职责/业务逻辑放入商店组件中。
我的商店专注于简单的api式操作,这些操作简短且易于测试,例如
static INITIALIZE_CONFIG_REQUEST = 'INITIALIZE_CONFIG_REQUEST';
static INITIALIZE_CONFIG_SUCCESS = 'INITIALIZE_CONFIG_SUCCESS';
static INITIALIZE_CONFIG_FAILED = 'INITIALIZE_CONFIG_FAILED';
static INITIALIZE_CONFIG_TEMPLATE_ERROR = 'INITIALIZE_CONFIG_TEMPLATE_ERROR';
createInitializeConfigRequest() { // separate from invoking call for easier testing
return {
type: ConfigActions.INITIALIZE_CONFIG_REQUEST,
httpRequest: {
url: 'api/path/to/config',
successAction: this.createInitializeConfigSuccess,
failedAction: this.createInitializeConfigFailed,
validateResponse: (data) => this.checkTemplate(data)
}
};
}
initializeConfigRequest() { // called by config.service
this.store.dispatch( this.createInitializeConfigRequest() );
}
createInitializeConfigSuccess(data) {
const payload = data;
return {
type: ConfigActions.INITIALIZE_CONFIG_SUCCESS,
payload
};
}
createInitializeConfigFailed(error) {
return {
type: ConfigActions.INITIALIZE_CONFIG_FAILED,
payload: {
error
}
};
}
使用这种模式,我可以更轻松地添加中间件,例如上面处理httpRequest和Response验证的中间件。
大多数减少都是通过一个通用的reducer完成的,它假设有效负载属性与store属性完全对应。这是我最喜欢的惯例,因为现在我有一套针对通用减速器的全面测试,而不是n次减速器的n次重复测试。
genericActionHandler(state, action) {
if (!action.payload) {
return state;
}
const newState = {...state};
Object.assign(newState, action.payload);
return newState;
}
希望能让你感受到我的建筑。
答案 1 :(得分:-2)
效果专门用于与API和应用程序外部的其他实体进行交互,并在NGRX规范中进行了定义。他们不知道,也不应该知道本地路由器状态,生命周期挂钩之类的东西:他们甚至不知道组件的存在,除非明确地通过动作有效负载了解了这一点。
另一方面,注入组件的服务确实具有这些知识,或者可以轻松地用这些知识提供。
这样,当您想做任何独立且仅适用于内部应用程序的事情时,就可以使用服务。当您希望某个动作触发某种外部交互(例如API调用,打开Web套接字或ssh连接)时,可以使用效果。
注意:如果希望在组件中创建和销毁服务,则需要将其定义为组件元数据内,组件本身内的提供者,因为在模块级别提供的服务将是单例。 / p>
其他阅读内容:
https://medium.com/@m3po22/stop-using-ngrx-effects-for-that-a6ccfe186399