为什么我们不直接在 NgRx 中达到状态?
Why don't we reach the state directly in NgRx?
目前我正在学习 NgRx。到目前为止,我了解到:
- 为了改变状态,我们发送所谓的动作
- 一个动作是一个带有标识符和可选负载的对象
- 此操作不会直接到达商店,而是到达所谓的减速器
- reducer 只是一个函数:它从存储中获取当前状态并将操作作为输入
- 在 reducer 中,我们可以查看操作标识符并相应地对状态执行更改(我们作为参数获得)以以不可变的方式(更改副本)更新该状态
- 减速器 return 是一个新状态,它 return 是旧状态的副本,并且这个状态被转发到应用程序商店
- 此减少的状态将覆盖旧状态
我真的不能理解,为什么我们不直接改变存储在store中的state?为什么我们需要这个减速器并在商店中的状态副本上进行更改并将其写回?
我的另一个问题是一段代码:
import { Ingredient } from '../../shared/ingredient.model';
import * as ShoppingListActions from './shopping-list.actions';
const initialState = {
ingredients: [new Ingredient('Apples', 5), new Ingredient('Tomatoes', 10)]
};
export function shoppingListReducer(
state = initialState,
action: ShoppingListActions.AddIngredient
) {
switch (action.type) {
case ShoppingListActions.ADD_INGREDIENT:
return {
...state,
ingredients: [...state.ingredients, action.payload]
};
default:
return state;
}
}
这是一个简单的减速器。在这里,我们通过 returning 旧状态并覆盖 ingredients
.
来创建新状态
是否有可遵循的模式,我们必须如何 return 新状态还是取决于商店中的状态?
- 关于您的第一个问题,即为什么我们不直接更改您商店的状态。答案是不变性
我认为整个 [action > reducer > store > selector] 流程的关键点是 不变性 。它确保没有任何不良副作用,并且您的行为是可预测和可重复的。
这通常会提高性能并通常简化编程和调试。
随着应用程序的扩展,NGRX 架构将使您拥有一致且可靠的状态管理。
- 关于要遵循的模式,我们如何return新的状态。
您只需 return 商店的新状态。这有助于更改以确保始终 return 编辑“新”值。考虑到你的 reducer 的状态是一个对象,我认为“新”状态有助于刷新你的商店的价值,并允许你的应用程序知道 reducer 是否发生了变化。
如前所述,您的状态的直接突变不会导致此刷新。
@wscttc 的回答已经提到了状态的不变性以及为什么这可以防止意外的副作用。因此,如果这个答案对您来说很复杂,请接受它 :) 但是我想提一下另一个优越的优势,即您用于 reducer 的纯函数。您知道这些函数是您应用程序中唯一修改状态的部分。这些功能通常非常简单,而且测试起来也非常简单。通过动作可以很容易的找到触发的地方
目前我正在学习 NgRx。到目前为止,我了解到:
- 为了改变状态,我们发送所谓的动作
- 一个动作是一个带有标识符和可选负载的对象
- 此操作不会直接到达商店,而是到达所谓的减速器
- reducer 只是一个函数:它从存储中获取当前状态并将操作作为输入
- 在 reducer 中,我们可以查看操作标识符并相应地对状态执行更改(我们作为参数获得)以以不可变的方式(更改副本)更新该状态
- 减速器 return 是一个新状态,它 return 是旧状态的副本,并且这个状态被转发到应用程序商店
- 此减少的状态将覆盖旧状态
我真的不能理解,为什么我们不直接改变存储在store中的state?为什么我们需要这个减速器并在商店中的状态副本上进行更改并将其写回?
我的另一个问题是一段代码:
import { Ingredient } from '../../shared/ingredient.model';
import * as ShoppingListActions from './shopping-list.actions';
const initialState = {
ingredients: [new Ingredient('Apples', 5), new Ingredient('Tomatoes', 10)]
};
export function shoppingListReducer(
state = initialState,
action: ShoppingListActions.AddIngredient
) {
switch (action.type) {
case ShoppingListActions.ADD_INGREDIENT:
return {
...state,
ingredients: [...state.ingredients, action.payload]
};
default:
return state;
}
}
这是一个简单的减速器。在这里,我们通过 returning 旧状态并覆盖 ingredients
.
是否有可遵循的模式,我们必须如何 return 新状态还是取决于商店中的状态?
- 关于您的第一个问题,即为什么我们不直接更改您商店的状态。答案是不变性
我认为整个 [action > reducer > store > selector] 流程的关键点是 不变性 。它确保没有任何不良副作用,并且您的行为是可预测和可重复的。
这通常会提高性能并通常简化编程和调试。
随着应用程序的扩展,NGRX 架构将使您拥有一致且可靠的状态管理。
- 关于要遵循的模式,我们如何return新的状态。
您只需 return 商店的新状态。这有助于更改以确保始终 return 编辑“新”值。考虑到你的 reducer 的状态是一个对象,我认为“新”状态有助于刷新你的商店的价值,并允许你的应用程序知道 reducer 是否发生了变化。
如前所述,您的状态的直接突变不会导致此刷新。
@wscttc 的回答已经提到了状态的不变性以及为什么这可以防止意外的副作用。因此,如果这个答案对您来说很复杂,请接受它 :) 但是我想提一下另一个优越的优势,即您用于 reducer 的纯函数。您知道这些函数是您应用程序中唯一修改状态的部分。这些功能通常非常简单,而且测试起来也非常简单。通过动作可以很容易的找到触发的地方