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

Question

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

// 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 开发人员仍会决定采用这种架构？

更新

为什么首先使用默认值是坏做法的原因来自于语言设计本身。在 JS 中，解释器无法判断开发人员的意图。例如:

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

那么，我能得到糖果吗？

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

我无法通过单个参数访问糖果!但我想开发商会希望我得到一些，对吧？但是，candy 始终是 undefined，这使得条件表达式的计算结果为 undefined。作为回退，else-part 被执行。开发者想要表达的意思不明确，也很难猜到。此类代码不会通过我们的审核流程/QA。

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

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

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

Answer 1

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

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

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

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

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

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

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