by Austin Malerba

奥斯汀·马勒巴(Austin Malerba)

为什么要选择useState而不是useReducer (Why you should choose useState instead of useReducer)

通过useState进行本地和全局状态管理的指南 (A guide to local and global state management via useState)

Since the introduction of the React Hooks API, I’ve seen a lot of discussion about useState, useReducer, and when to use one over the other. From these conversations, one would conclude that useState is best suited for simple state with simple update logic and that useReducer is best for complex state shapes with complex update logic.

自从引入React Hooks API以来，我已经看到了很多关于useState ， useReducer以及何时使用useReducer的讨论。 从这些谈话，人们会得出这样的结论useState最适合于用简单的更新逻辑简单状态，并且useReducer是最适合复杂形状的状态与复杂的更新逻辑。

I’m here to convince you that when wrapped in a 4 line custom hook, useState can be just as powerful as, if not more powerful than, useReducer when managing complex state.

我在这里说服您， 当包装在4行自定义挂钩中时，useState在管理复杂状态时的功能与useReducer一样强大，甚至比useReducer强大 。

I don’t like reducers. I’ve tried using them, but I always end up migrating away. Something just feels wrong about dispatching actions to trigger business logic when I could instead do so by invoking a function with arguments.

我不喜欢减速器。 我尝试过使用它们，但最终总是要移走。 当我可以通过调用带有参数的函数来调度操作来触发业务逻辑时，感觉有些不对劲。

And then there’s the fact that instead of encapsulating my business logic into functions, I’m supposed to cluster it all into one giant function partitioned by a bunch of switch cases? I’ve tried libraries such as redux-actions to alleviate this concern, but I still couldn’t deal with it. My dislike for reducers motivated me to search for a better solution.

还有一个事实是，不是将我的业务逻辑封装到函数中，而是应该将其全部聚集到一个由一堆开关盒分隔的巨型函数中？ 我已经尝试使用诸如redux-actions之类的库来减轻这种担忧，但是我仍然无法解决 。 我对减速器的厌恶促使我寻求更好的解决方案。

Let’s review a few common reasons why people choose useReducer over useState:

让我们回顾一些人们为什么选择useReducer不是useState常见原因：

1. So business logic can be centralized in the reducer as opposed to scattered about the component
   因此，业务逻辑可以集中在化简器中，而不是分散在组件上
2. Reducers are pure functions that are easy to test in isolation of React
   Reducer是纯函数，易于在React隔离中进行测试

3. Reducers allow pieces of state that depend on each other to be updated predictably (whereas multiple useState’s might not)

   精简器允许相互依赖的状态可预测地更新(而多个useState可能不会)

If any of these bullets are confusing, I’d recommend having a look at this article. Throughout this guide I will refer back to these items as the three benefits of reducers.

如果这些符号中的任何一个令人困惑，我建议您看一下这篇文章 。 在整个指南中，我将把这些项目称为减速器的三个优点。

第一步：构建一个例子 (Step One: Constructing an Example)

First, I’m going to show you an example that showcases the benefits of reducers I mentioned above, and then I’m going to show you how you can implement the same functionality via useState without sacrificing any of the benefits of a useReducer solution.

首先，我将向您展示一个示例，该示例展示了我上面提到的reducer的好处，然后将向您展示如何通过useState实现相同功能而又不牺牲useReducer解决方案的任何好处。

可冻结柜台 (A Freezable Counter)

To illustrate the pros/cons of useState vs useReducer I’m going to implement a simple counter with a twist. The counter can be incremented, but can also be frozen. If in the frozen state, incrementing the counter will not do anything.

为了说明useState与useReducer优缺点，我将实现一个简单的计数器。 计数器可以增加，但也可以冻结。 如果处于冻结状态，则递增计数器将不会执行任何操作。

As you can see, I’ve implemented our counter above once with useState and once with useReducer. However, StateCounterV1 has some issues. In fact, it doesn’t even work as expected.

如您所见，我已经使用useState和useReducer实现了上面的计数器。 但是， StateCounterV1有一些问题。 实际上，它甚至无法按预期工作。

We would expect that StateCounterV1 should render <div>1</div> because we increment the counter once, then we freeze the counter, and then we increment again. But in reality it renders <div>2</div> because the second invocation of increment doesn’t have access to the new value of frozen. This illustrates benefit #3 of useReducer over useState.

我们希望StateCounterV1应该呈现<div>1 </ div>，因为我们增加了一次计数器，然后冻结了计数器，然后又增加了。 但在现实中it renders的<div> 2 </ DIV>因为牛逼he second增量的调用没有ACC ess to冷冻的新值。 这说明lustrates t #3 of优于useState。

It’s also apparent that in StateCounterV1 our logic to increment the counter resides in the component itself, but in ReducerCounter the logic belongs to the countReducer (benefit #1).

同样很明显，在StateCounterV1用于递增计数器的逻辑驻留在组件本身中，但是在ReducerCounter该逻辑属于countReducer (收益＃1)。

And lastly we see that in order to test the count logic in StateCounterV1 we would have to render it, whereas to test the logic in countReducer, we could do so without ever having to render a component. We could test it simply by invoking it with a state and an action and ensuring it outputs the correct next state (benefit #2).

最后，我们看到，为了测试StateCounterV1的计数逻辑，我们必须渲染它，而要测试countReducer的逻辑，我们可以不必渲染组件就可以这样做。 我们可以简单地通过调用一个状态和一个动作并确保其输出正确的下一个状态(好处2)来对其进行测试。

第二步：崩溃状态 (Step Two: Collapsing State)

In our example, we have a state transition, increment, that updates count but depends on another piece of state, frozen. In instances like this, I find it best to consolidate state. In theory we could always have a maximum of one useState hook per component and still achieve any functionality we want to. But it’s totally okay to useState multiple times as long as the pieces of state do not depend on each other when updating. With that said, let’s see how consolidating state can give us back benefit #3 of reducers.

在我们的示例中，我们有一个状态转换， increment ，它更新count但取决于另一状态，即frozen状态。 在这种情况下，我发现最好合并状态。 从理论上讲，每个组件最多可以有一个useState挂钩，并且仍然可以实现我们想要的任何功能。 但是，多次使用useState完全可以， 只要在更新时状态不相互依赖 。 如此说来，让我们看看巩固状态如何使我们获得减速器的第三大收益。

Now the updater passed to setState in our increment function is self-sufficient. It no longer needs to reach for frozen via closure to determine how to produce the next state. Instead prevState contains all of the state necessary to perform its update logic.

现在，在我们的increment函数中传递给setState的更新程序是自足的。 它不再需要通过封闭来frozen以确定如何产生下一个状态。 相反， prevState包含执行其更新逻辑所需的所有状态。

Because it’s self-sufficient, we no longer have a need to declare it at render time, we could instead lift it out of the component.

因为它是自给自足的，所以我们不再需要在渲染时声明它，而是可以将其从组件中取出。

When we lift state-updater declarations outside of our component, not only do we improve performance, but we prevent ourselves from accidentally depending on variables via closure like we did in StateCounterV1. This pattern is a bit beside the point of this article, but I thought I’d mention it anyway.

当我们将state-updater声明提升到组件之外时，不仅可以提高性能，而且可以防止自己像StateCounterV1那样通过闭包意外地依赖变量。 这种模式与本文的要点略有出入，但我认为无论如何我都会提到它。

第三步：提取业务逻辑 (Step Three: Extracting Business Logic)

At this point StateCounterV2 is still bloated with counter logic. But no worries, all we need to do is extract all of our counter business-logic into a custom hook. Let’s call it useCounterApi.

此时， StateCounterV2仍然StateCounterV2了计数器逻辑。 但是不用担心，我们要做的就是将我们所有的计数器业务逻辑提取到一个自定义钩子中。 我们称它为useCounterApi 。

Now StateCounterV3 is looking good. I’d argue it looks even better than the ReducerCounter. Not to mention this refactor was straightforward because all it really took was a copy/paste of our counter logic into a custom hook. But here’s where things get tricky.

现在StateCounterV3看起来不错。 我认为它看起来比ReducerCounter更好。 更不用说此重构很简单，因为它真正要做的只是将我们的计数器逻辑复制/粘贴到自定义钩子中。 但是，这里变得棘手。

It can be hard sometimes, as developers, to identify where logic belongs. Our brains are erratic and there are some days where it wouldn’t occur to me to extract this logic out of the component into a custom counter hook. That’s why we developers need opinionated interfaces to guide us in the right direction.

作为开发人员，有时可能很难确定逻辑的位置。 我们的大脑动荡不定，在某些日子里，我通常不会将这种逻辑从组件中提取到自定义计数器挂钩中。 这就是为什么我们的开发人员需要审慎的界面来指导我们朝着正确的方向发展。

第四步：创建指导 (Step Four: Creating Guidance)

If we had to describe useCounterApi verbally, we’d probably say,

如果我们不得不口头描述useCounterApi ，我们可能会说，

“It’s a custom hook that creates and returns a counter API.”

“这是一个创建并返回计数器API的自定义钩子。”

Here within lies our first clue. It creates and returns an API. Thus, it is an API Factory. More specifically, it is a Counter API Factory.

我们的第一个线索就在这里。 它创建并返回一个API 。 因此，它是一个API工厂。 更具体地说，它是Counter API Factory。

But we like to abstract things, so the next question is, how can we make a Generic API Factory? Well, let’s remove the “Counter” part from useCounterApi. Now we’re left with useApi. Awesome, now we have our Generic API Factory. But where does our business logic go?

但是我们喜欢抽象事物，所以下一个问题是，我们如何才能创建通用 API工厂？ 好吧，让我们从useCounterApi删除“ Counter”部分。 现在我们剩下了useApi 。 太好了，现在我们有了通用API工厂。 但是我们的业务逻辑去哪儿了？

Let’s think more about how useReducer works.

让我们更多地考虑useReducer工作方式。

const [state, dispatch] = useReducer(reducer, initialArg, init);

The first argument of useReducer is a reducer and the second argument is the initial state. Remember that the reducer contains business logic. Let’s try to mimic this interface.

useReducer的第一个参数是减速器，第二个参数是初始状态。 请记住，reducer包含业务逻辑。 让我们尝试模仿这个界面。

const api = useApi(someApiFactoryFunction, initialArg);

Okay, it feels like we’re getting close to a solution. But now we have to figure out what the heck someApiFactoryFunction is supposed to do.

好的，感觉就像我们正在接近解决方案。 但是现在我们必须弄清楚someApiFactoryFunction应该做什么。

Well, we know it should contain business logic and we know it should be unaware of React so that we can test it without having to render a component. What we also know is that someApiFactoryFunction cannot contain a useState invocation because then it would be aware of React things. But it surely needs state and setState . So we’ll have to inject state and setState some other way. So how do we inject things into functions again? Oh yeah, parameters. Tying this thought exercise together, we end up with the following.

好吧，我们知道它应该包含业务逻辑，并且我们应该知道它不知道React，以便我们可以测试它而无需呈现组件。 我们还知道的是someApiFactoryFunction不能包含useState调用，因为这样它将知道React事物。 但是它肯定需要state和setState 。 因此，我们将不得不以其他方式注入state和setState 。 那么，我们如何将事物再次注入函数呢？ 哦，是的，参数。 将这一思想练习结合在一起，我们得出以下结论。

And there it is. useApi is our magical 4 line custom hook that reveals the true power of useState. API Factory functions supply us with the current state and a setState callback and let us expose an API from them. Let’s think about what kind of benefits we just introduced with this simple contract change.

在那里。 useApi是我们神奇的4行自定义钩子，它揭示了useState的真正力量。 API Factory函数为我们提供当前state和setState回调，并让我们从中公开API。 让我们考虑一下我们通过这种简单的合同变更所带来的好处。

counterApiFactory is unaware of React, which means we can now test it simply by passing a state object and a setState callback (Reducer benefit #2 achieved).

counterApiFactory不了解React，这意味着我们现在可以简单地通过传递state对象和setState回调(实现Reducer好处＃2)来对其进行测试。

useApi expects an API Factory, which means we’re telling the developer they need to write API Factory functions with the signature ({state, setState}) => api . This means, even on my off days when my brain struggles to recognize that a cluster of logic can be refactored into a stateful API, I have this nice little useApi function prompting me to throw all of my stateful business logic into a centralized location.

useApi需要一个API Factory，这意味着我们要告诉开发人员他们需要使用签名({state, setState}) => api来编写API Factory函数。 这意味着，即使在我休假的日子里，当我的大脑难以识别可以将逻辑集群重构为有状态的API时，我也会le use Api函数很好地提示我将所有有状态的业务逻辑都放在一个集中的位置。

第五步：优化 (Step Five: Optimizing)

As it stands, useApi isn’t as efficient as it could be. Any component that consumes useApi will invoke useApi on every render, which means apiFactory will also be invoked on every render. It’s not necessary to invoke apiFactory on each render, but rather only when state has changed. We can optimize useApi by memoizing the execution of apiFactory.

就目前而言， useApi效率不如useApi 。 任何消耗useApi组件useApi将在每个渲染useApi上调用useApi ，这意味着apiFactory也将在每个渲染器上被调用。 不必在每个渲染apiFactory上调用apiFactory ，而仅在state更改时调用。 我们可以通过useApi的执行来优化apiFactory 。

测试API工厂 (Testing an API Factory)

Now that we’ve implemented our useApi hook, let’s look at how we’d test an API Factory.

现在我们已经实现了useApi挂钩，让我们看一下如何测试API工厂。

It’s simple enough to create a wrapper around our counterApiFactory that mimics the behavior of state/setState. With this helper function we can test our counterApiFactory in a very natural way.

在我们的counterApiFactory周围创建一个模仿state / setState行为的包装器非常简单。 使用此辅助函数，我们可以非常自然地测试我们的counterApiFactory 。

useApi vs useReducer (useApi vs useReducer)

Let’s now compare these two solutions.

现在让我们比较这两种解决方案。

逻辑封装 (Logic Encapsulation)

In both solutions, logic to update state is centralized which allows for easy reasoning, debugging, and testing. However reducers only provide a mechanism to update state, they do not provide a mechanism to retrieve state. Instead it’s common to write selectors and apply them downstream from the reducer. What’s nice about our useApi solution is that it encapsulates not only logic to update state, but also logic to retrieve state ?.

在这两种解决方案中，用于更新状态的逻辑都是集中的，这使得推理，调试和测试变得容易。 但是，reduce只提供更新状态的机制，而没有提供检索状态的机制。 取而代之的是编写选择器并将其应用到减速器的下游。 我们的useApi解决方案的useApi是，它不仅封装了更新状态的逻辑，而且还封装了检索状态的逻辑？

更新状态 (Updating State)

To update state with useReducer, we need to dispatch actions. To update state with useApi we need to invoke updater methods. A potential advantage of reducers in this scenario is that multiple reducers could listen to the same action. However, this also comes with a downside: execution flow is not intuitive once an action has been dispatched. If I need multiple, disparate pieces of state to be updated at once, I’d rather do it explicitly with multiple back-to-back API method calls, than through a single dispatched action that’s broadcasted to all reducers.

要使用useReducer更新状态，我们需要调度动作。 要使用useApi更新状态，我们需要调用updater方法。 在这种情况下，Reducer的潜在优势是多个Reducer可以侦听同一动作。 但是，这也有一个缺点：一旦分派了动作，执行流程就不直观。 如果我需要一次更新多个不同的状态，我宁愿使用多个背对背API方法调用来显式地进行此操作，而不是通过广播到所有reducer的单个调度动作来显式地进行更新。

性能 (Performance)

One nice thing about reducers is that, via reducer composition, multiple reducers can listen to a single dispatched action which means you can have many parts of the state change in just a single render. I have not come up with a solution for API Factory composition (though it’s surely possible). For now my solution is to invoke state updaters back-to-back when necessary which could lead to more renders than a reducer approach.

关于化简器的一件好事是，通过化简器组成，多个化简器可以侦听单个调度的动作，这意味着您可以在单个渲染中拥有状态变化的许多部分。 我还没有想出API工厂组合的解决方案(尽管肯定有可能)。 现在，我的解决方案是在必要时背靠背调用状态更新程序，这可能比reducer方法导致更多的渲染。

样板 (Boilerplate)

Reducer-based solutions are notoriously boilerplate-y (especially when working with redux). Action type declarations take up some extra space and dispatching actions tends to be a bit more verbose than just invoking a function with arguments. For these reasons I’d say useApi has a slight edge on useReducer in terms of boilerplate code.

众所周知，基于Reducer的解决方案非常简单(尤其是在使用redux时)。 动作类型声明会占用一些额外的空间，而分派动作往往比仅带参数的函数更为冗长。 由于这些原因，我会说useApi有一个轻微的边缘useReducer中的样板代码方面。

可测性 (Testability)

Both reducers and API Factories are easy to test.

减速器和API工厂都易于测试。

进一步探索用途 (Further Exploring useApi)

Let’s have a look at some other cool things we can do with useApi.

让我们来看看我们可以使用useApi其他一些酷操作。

I’ve taken the time to implement the classic Redux Todo List Example via useApi. Here’s how todosApiFactory looks in the useApi implementation.

我已经花了一些时间通过useApi实现经典的Redux Todo List Example 。 这是todosApiFactory在useApi实现中的外观。

One gross thing you may have noticed in the code above is the repetition of the following boilerplate.

您可能在上面的代码中注意到的一件事是重复以下样板。

setState(prevState => ({  ...prevState,  /* … */});

Assuming our state is an object and because setState does not support shallow merging, we need to do this to ensure we preserve any state that we’re not currently working with.

假设我们的state是一个对象，并且因为setState不支持浅层合并 ，那么我们需要执行此操作以确保保留当前不使用的任何状态。

We can reduce some of this boilerplate and get some other cool benefits from a library called immer. immer is an immutability library that lets you write immutable code in a mutable way.

我们可以减少一些样板，并从名为immer的库中获得其他一些很酷的好处。 immer是一个不变性库，可让您以可变的方式编写不变的代码。

As you can see, immer helps us remove some of that annoying boilerplate code required when writing immutable updates. But beware, the convenience of immer is also its Achilles’ heel. A developer who’s introduced to the concept of immutability through immer might not fully understand the consequences of mutations.

如您所见，沉浸式帮助我们删除了编写不可变更新时所需的一些烦人的样板代码。 但是要注意，沉浸的便利性也是它的致命弱点。 通过沉浸式引入不变性概念的开发人员可能不会完全了解突变的后果。

But wait a second, useApi only provides state locally, but the Todo List Example uses redux to provide a global state solution.

但是请稍等， useApi仅在本地提供状态，但“ 待办事项列表示例”使用redux提供全局状态解决方案。

具有API Factories全球商店 (Global Stores with API Factories)

Let’s see how we can create global stores from API Factories.

让我们看看如何从API工厂创建全局商店。

Not bad at all, right? Context makes global state super easy in React. So we now have a global state management solution to use with API Factories.

一点都不差吧？ 上下文使React中的全局状态变得异常简单。 因此，我们现在有了一个可以与API工厂一起使用的全局状态管理解决方案。

Below is the working API Factory Todo List Example.

以下是有效的API Factory Todo List示例。

结论 (Conclusion)

To wrap it up, this article contains three functions that you might find useful.

总结一下，本文包含三个可能会有用的功能。

These functions provide useful abstractions for local and global state management powered by useState.

这些功能为useState支持的本地和全局状态管理提供了有用的抽象。

Don’t get me wrong, reducers come with a lot of perks, but I just can’t rest easy with the interface they offer. Both useApi and useReducer offer viable solutions to complex state management. It’s really a matter of preference.

不要误会我的意思，Reducer带来很多好处，但是我只是对它们提供的界面感到不安。 useApi和useReducer为复杂的状态管理提供可行的解决方案。 这实际上是一个偏好问题。

One useful takeaway is that libraries don’t have to perform complex logic to be useful. A lot of the value libraries and frameworks offer does not have to do with the logic they perform, but rather the guidance they give the developer. Good libraries/frameworks force the developer to follow known patterns via explicit and opinionated interfaces. useApi does very little computationally, but encourages the developer put their stateful business logic in a centralized location, all the while avoiding pollution of components.

一个有用的收获是，库不必执行复杂的逻辑就可以使用。 许多价值库和框架提供的值与它们执行的逻辑无关，而与它们给开发人员的指导有关。 好的库/框架迫使开发人员通过显式且自觉的界面遵循已知的模式。 useApi在计算上做的很少，但是鼓励开发人员将其有状态业务逻辑放在一个集中的位置，同时还要避免组件污染。

翻译自: https://www.freecodecamp.org/news/why-you-should-choose-usestate-instead-of-usereducer-ffc80057f815/