为什么不推荐使用store——React中的状态管理难题

react项目中最复杂的工作常常是状态管理问题,然而react生态相比其他框架却有着最多的状态管理库,那为什么状态管理仍然是一件非常复杂的工作呢?因为大多数的状态管理库解决的问题是跨组件数据通信的问题,并非解决状态管理复杂度,甚至他们反而会增加状态管理的复杂度。

状态与数据

react的核心理念是

Plain Text UI=render(state)

react本身可以看成一个render函数,而使用者需要负责state的管理。

拆解state的数据源,可以分为

  • serverData:服务端数据
  • localData:本地数据
  • stateData:派生出该state的其他state
  • uiData:ui数据,比如DomRect,style,以及各种事件

一般我们将state放入store中进行管理,因此从逻辑上,可以拆解为以下几个部分:

  • 业务逻辑
  • store逻辑(状态管理)
  • ui逻辑

从下图中可以看到,store中的逻辑是最复杂的,因为参与其中的数据来源最多。

一个长周期的前端项目,最先腐化的往往就是store层逻辑。

想要降低store逻辑的复杂度,就只能将其中的逻辑,划分到不同的业务Model和UI Ctrl中,让store中只处理state相关逻辑。

Redux/Zustand等状态库的缺陷

下图简单展示了这两个库是如何将数据转为状态的

上图可以看出两个特点:

  1. 无法自由改变数据------必须使用特定的方式
  2. state总是数据的拷贝------需要一直维护数据和状态的联系,且需要immer这类库

这两点反而加重了store中的逻辑复杂度。

解决方案一:Observable

React生态里,Observable方案有两大代表:Mobx和Rxjs。

Mobx方案中,所有业务Model都是state,业务Model的修改驱动试图更新

Rxjs方案中,所有state都是数据流的产物,数据流的更新驱动视图更新

虽然两者的理念/背后实现/落地形式完全不一样,但都能在一定程度上解决状态管理的复杂性------不再关心普通数据与状态数据映射和维护,数据更新即触发组件更新

解决方案二:事件驱动

假设有一个状态 x,A/B场景都修改x,但x的不同字段变更,触发的组件更新行为不一样。

举个例子:

action A 新增了一个新闻渠道,组件应该订阅该渠道,然后更新渲染。

action B 修改了某个渠道展示样式,组件应该更新该样式,但不重新订阅渠道。

如果是用redux来实现,代码可能如下:

组件并不能观察到x是被哪个场景的action修改的,因此组件不仅需要响应x的变更,而且还需要根据变更内容判断是否或如何再次更新。

数据修改和更新的流程可能如下:

不仅触发了多次更新,而且很多情况下,组件难以对数据变更进行溯源。更合理的预期是,直接响应action,而不是状态。

针对这种场景的建议方案是事件/行为驱动。组件订阅A场景的action,该订阅会给组件提供最新的x,这样组件内部就不再需要维护额外标识,也不用关心数据变更的溯源。

相关推荐
打不着的大喇叭37 分钟前
uniapp的光标跟随和打字机效果
前端·javascript·uni-app
无我Code43 分钟前
2025----前端个人年中总结
前端·年终总结·创业
程序猿阿伟1 小时前
《前端路由重构:解锁多语言交互的底层逻辑》
前端·重构
Sun_light1 小时前
6个你必须掌握的「React Hooks」实用技巧✨
前端·javascript·react.js
爱学习的茄子1 小时前
深度解析JavaScript中的call方法实现:从原理到手写实现的完整指南
前端·javascript·面试
莫空00001 小时前
Vue组件通信方式详解
前端·面试
呆呆的心1 小时前
揭秘 CSS 伪元素:不用加标签也能玩转出花的界面技巧 ✨
前端·css·html
susnm1 小时前
Dioxus 与数据库协作
前端·rust
优雅永不过时_v1 小时前
基于vite适用于 vue和 react 的Three.js低代码与Ai结合编辑器
前端·javascript
小皮侠1 小时前
nginx的使用
java·运维·服务器·前端·git·nginx·github