为什么我们不直接在 NgRx 中达到状态?

Why don't we reach the state directly in NgRx?

目前我正在学习 NgRx。到目前为止,我了解到:

我真的不能理解,为什么我们不直接改变存储在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 新状态还是取决于商店中的状态?

  1. 关于您的第一个问题,即为什么我们不直接更改您商店的状态。答案是不变性

我认为整个 [action > reducer > store > selector] 流程的关键点是 不变性 。它确保没有任何不良副作用,并且您的行为是可预测和可重复的。

这通常会提高性能并通常简化编程和调试。

随着应用程序的扩展,NGRX 架构将使您拥有一致且可靠的状态管理。

  1. 关于要遵循的模式,我们如何return新的状态。

您只需 return 商店的新状态。这有助于更改以确保始终 return 编辑“新”值。考虑到你的 reducer 的状态是一个对象,我认为“新”状态有助于刷新你的商店的价值,并允许你的应用程序知道 reducer 是否发生了变化。

如前所述,您的状态的直接突变不会导致此刷新。

@wscttc 的回答已经提到了状态的不变性以及为什么这可以防止意外的副作用。因此,如果这个答案对您来说很复杂,请接受它 :) 但是我想提一下另一个优越的优势,即您用于 reducer 的纯函数。您知道这些函数是您应用程序中唯一修改状态的部分。这些功能通常非常简单,而且测试起来也非常简单。通过动作可以很容易的找到触发的地方