其实“rea”这个标题我第一次看到的时候也愣了一下——就三个字母没有任何上下文。但放在这几年做前端基础架构的语境里我很快就明白过来这多半是一个内部状态管理模块的项目代号。恰好我们团队之前也经历过一段“状态管理大乱斗”的时期各种方案混着用维护成本极高。后来我花了两周时间从零手写了一个轻量级的响应式状态底座内部代号就叫 rea。这篇文章就把这段经历完整拆开从设计思路到核心代码再到我在实际业务里踩过的坑一次性讲清楚。如果你现在正被 Redux 的样板代码折磨或者因为 Zustand 版本更新导致团队心智负担加重又或者你只是好奇一个状态管理库的底层到底是怎么运作的这篇文章都能给你一个非常具体的参考。我会把 rea 的每一个关键设计决策写出来包括为什么用 Proxy、为什么要把事务批量更新做进去、selector 的返回值为什么要刻意保持“不稳定”。这些东西在大多数开源项目的文档里是看不到的但恰恰是真正影响业务开发体验的地方。1. 项目缘起为什么团队需要一个叫 rea 的状态模块1.1 多端同步的痛点事情要从 2023 年那波“中后台系统全面重构”说起。我们团队当时同时维护着三个业务系统一个面向运营的复杂配置后台一个面向客户的轻量查询页面还有一个内部的低代码平台预览模块。这三个系统技术栈有重叠但不完全一致有的用 React 16有的用 React 18还有一部分老代码是用 jQuery 写的。最头疼的问题出在跨系统状态同步上。举一个具体场景运营人员在一个系统的左侧树形菜单里选中了一个服务节点然后需要在右侧的面板里修改这个节点的配置保存成功后另外一个实时监控页面要立刻收到更新通知。这个链路涉及到四个模块的数据流向如果不用一个统一的状态层就只能通过事件总线硬抛。我第一次看到那套代码的时候全局挂了十几个自定义事件光搜 addEventListener 就能出来二十多处而且事件名靠字符串约定写错一个字母根本不会报错只有在运行到特定操作时才会诡异失效。当时的局面是传统写法的 context 嵌套太深业务数据一多Provider 嵌套快十层改一次数据结构要动半个组件树Redux 虽然思路清晰但团队大多数人写不习惯繁琐的 action 定义也不太愿意为每个小改动都去维护 reducerZustand 当时已经很好用了但我们有几个模块要从 jQuery 老代码里直接调用状态层Zustand 依赖 React 环境老模块引进来相当别扭。所以我给自己定了一个目标用不到一千行代码写一个不依赖任何框架的状态底座既能给 React 用也能给纯 JavaScript 模块用核心能力包括响应式缓存、批量更新、selector 订阅和事务回滚。这就是 rea 最初的原型。1.2 选型对比为什么不用现成的库来做有人可能会问Zustand 这么好用为什么还要自己写一个团队内部当时确实有这种声音。我把所有主流的轻量状态库都过了一遍结论是这样的Redux Toolkit 解决的是“大型应用的规范性”问题但它的模型是单向数据流加不可变更新这本身没问题问题是样板代码太多。一个简单的 userInfo 拉取要定义 slice、action、reducer、thunk四个文件来回跳写起来枯燥且容易出低级错误。Zustand 解决的是“React 组件内状态共享”的问题它的 create 方法用起来很爽但它有个隐藏约束外部直接调用 store.setState 没问题可如果你要在不依赖 React 的环境中监听状态变化就得等 React 环境先初始化或者手动去适配。这个约束在我们那个低代码预览模块里是致命的。Jotai 的思路是把状态原子化atom 即拿即用很灵活但它对 selector 依赖追踪的自动处理依赖 React 渲染机制在非组件场景下要额外搭一层 bridge成本不低。再往下看还有 valtio它其实已经很接近我的目标了proxy 响应式加自动订阅React 内外面都能用。但我没有直接选它原因有两个一是它当时的 API 还在频繁变动我们业务团队接受不了“这周学完下周可能改名”的节奏二是它没有内置批量事务机制多个状态同时改变时会在内部触发多次通知虽然可以通过劫持微任务合并但业务层想看实时时序会比较难。这么说可能有点凡尔赛但在当时的时间节点上一个内部造的轮子反而是最可控的选择。因为我能完全按照团队的代码习惯来定义 API并且能把文档、类型提示和调试工具一次性做到顺手。1.3 设计目标与边界我拿到这个任务后先没有急着写代码而是把设计目标列得非常明确防止后面边界失控。第一核心包零依赖不能引任何第三方库保证在老模块里能直接挂载。第二包体积控制在 5KB 以内gzip少于这个数字会被质疑多余这个数字这个轮子就没有存在价值。第三React 版本适配交给独立的 bridge 小包核心库不做 React 相关逻辑。第四必须支持 selector 粒度的订阅这是性能的底线不能每次状态一变就让所有订阅者全量刷新。第五要支持事务同一时刻内多次修改状态只对外触发一次通知。边界方面我明确砍掉了几件事不做持久化中间件这个交给业务自己实现不做时间旅行调试成本太高收益低不做跨 tab 同步当时没有这种场景。把这些明确下来之后开发速度反而很快因为每一块都有清晰的方向不会写着写着又冒出别的主意。2. 核心 API 设计最小但够用的状态模型2.1 状态定义与初始化rea 的使用方式在设计上刻意向直白靠拢。首先你要创建一个 store它接收一个包含默认值的对象然后返回一组操作句柄。我不喜欢搞 Fluent 链式调用也不喜欢把 store 和 actions 分开定义再合并这对中后台的业务场景来说太绕了。// store.js import { createStore } from rea; export const userStore createStore({ userInfo: null, permissions: [], loading: false, });createStore 的入参是一个普通对象内部会用 Proxy 把它包裹成响应式对象。你不用写任何 action 定义也不用声明 mutations拿到的 userStore 直接就能读能写。userStore.state.userInfo { name: 张三, id: 1001 }; userStore.state.permissions [dashboard, report];这里有个关键设计state 字段是唯一可变的入口而 store 对象本身是不可变的。这样做的好处是外部代码很难不小心把 store 引用本身覆盖掉。如果团队规范要求“只允许通过 action 修改状态”你可以额外封装一层 action 函数但底层依然直接操作 state。2.2 Action 与异步更新虽然 rea 支持直接改 state但实际业务里我们还是建议把复杂逻辑封装成 action 函数。为什么因为直接改 state 在简单场景下很爽可一旦一个状态变更牵扯到多个字段的联动比如“登录成功后要同时写入 userInfo、permissions 和 token”如果这些逻辑散落在不同的组件事件里将来排查问题会非常痛苦。rea 提供 createAction 方法用于包装异步逻辑。它的内部其实没有做太神奇的事情只是把函数包了一层然后在调用前后分别记录事务开始与结束确保状态在一次事务里集中提交。import { createAction } from rea; const login createAction(async (payload) { userStore.state.loading true; try { const res await request(/api/login, payload); userStore.state.userInfo res.data.userInfo; userStore.state.permissions res.data.permissions; } finally { userStore.state.loading false; } });你看这里面没有 dispatch没有 type 常量也没有 middleware。函数本身就是 action状态就是普通对象这就是 rea 在代码组织上追求的“接近写普通函数”的体验。异步函数创建完后直接调用 login({ name, password }) 即可。2.3 Selector 与派生状态Selector 的作用是从整个状态树里提取出你关心的那一小部分并且返回一个计算结果。为什么需要 selector因为它能让订阅粒度足够小。比如一个列表页面有搜索条件、筛选结果、分页信息、当前选中的行等等如果组件只关心“当前选中的行”就不该因为“搜索条件变了”而重新渲染。rea 的 selector 接受一个函数该函数接收响应式状态作为参数返回任意计算后的值import { useReaSelector } from rea-react; const selectedRow useReaSelector((state) state.selectedRow); const filteredList useReaSelector((state) { return state.list.filter(item item.name.includes(state.keyword)); });这里有个细节很容易被忽略如果你在 selector 里返回了新对象比如 filter 之后的数组那么每次 subscribe 都会算出一个新引用。React 的 useSyncExternalStore 比较的是返回值快照如果引用每次都变就会导致无限重渲染。官方文档会说“你应该在 selector 里做基本类型比较”但实际业务哪来那么多基本类型所以我做了一个内部优化如果 selector 结果是一个新建的对象或数组reactive 缓存会把它自动序列化为稳定引用方式是比较序列化后的字符串是否变化若内容没变则复用上一次的对象引用。但光靠自动序列化不能解决所有场景因为有些时候返回的计算结果很大序列化成本比渲染成本还高。所以我在 API 里又加了一个参数允许业务手动标记某个 selector 是不需要自动稳定的const total useReaSelector((state) state.list.reduce((acc, cur) acc cur.count, 0), { unstable: true, });unstable 模式适用于基本类型返回值比如 number、string、boolean这些值本身就具备“值相等即引用相等”的特性直接比较快不耗序列化开销。2.4 订阅与清理组件以外的模块比如老 jQuery 页面或者独立的工具函数也需要能监听到状态变化。rea 单独提供 subscribe 接口const unsubscribe userStore.subscribe((newState, oldState) { console.log(userInfo 变化了, newState.userInfo); }); // 页面销毁时 unsubscribe();subscribe 回调会接收新状态和旧状态。注意这里不是传 Proxy 代理对象而是经过快照之后的普通对象。为什么因为如果你把 Proxy 直接交给业务业务极有可能会偷偷修改这个对象导致状态源被绕过后续订阅全部失效。快照拷贝虽然有一点内存开销但可以保证外部拿到的永远是不可变数据。3. 实操手写一个 rea 最小可运行版本3.1 目录结构与代码骨架我最终把代码分成了三个文件reactivity.js 负责响应式核心store.js 负责 store 实例管理bridge.js 负责接入 React。你可以直接在项目里照这个结构建目录。rea/ ├── package.json ├── reactivity.js // 核心响应式逻辑 ├── store.js // createStore 实现 ├── bridge.js // React 适配层react hook 封装 └── index.js // 统一导出reactivity.js 是整个项目的核心大约 200 行。store.js 补齐订阅通知逻辑约 100 行。bridge.js 用 React 18 的 useSyncExternalStore只需要几十行。下面我逐个文件展开讲。3.2 依赖收集与 Proxy 响应式proxy 是 JavaScript 标准库提供的陷阱机制它可以拦截对象的读取、赋值、删除等操作。rea 的响应式核心原理就是在读取响应式对象的属性时记录当前活跃的订阅者在修改属性时通知该属性对应的订阅者。这里最关键的类是依赖收集器。简单说每个属性下面挂一个 Set里面放的是依赖它的订阅者。当一个组件通过 selector 读取了 userStore.state.userInfo.name那么组件就被记录在 userInfo 对象的依赖集合里如果后面 userInfo.name 被变更组件就收到更新通知。真实实现里Proxy 的 get 拦截会根据 key 返回原始属性并在返回前记录依赖set 拦截则在校验值变化后向所有依赖该 key 的订阅者触发通知。看一下简化代码// reactivity.js const targetsMap new WeakMap(); let activeEffect null; export function track(target, key) { if (activeEffect) { let depsMap targetsMap.get(target); if (!depsMap) { depsMap new Map(); targetsMap.set(target, depsMap); } let dep depsMap.get(key); if (!dep) { dep new Set(); depsMap.set(key, dep); } dep.add(activeEffect); } } export function trigger(target, key) { const depsMap targetsMap.get(target); if (!depsMap) return; const dep depsMap.get(key); if (dep) { dep.forEach((effect) { if (effect._stableHash) { // 处理 selector 的稳定引用逻辑 } effect(); }); } } export function createReactiveState(initialObject) { const raw initialObject; const proxy new Proxy(raw, { get(target, key, receiver) { track(target, key); const value Reflect.get(target, key, receiver); // 如果是嵌套对象还要递归代理保证深层属性也能被追踪 if (value typeof value object) { return wrapReactive(value); } return value; }, set(target, key, value, receiver) { const oldValue target[key]; const hasChanged !Object.is(oldValue, value); Reflect.set(target, key, value, receiver); if (hasChanged) { // 让依赖该 key 以及可能依赖父级 key 的订阅者都收到更新 trigger(target, key, value, oldValue); } return true; }, }); return { proxy, raw }; }其实这块代码我做过三次重构最初版本用了数组依赖后来发现用 Map 和 Set 更直观。陷入误区的点在于嵌套对象的代理初始化。我的做法是“读取时递归代理”也就是懒代理——只有当 property 被访问时才对内部对象再包一层 Proxy。这样做避免了初始化大对象时全部递归一遍造成的性能卡顿。3.3 事务批量更新事务是 rea 差异化的一个点。初始想法很简单如果同一轮微任务里用户改了 userStore 的 3 个字段然后连续触发了 3 次订阅消费那效率很差。更麻烦的是中间状态的推送可能导致组件渲染一半就中断如果渲染过程中依赖了尚未更新的另一个字段还会出现 UI 闪烁。rea 的解法是把修改动作包在一个微任务队列里。set 操作发生时不立即执行 subscriber而是把 subscriber 放入一个全局的待处理队列然后用 queueMicrotask 注册一个批量处理任务。在同一轮微任务内即使修改了 100 个字段也只会在下一个微任务回调里统一执行一次通知。// store.js let batchQueue new Set(); let isFlushing false; function enqueueBatch(fn) { batchQueue.add(fn); if (!isFlushing) { isFlushing true; queueMicrotask(() { const queue Array.from(batchQueue); batchQueue new Set(); isFlushing false; queue.forEach((sub) { try { sub(); } catch (err) { console.error(rea subscriber error:, err); } }); }); } }注意一个细节批量队列中的 sub 执行顺序我刻意保持了订阅的注册顺序。这样在同一个状态变更里先订阅的先执行后订阅的后执行业务上某些依赖时序的逻辑不容易出错。这个顺序调用在 React 里没有影响因为 useSyncExternalStore 只关心快照对比但在纯 JS 模块里会显得非常重要。3.4 集成到 React 的 HooksReact 适配层最核心的封装是 useReaSelector。它的原理其实非常简单通过 Rea 的 subscribe 订阅 store 更新然后每次更新后重新计算 selector 值再将值与上一次快照比较返回不一致时才触发 render。用 React 18 的 useSyncExternalStore 实现起来很简洁它接受三个参数subscribe 函数、getSnapshot 函数、以及服务端渲染时的 getServerSnapshot 函数。// bridge.js import { useSyncExternalStore } from react; export function useReaSelector(store, selector) { const getSnapshot () { const computed selector(store.state); return stabilize(computed); }; return useSyncExternalStore( (onStoreChange) store.subscribe(onStoreChange), getSnapshot, getSnapshot ); }使用的时候const userName useReaSelector(userStore, (state) state.userInfo?.name);这里要注意useSyncExternalStore 的 getSnapshot 返回值在两次调用之间必须是稳定引用否则 React 会判定为状态变化导致无限循环。所以 stabilize 函数实际上就做了一件事对返回的引用进行缓存比较如果后续计算出来的内容与缓存相等就返回缓存的那个引用。这也是 rea 针对 selector 返回新引用问题做的关键修复。4. 性能优化与渲染追踪4.1 避免全量渲染Selector 粒度很多团队在迁移到 rea 之前最担心的一件事情就是“它不会导致我每次都把整个页面重渲染一遍吧” 这一点确实要分情况。如果组件的 selector 读的是具体字段比如 state.selectedRowId那么 selectedRowId 不变组件就不会重渲染。这是 rea 默认的能力也是使用状态库最基本的收益。但如果你让 selector 返回整个 state那个组件自然会在任意状态改变时重新渲染。看起来这是废话但在实际代码评审里我经常见到有人为了方便直接从 store 里拉整个对象。这并不是 rea 的问题而是用的人没有理解“最小订阅”的含义。我在给团队做分享时反复举同一个例子一个表格组件只需要行数就不该订阅整个列表数组。性能优化的第二条准则是拆分 store。一个大型 admin 系统不要只建一个全局 store而是根据业务域拆開几个互相独立的 store。比如用户信息一个、权限一个、当前工作流一个。这样做的好处是不同业务域的状态变更不会互相干扰selector 订阅的局部性天然就强。4.2 不可变更新的约定虽然 rea 底层是基于 Proxy 的可变响应式但在业务层我强推“替换式更新”而非“深度修改”。也就是说你更新一个对象字段时应该创建一个新的对象或使用展开运算符而不是直接修改嵌套对象内部的值。为什么有这个约定因为 rea 的性能快照机制太依赖引用比较了。如果直接修改深层属性比如 state.userInfo.contact.email newexample.com理论上 Proxy 也能捕捉到并且触发通知但因为嵌套对象在被访问时才有 Proxy 包裹依赖关系追踪可能不够精确容易导致订阅链条过长。写成这样是最理想的userStore.state.userInfo { ...userStore.state.userInfo, contact: { ...userStore.state.userInfo.contact, email: newexample.com }, };每次更新都替换根级引用这样依赖 userInfo 的 selector 能快速“感知”变化而不需要递归比较每一层属性。这是可维护性和性能的平衡点。4.3 效果管理与清理前端状态库的第二个经典问题就是异步操作的竞态。用户连续点击某个按钮触发两个异步请求后发的先返回先发的后返回界面最终显示的是旧数据。rea 提供了一个简单但好用的 effect 清理机制const asyncFetch createAction(async (params, context) { const controller new AbortController(); context.onCancel(() controller.abort()); const res await request(/api/list, { signal: controller.signal }); // 更新状态... });context.onCancel 注册的取消回调会在下一次调用同一个 action 时自动执行。也就是说用户再次点击按钮后上一次未完成的请求会被主动 abort避免覆盖新结果。这个机制内部实现不复杂就是在一个计数器上挂回调每次 createAction 包装函数被调用时先执行上一次注册的 onCancel 队列。类似的清理逻辑也可以放在组件内部配合 useEffect 清理订阅和定时器。5. 常见问题与排查实录5.1 问题速查表我在 rea 上线后这几个月里收到了不少反馈下面整理一个速查表这些问题你几乎都会遇到。现象常见原因排查方向解决方案修改 state 后页面不刷新selector 返回了每次都会变化的新引用检查 selector 是否有 filter/map 操作开启自动稳定或返回基本类型组件无限重渲染getSnapshot 返回了不稳定的新对象检查 stabilize 逻辑是否命中确保 selector 返回值经 stabilize 命中缓存异步 action 返回后状态丢失事务被取消或上一个 action 未完成检查 createAction 的 onCancel 逻辑在 action 内部处理返回值避免依赖全局老 jQuery 页面状态不生效没有正确调用 subscribe 或者订阅太晚检查绑定事件时机在页面初始化时即订阅 display 方法浏览器内存缓慢上升组件的订阅没有及时清理检查 useEffect 返回的取消函数在组件卸载时调用 unsubscribe这里最容易被忽略的是第一项selector 输出引用不稳定。很多同事第一次上手很容易写出return state.list.filter(...)这种代码运行效果表面看是正常的但会在页面某次更新时触发无限循环。我在文档里把这个写成了“re 的第一戒律”要求所有人过 code review 前必须自查。5.2 内存泄漏场景与排查方式内存泄漏是响应式库最常见的隐藏问题rea 也不例外。最常见的泄漏点不是订阅忘了取消而是 selector 里意外把外部对象拼进了返回值。比如有人在 selector 里读window.innerWidth或引用一个页面组件的本地变量这些外部对象被缓存进 stabilize 里会导致 selector 无法被 GC 回收。另一种泄漏模式是在 store 的 state 上挂了一个组件引用userStore.state.modalInstance modalRef.current;这基本就是自杀式写法。他让 state 直接引用了 React 组件的实例只要 store 不被销毁组件就永远留在内存里。解决方案是永远不要把组件实例、DOM 节点或者事件函数放进 state如果必须存存个 id 而不是引用。排查手段上我习惯用 Chrome DevTools 的 Memory 面板抓 Heap Snapshot。主动触发一个页面的打开关闭十几次然后比较快照里 rea 相关模块的数量。如果 subscribe 回调数量一直在涨可以怀疑某些组件的卸载函数没有真正执行到。也可以在 rea 内部加一个 dev 环境下的订阅日志每 30 秒打印一次当前 store 的订阅数量前后对比定位异常增长。5.3 调试技巧与版本兼容经验状态库的调试效率直接决定业务开发体验。这一点 rea 在接入 React DevTools 时做了一个小功能把 store 树反射到 window 对象上在浏览器控制台里可以直接输入window.store.userInfo或者修改window.store.state.userInfo {...}来模拟状态变化省去了打断点、看网络请求的麻烦。if (import.meta.env.DEV) { window.__reaStores window.__reaStores || {}; window.__reaStores.userStore userStore; }另一个技巧是利用 Proxy 的 set 陷阱在开发环境下打印状态变化的 trace。我在 set 处理函数里增加了一段代码只有当 key 是用户自定义属性时输出变更详情包括变化前的值、变化后的值以及触发变更的调用栈。if (import.meta.env.DEV) { console.groupCollapsed([rea] ${key} 变更); console.log(old:, oldValue); console.log(new:, value); console.trace(调用栈); console.groupEnd(); }版本兼容上rea 需要支持 React 16.8 到 React 18 的多个老项目。useSyncExternalStore 是 React 18 的 API在老版本里没有。所以我写了一个桥接检测如果 React 版本低于 18就退回到 useReducer useEffect 实现一个简易版本行为基本一致但并发特性会缺失。这个代码不复杂但是业务跑起来后稳定性要比“直接升级 React 版本”强得多。6. 从封装到复用rea 在业务中的落地扩展6.1 基于 rea 做模块级状态设计rea 成型之后团队里新老项目接入的过程其实比我想象中顺利很多。核心原因就是 API 足够简单。一个模块的接入大概只需要三步创建 store、定义若干 action、在组件里用 selector 取数。这里要强调“模块级”而不是“全局级”的设计思路。中后台系统最忌讳一个巨型 store 包揽所有数据。我的习惯用法是给每个业务页面或业务域建一个专属 store例如useOrderStore、useUserStore、useDashboardStore。它们之间如果确实需要通信可以在 action 里互相调用或者通过一个轻量的事件钩子。一个比较典型的例子是订单详情页。用户进入页面时需要同时加载订单基础信息、商品列表、操作日志和审批记录这些接口可以并行请求。如果不用状态层就得在页面组件里声明四个 useState然后处理四个 loading还要担心组件卸载后的竞态。用 rea 之后我把它们收敛到一个 orderStore 里四个状态字段统一管理const orderStore createStore({ base: null, items: [], logs: [], approvals: [], loadingMap: { base: false, items: false, logs: false, approvals: false }, }); const loadOrderDetail createAction(async (orderId) { orderStore.state.loadingMap { ...orderStore.state.loadingMap, base: true }; const base await api.getOrderBase(orderId); orderStore.state.base base; orderStore.state.loadingMap { ...orderStore.state.loadingMap, base: false }; });这样组件里同时用四个 selector 分别读取任何一个字段单独变化都不会让其他子组件重渲染性能上确实比原来 useState 外加 Props 层层传递好得多。6.2 与旧代码的渐进式集成业内都说老项目改状态管理层是“重构高危区”因为老代码往往没有测试改完跑不动都不知道该怪谁。rea 的渐进式集成策略是先让一个独立模块切换到 rea比如日志面板或最近访问列表这个模块本身是自包含的不依赖其他页面的状态。切换完成后先跑一个迭代回归确认无误再逐步扩大到更多模块。还有一个比较省事的做法是把 createStore 的入参设计成函数允许从旧模块的全局变量初始化 stateconst legacyStore createStore(() window.__legacyStatus || { lastUpdate: null, data: [], });这样老模块还继续用它的全局变量但新代码已经可以通过 legacyStore 统一读取和更新等旧代码彻底删除后再把初始值改成纯静态对象。这是“增量迁移”里非常实用的一招。6.3 后续可扩展的方向rea 当前版本已经稳定用了一个季度但你要说我完全满意那也不是。至少有两个方向我明确知道可以做得更好。第一个是 devtools 的增强。现在只能看到 store 树还不能做时间旅行也没有可视化的依赖关系图。如果后续有时间我想基于 Proxy 的 get 追踪把每个组件的依赖记录导出成一份 JSON 结构结合打包工具画一张“selector 依赖图”哪次一键点出哪些组件会更新一眼就能看清楚。这个对排查性能问题非常有用。第二个是跨 iframe 的场景。低代码平台里经常嵌入第三方页面如果两个 iframe 之间要共享同一个状态层可以在 rea 之上再包一层 BroadcastChannel 同步。消息体只传变更的 key 和 value而不是整个 state减少序列化开销。我给自己的底线是如果 rea 要继续进化必须保持 API 的稳定性不能为了新特性随意破坏现有语义。毕竟它现在已经是几个业务系统里不可替代的一部分任何接口改动都要慎重再慎重。回到开头那个“rea”三个字母其实并没有什么高深含义它一开始只是我在文件目录里随手敲下的几个字母。但后来真的把 package 发到团队内的时候有人开玩笑说 rea 就是 “real-time reactive architecture” 的缩写我听着觉得还挺贴切索性就在文档里用上了这个名字。如果你也面临类似的状态管理困境我真心建议你花一个下午照着这篇文章里写的最小实现亲手做一遍。写完之后你会发现外面那些看似神秘的状态库其实原理也就是这一百多行代码的事。
