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

使用 angular 从来没有这种顾虑

两个没关系的组件都要使用到 token 用 redux 进行 token 管理

@Chad0000 我比较疑惑的是什么类型的业务使用全局状态管理比较划算

@Promisei 单纯的 useContext 就可以实现的啊

@quehei context 的性能十分差.redux 可以做到按需更新组件.

@catchecken redux 也是把 store 更新到 context 里啊，大家提升代码复杂度使用 redux 是为了提高组件性能？依据是什么呀

@quehei
比如地区登陆状态？当前选择的资源比如当前选择的学校 /项目？还有全局批量上传进度？

以我肤浅的实践来看，多层属性传递的嵌套组件用状态管理确实比较方便，他的场景暂时还没发现是必须的

Redux 产生的时期还不存在 Context API ，现在很多场景下应该可以不用 Redux 的

@quehei 错,store 没有更新

redux context Provider 的 value 没有更新
@quehei

zustand/jotai 才是正解，放弃 redux 吧。

@quehei useContext 必须得是子孙组件才能传吧 如果两个组件毫无关联 useContext 用不到哦

恕我直言，80%的前端页面（展示类、增删改查类）都用不到状态管理。

需要状态管理的是交互多并且存在联动的情况，比如在线 PS 、地图类等。

@Chad0000 #1 Angular 当初尝试过，那个 module 系统就把我干蒙蔽了，TS/JS 本身的 import/export 再加上 ng 自己的 import/export ，一下就上天了。

@Promisei 我的意思是在根组件或者 layout 这种地方挂 context ，不存在两个毫无关联的组件啊。使用 redux 不也是在根组件把 store 传到 context 里面

@catchecken 传一个 valueChange 的方法在 value 里面是不是可以做到更新呢

写过一个需求感觉比较合适，有个开会模式，开会时需要广播当前用户的所有状态（列表内容，过滤器选项等）和操作到其他用户上
然而这个需求是后来才提的，一开始搭架构的时候状态就是分散的，用 swr 管理请求的数据，最后也是把各个操作每个都加上同步

用不到就不用，不用随大流

@quehei 是的.
redux 的顶层 context 传递的是 store 的包裹对象,这个对象的引用是不变的.
组件可以访问 store.
使用 redux 的组件感知 store 更新的原理是发布订阅.组件挂载的时候会订阅 store 更新.store 更新后订阅 store 的组件会自动更新.
跟 context 没有关系.

recoil 或者 jotai ， 比 redux 更好用

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

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

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

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

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

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

一般使用也确实可以不用

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

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

@limi58 是的

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

我都用 Mobx

竟然没人提 flutter

一直都没用过 redux

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

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

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

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

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

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

mobx 还是爽

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

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

一个图片审核类的项目，一次加载一页 180 张图片。会有多种过滤条件选项，和单个数据状态改变，操作多是批次操作，如果父子传值会带来子 card 的重绘，页面会非常卡。

我一般用在全局状态上,比如用户登录状态,多语言设置

@Chad0000 只要有一个依赖注入系统 (比如 inversify.js )，则任何框架都可以做到。 angular 是径直把它做到框架里了仅此而已

推荐 zustand , redux 需要写的代码太多

@czgaotian #44 全局状态管理，相当于是响应式的变量，你用 provide ，首先需要在根组件里初始化，以及在每个子孙组件里进行 inject 。用了全局状态管理之后可以在任意地方进行状态的初始化、修改、取值。在复杂的项目生产里，比单纯的靠组件关系传值方便许多。