useReducer 这个东西到底有啥用, 简单的东西搞复杂化是为了啥?

确实 reducer 不是最优的，但这主要是取决于 js 本身的限制，但相比于 state 和一大堆 callback 乱改 state 还是有一定好处的，至少你能从 useReducer 那里看到 state 有可能的变化方式（当然你也可以摆烂只做 setState 一样的事情，那种就不提了），比如限定 state 只能+1 或者-1 ，如果用 setState ，这个意思是无法表达出来的
不过你这把所有 click 函数都直接 dispatch 的情况，多半还是存在一些问题，相当于另一个方向摆烂，我建议可以放点代码例子来看看是不是这个方向的写法
某种意义上说可以理解为写了一个状态机，reducer 函数就是状态转移方程，dispatch 则是触发状态转移的 trigger

这玩意除了给自己添堵真没啥用, 用起来麻烦, 找起来麻烦

这个本来就是可选的啊，场景简单的话直接上 mobx 之类就可以了吧。

https://github.com/pmndrs/zustand
最近在用这个，感觉更舒服一点

reducers 是描述 action 如何改变 state 。思想是 Facebook 研究的一种 Flux 架构，用途是管理数据流，Flux 数据流周期就是这个样子：

Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores -------+
|
| V
+-- (Controller-Views "change" event handlers) ---- (Stores emit "change" events) --+

先有了思想，再实现的代码，于是 reducers 就实现成了这个复杂的样子。但从某些实际场景来说，比如 op 说的 click 的情况，action 直接对应函数不是更方便吗？这种场景确实更方便，毕竟 Flux 架构环节还是挺多的挺复杂的。
这就是它这么复杂的原因。
至于要不要去用它，得看实际业务情况。
开卷有益。
尽信书不如无书。

当一个状态是从其他很多状态合并计算过来的时候，用 useReducer 批量更新，减少 rerender 次数

这玩意儿利于调试是要配合 devtools 用的

解决了要传十几个不同的 callback 要给子组件写十几个参数的问题

dispatcher 是一个独立于视图层的层，在这处理好之后，再把计算结果传递给视图层。这样一来，视图层会更薄（更不携带计算量）了，只负责 event handler 和渲染数据

层本身就是答案。至于 “为什么要切出额外一层” 那么一个人只能告诉你 这可以对他而言降低心智负担，对他而言也的确如此。但对你而言未必，你不就觉得是多此一举吗？如果你没觉得它在 “降低心智负担” 那么等你遇到了就知道了

所有的答案都是为了特定的问题应运而生的，理解答案是无助于理解答案的，理解问题是有助于理解答案的。

@Leviathann 这个你可以定义一个 object obj = {}, 把这些参数都挂载到这个 obj 上, 然后给子组件只传这个 obj 就行了

@charlie21 但是我把所有与视图无关的函数都抽到一个.js 文件里, 一样能达到你这样的效果, 还不用绕这么多弯弯.
我只能归结为外国人的思维跟中国人就是不一样. 就跟邮件地址一样, 我们觉得从大范围到小范围很快就能锁定具体位置, 老美偏要反过来.

你说的对，在 2023 年 useReducer 和 Redux 可以说是最落后的状态管理方案了。

现在有好的多的状态管理解决方案：
喜欢 Redux 这种单向数据流思维的可以用： https://github.com/pmndrs/zustand
喜欢 React Hook 函数式思维的可以用： https://github.com/pmndrs/jotai
喜欢 vue3 reactive 的可以用： https://github.com/pmndrs/valtio

早期 React 状态管理大家都是摸着石头过河，难免会走出 useReducer 和 Redux 的弯路。