react-bits 单向数据流模式用订阅式 Store 让 React 组件回归纯粹展示【免费下载链接】react-bits✨ React patterns, techniques, tips and tricks ✨项目地址: https://gitcode.com/gh_mirrors/re/react-bits单向数据流是 React 应用数据管理的基石思想让数据只沿一个方向流动消除多个状态源带来的不可预测性。本文基于 react-bits 仓库中 patterns/7.one-way-data-flow.md 的核心思路从零实现一个支持订阅的最小 Store并将它接入 App 与 Switcher 两个组件最终让组件变成Store 数据的哑展示层。读完后你将掌握订阅-发布式 Store 的完整写法、forceUpdate的适用边界与高阶组件替代方案以及单向数据流与 Flux、Redux、容器组件模式之间的演进关系。一、为什么需要单向数据流在 React 应用中状态可以散落在各个组件内部每个组件自己维护this.state父子组件之间通过 props 回调传递数据兄弟组件之间则依赖提升状态或事件总线。当组件树变大这种多状态源并存的方式会出现两个典型问题状态来源不唯一同一个业务数据可能在多个组件中各存一份改了一处忘了另一处界面与数据出现分歧数据流向不透明数据在组件间绕来绕去难以追踪一个值从哪里来、被谁修改。单向数据流One-way data flow的思路是消除多个状态只保留一个权威状态这个状态通常存放在 Store 中。组件不再各自为政而是统一从 Store 读取数据、通过 Store 提供的方法修改数据。数据流向固定为用户交互 → 调用 Store.set() → 触发订阅回调 → 组件重新渲染这样整条链路只有一条数据高速公路调试和推理都变得简单。二、实现一个可订阅的最小 Store要让组件感知到数据变化Store 对象必须提供订阅变更的能力即典型的发布-订阅Pub/Sub模式。原文档给出的实现非常精简只有四个成员var Store { _handlers: [], _flag: , onChange: function (handler) { this._handlers.push(handler); }, set: function (value) { this._flag value; this._handlers.forEach(handler handler()) }, get: function () { return this._flag; } };逐个拆解这四个成员可以看出一个最小 Store 的全部要素成员类型职责_handlers数组存放所有订阅者回调函数是 Store 内部的私有属性_flag任意值当前唯一的数据源本例用字符串示意实际业务中可以是对象onChange(handler)方法订阅接口把回调推入_handlers之后每次数据变更都会调用它set(value)方法写接口更新_flag然后遍历_handlers逐个通知订阅者get()方法读接口返回当前_flag的值值得注意的细节set是唯一的写入口外部组件不能直接改_flag只能通过set写入这保证了改数据必发通知的强约束通知是同步广播set内部forEach逐个调用订阅者不涉及异步调度逻辑简单直白没有退订机制这是刻意简化的结果。真实场景中通常会给onChange返回一个退订函数或在组件卸载时清理避免内存泄漏。可以看到这个 Store 与仓库中 Flux 模式文档 里 Dispatcher 的register/dispatch思路一脉相承Flux 用 Dispatcher 统一分发 action 到各 store 的update方法这里的set承担了类似的变更广播职责只是收敛为单 Store、单数据源的极简形态。三、将 App 组件挂接到 Store有了 Store 之后接下来要让应用根组件App订阅 Store 的变更并在每次变更时重新渲染class App extends React.Component { constructor(props) { super(props); Store.onChange(this.forceUpdate.bind(this)); } render() { return ( div Switcher value{ Store.get() } onChange{ Store.set.bind(Store) }/ /div ); } }这段代码包含两个关键动作订阅在constructor里调用Store.onChange(...)把this.forceUpdate.bind(this)注册为变更回调。此后只要Store.set被调用App就会强制重新渲染读写分离地传递 propsvalue{ Store.get() }从 Store 读取当前值onChange{ Store.set.bind(Store) }把 Store 的写方法绑定好this作为回调下发给子组件。注意Store.set.bind(Store)这一步Store是普通对象字面量其方法里的this依赖调用方式。把set作为 props 传下去后调用方上下文不再是Store所以必须bind(Store)否则this._flag会指向错误的对象。这是一个非常容易踩坑的细节。关于 forceUpdate能用但不够优雅原文档特别提醒forceUpdate并不是 React 推荐的做法。forceUpdate会跳过shouldComponentUpdate的优化机会强制组件及其子树重新渲染破坏了 React 基于状态差异做渲染决策的正常机制。它在这里出现只是因为足够简单——不需要引入额外抽象三行代码就能演示订阅驱动的重渲染。原文档原话Normally a high-order component is used to enable the re-rendering. We used forceUpdate just to keep the example simple.正常情况下应该用高阶组件来触发重渲染这里用 forceUpdate 只是为了保持示例简单。那么正规做法是什么参见仓库中 Presentational vs Container 模式文档把数据逻辑封装进容器组件由其负责订阅 Store、持有 state并用 render 只输出纯展示组件。更典型的形态是高阶组件HOC——仓库中 Feature Flags 文档 展示了用connect把 Redux store 注入容器的完整范式return connect((store) { isEnabled: isFeatureEnabled(store, featureName) })(FeatureFlaggedContainer);这套思路与本文的 Store 订阅如出一辙connect本质上就是订阅 store 变化 → 触发容器重渲染 → 把新数据注入 props的通用化封装只是把forceUpdate换成了可控的订阅管理并附带了shouldComponentUpdate层面的优化。四、Switcher 组件彻底移除内部状态数据流理顺之后受益最明显的是子组件。原来的Switcher可能自带一个开关状态比如this.state.on而现在它完全不需要内部 state 了class Switcher extends React.Component { constructor(props) { super(props); this._onButtonClick e { this.props.onChange(!this.props.value); } } render() { return ( button onClick{ this._onButtonClick } { this.props.value ? lights on : lights off } /button ); } }分析一下这个组件的依赖读只通过this.props.value拿到当前开关状态不自己存副本写只通过this.props.onChange(!this.props.value)把希望切换的意图上报给父级由父级转交Store.set渲染纯由 props 决定同样的 props 永远渲染出同样的 UI。点击按钮的完整链路因此变得非常清晰点击 button → _onButtonClick → this.props.onChange(!value) → Store.set(新值) → 广播所有订阅者 → App.forceUpdate() → Store.get() 返回新值 → Switcher 拿到新 props → 重新渲染按钮文案这里有一个与 React 语义相关的注意点onChange回调经由 props 层层上传setState的调用最终发生在 Store 内部严格说是发生在Store.set里而不是某个组件里。而关于setState的异步批处理问题仓库中有两份独立文档专门讨论setState 的异步本质 说明了 React 事件处理器内setState会被批处理、而setTimeout/AJAX 等场景下会同步更新的行为差异向 setState 传入函数 则给出了依赖旧状态更新时的推荐写法。在 Store 场景下如果多个组件在短时间内连续set同样值得参考函数式更新的思路避免读到过期值。五、这个模式带来的核心收益原文档在结尾总结了单向数据流最本质的两个收益组件变成 Store 数据的哑展示组件不再关心数据从哪来、如何变化只负责把 props 渲染成 UI。这大大降低了单个组件的认知负担也让组件可以被随意复用——只要给它 props它就能工作用声明式方式写应用把复杂度集中到一处应用被写成数据是什么界面就是什么的声明式形态所有关于数据变更的逻辑何时变、变什么、变了通知谁都收敛在 Store 这一个地方而不是散落在每个组件的生命周期方法里。这一点与 Presentational vs Container 文档 的分层哲学完全一致展示组件只关心外观how things look容器组件负责数据与业务逻辑how things work。单向数据流正是让展示层得以彻底简化的前提——因为权威数据永远在 Store组件内部不再需要额外的状态副本。同时要看到这条模式的边界它是一个教学级的最小实现用于揭示单向数据流的核心机制。真实项目中通常不会手写这种 Store而是直接使用 Flux仓库中 Flux 模式文档 给出了带 Dispatcher、action、store 注册校验的完整实现或 Redux 等成熟方案它们把本文中的订阅广播、唯一数据源思想工业化了。但无论框架如何演进你看到的底层骨架始终是数据统一存储 → 变更通知订阅者 → 组件从 Store 拉取新值重渲染。六、小结从最小 Store 到工业级状态管理层级本文示例工业级方案数据存储Store._flagRedux 单一 store / reducer变更通知_handlersforEachsubscribe/connect触发渲染forceUpdate容器组件 HOC如connect写数据入口Store.setdispatch(action)组件形态无内部 state 的展示组件展示/容器分层本文基于 patterns/7.one-way-data-flow.md 展开我们实现了一个仅 10 余行的订阅式 Store用它驱动了App与Switcher两个组件的单向数据流动理解了forceUpdate的局限与高阶组件的演进方向。当你下次遇到状态散落各处、数据流向混乱的应用时不妨先回到这条最简单的链路一个 Store、一次广播、一层纯粹展示——复杂应用的状态管理往往就是从这条单向链路生长出来的。【免费下载链接】react-bits✨ React patterns, techniques, tips and tricks ✨项目地址: https://gitcode.com/gh_mirrors/re/react-bits创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考