周三下午三点,办公室又吵起来了。一位前端兄弟把需求评审会变成了状态管理辩论赛:“直接用 Context 啊,这还要讨论?”“Redux 才是标准方案!”“Zustand 不香吗?”项目代码还没写一行,工具先选了三小时。我打开购物车需求——一个导航栏上的图标要显示商品数量,侧边栏要能删改,产品卡片里有个“加入购物车”按钮。
他们把问题想复杂了。产品卡片上的“加入购物车”按钮,点击后短暂显示“已添加!”,1.5 秒后消失。这段交互只需要一个布尔值:justAdded。它只活在 ProductCard 组件内部,兄弟组件 CartSidebar 不知道,祖辈 App 不关心,页面切换后重置也没人在意。这就是 useState 的教科书场景。但会议上没人提它——因为 useState 不够“厉害”,不值得争论。
![]()
这恰恰是大多数团队踩坑的起点:不先定义“状态属于谁”,就急着上全局方案。我见过一个表格组件的分页页码被塞进 Redux,就因为后端同事说“状态要集中管理”。还见过用来控制弹窗开关的 boolean,跟着 Context 一路传了五层 props。这些都不是架构问题,是忘了 React 原本的哲学。
useState 设计之初就划好了边界:它只管一个组件自己的事。满足三个条件时,它就是你唯一需要的工具:
- 这段状态不被其它组件读取;
- 不要求跨页面存留;
- 不与兄弟节点或远祖组件联动。
购物车的例子很诚实。ProductCard 里 justAdded 这个值,正是典型“暂时、私有且不需要外传”的状态。它独立完成反馈动画,不污染父级,不拖累渲染,1.5 秒后自动复位。换成 Context?为了一个按钮的视觉效果,你要先创建 Provider,再在消费端写 useContext,还要考虑重新渲染的范围。换成 Redux?你得写 action、reducer,再 dispatch,然后盯着控制台看有没有多余订阅。这已经不是杀鸡用牛刀,是拿着牛刀去切豆腐——豆腐碎了,手也酸了。
争论工具前,先去画组件树。问问自己:这个状态究竟是“全局的”,还是“某个组件的私事”?如果答案模糊,那就先用 useState。等 props 真正钻到第三层、第五层,等两个不相干的子树真的需要同一份数据时,再对照你的问题去挑 Context、Zustand 或者 Redux。那时你手里有具体的痛点,而不是道听途说的“这个库很流行”。
下次再有人把技术选型聊成信仰之争,你可以把产品卡片的按钮效果打开,问他:“这个状态,你想用哪种姿势管理?”十有八九,他会闭嘴。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.