redux 初始状态作为第一个参数是一种不好的做法

Question

在 redux 中，初始状态是通过使用第一个参数 state 的默认参数来提供的，而第二个参数 action 没有默认值。但是，我认为这是一种代码异味（Airbnb guidelines 等其他人也是如此），因为您总是需要提供第一个参数（然后会使用 undefined 来获取默认值，这很麻烦）。我完全理解您为什么要提供该初始状态，但是为什么他们不切换参数，因此默认值是第二个以使代码符合通用准则？

// bad
function someReducer(state = 0, action) {
  switch (action.type) {
  default: return state;
}

// good
function someReducer(action, state = 0) {
  switch (action.type) {
  default: return state;
}

redux 迫使我们的开发人员使用一种不好的做法，鼓励他们在其他地方这样做。为什么 redux-developers 仍然会选择这样的架构？

更新

为什么首先使用默认值是一种不好的实践，原因在于语言设计本身。在 JS 中，解释器无法判断开发人员的意图是什么。举个例子：

const giveMe = (goodHuman = true, candy) => (goodHuman && candy) ? 'candy' : 'tea';

那么，我会得到糖果吗？

giveMe(true) // not clear! (but it is 'tea')

我无法使用单个参数访问糖果！但我猜开发商会希望我得到一些，对吧？但是，candy 始终为undefined，使得条件表达式的计算结果为undefined。作为后备，执行 else 部分。这不是一个明确的意图，也很难猜测开发人员想要表达什么。此类代码不会通过我们的审核流程/QA。

因此，在以下示例中，开发人员确保我们可以在需要时访问该糖果，并且他认为我们默认情况下是应该获得该糖果的好人。：

candy giveMe = (candy, goodHuman = true) => (goodHuman && candy) ? 'candy' : 'tea';
giveMe(true) // finally we get the candy!

由于人们说将默认值放在前面是 redux 的最佳实践，因此我认为 redux 在 reducer 签名上的设计很糟糕！这可能源于 reducer 函数通常具有类似签名的事实，但 它们不会将第一个参数设为可选，这没有任何意义！它认为使用 undefined 调用函数使其成为“最佳实践”是 redux 的错误设计决策。

Answer 1

作为(state, action) 的“reducer”函数的签名基于您将传递给Array.prototype.reduce() 的回调的签名，例如：

const sum = [1, 2, 3].reduce( (sumInProgress, currentNumber) => {
    return sumInProgress + currentNumber;
});

第一个参数是“累加器”或“先前状态”值，第二个参数是“当前项”值。在 Redux 中，这些值对应于现有状态和当前操作。因此，该函数签名有明确的先例。

至于初始化状态：您可以始终将应用范围的初始状态作为第二个参数提供给createStore(rootReducer, preloadedState)。但是，鼓励的方法是每个 slice reducer 都应该注意提供自己的初始状态，并在使用状态值undefined 调用它时这样做。内置的 combineReducers 函数将确保每个 slice reducer 在启动时被调用，从而整齐地初始化整个应用程序状态的每一部分。

虽然您可以在函数内部显式检查if(state === undefined) return initialState，但将初始状态声明为state 参数的默认值会更短更简单。

所以，总的来说，这不是一个不好的做法，而是一个最佳使用 Redux 的做法。请记住，像 AirBNB 指南这样的样式规则集只是意见，而不是每个人都必须遵守的严格规则。

有关 Redux 状态初始化如何工作的更多信息，请参阅 Redux 文档的 Structuring Reducers - Initializing State 部分。