什么需求不得不用 redux 这种全局状态管理工具

[quehei]

目前遇到的组件通信都会使用 context 完成业务需求，感觉并不是必须使用全局状态管理。有大佬可以列举一下必须使用全局状态管理才能实现的需求嘛，感觉自己以前业务真的是强行使用的，并不是被逼的不得不用

[ifdef]

recoil 或者 jotai ， 比 redux 更好用

[quehei]

@ifdef 之前用的都是 mobx ，只是在疑惑是不是非得使用全局状态管理实现需求

[shadeofgod]

大部分时候不需要，Redux 在面临着比较高复杂度的应用里才能深刻体会到它的优势，另外现在使用 Redux 的标准姿势是直接使用 Redux Toolkit ，它的 API 设计和完善的类型让使用成本变得非常低而且体验上强很多

[ifdef]

@quehei 哈哈我写 react 的时候也是只用过 context ，感觉完全够用了

[karott7]

已经完全不用 redux 了，context + immer 就可以了

[limi58]

redux 这类的，可以拿来约束团队，如果用 context ，写法可能有 100 种，redux 的话就往对应的模块加东西就可以了

[darlinghsu]

redux 重要的一个点就是，到了要用的时候你就知道要用它了（指 需要它来解决数据管理的问题 如：多&杂

一般使用也确实可以不用

[66beta]

个人观点：
context：配置
redux：数据 /状态

[gouflv]

个人感觉，redux 的模式或者说约束，在大型项目中是成本最低的方案，对标 angular

[cyberpoint]

@limi58 是的

[yor1g]

工程化的东西 解耦 模版化 虽然繁琐但是整体更好控制 而且还有专门工具调试 小项目用了觉得没用

[magichacker]

我都用 Mobx

[mmm159357456]

竟然没人提 flutter

[Baymaxbowen]

一直都没用过 redux🫤

[thulof]

useContext 存在的问题是会有多余的重渲染

[thulof]

上面是指 value 是一个复杂对象的情况下
当然也可以拆成多个简单值，但是这样的话就要套一大堆的 Provider

[charlie21]

耦合这些东西之后会非常 messy.

我设想的是，就页面状态保存而言，即然全站各个页面是从全站各个路由走到的，那么仅就页面状态保存而言，应该是基于全站路由的一个 map 。在全站各个路由载入对应的根组件之前，可以从 map 里找到此路由对应的根组件 将数据填充进去

这时候，状态缓存器是让 “第二次访问某路由” 的时候 和第一次访问此路由时有相同的状态。而这种模式如果被各个路由用到，那么 一个 service 就是必要的。而这种 service 就是：一个被注入各种组件到 service ，一个挂载到根组件到 service 。但它依然不必须是一个全局状态管理器

[jymsy]

context 只能在组件里用，我要在 service 里拿一个全局状态就废了（不通过传参的方式）。

[linshuizhaoying]

mobx 还是爽

[zgk]

redux 在 React Hooks 流行之前，class component 为主的时候，还是蛮普遍的，在 Hooks 流行以后顶部直接 useState / useReducer 已可以满足大部分不太重度的需求，就无需再引入太重型的状态管理库。

redux 模版代码一堆，redux-toolkit 虽然解决了一部分，但也有些臃肿，ts typing 有一定概率踩坑，都带着很多前一个时代的历史包袱。目前的话非集中式的 zustand / jotai / recoil 之类的会更合适些。