如何搭建数据中间层的笔记和思考
内容提要
本文探讨如何搭建数据中间层，以处理复杂业务数据。其意义在于共享视图数据、避免组件过度封装、兼容异步获取和聚合。难点包括统一同步异步、获取与订阅逻辑，以及数据组合。文章对比Promise、Generator和Reactive方案，指出Reactive更利于按需响应，但理解成本高；而Promise流程控制简单，适合复杂应用，最终建议根据异步复杂度选择redux-saga或redux-observable。
延伸解读
数据中间层的核心价值
数据中间层位于组件与视图渲染之间，主要解决视图层间的数据共享、避免组件过度封装、兼容多种数据来源（如服务端推送、异步获取、本地缓存）以及数据聚合问题。它通过统一数据访问和更新逻辑，降低业务复杂度，使组件更专注于视图表现。
同步与异步的统一处理
实际开发中，同一数据可能来自同步缓存或异步请求，且获取与订阅逻辑不同。Promise 通过将同步转为异步（如 Promise.resolve）统一处理，但只能响应一次；Reactive（如 Observable）则天然支持多次响应，能统一获取与订阅，直接描述“数据有变”的过程，减少区分获取与订阅的额外逻辑。
Reactive 的按需响应优势
使用 Promise 或主动更新状态时，数据变化可能引发不必要的更新，产生副作用。Reactive 从使用者角度出发，只对订阅的数据更新，未被订阅的数据不会触发复杂组合规则，从而避免无效计算，实现真正的按需获取，提升性能与可维护性。
方案选择的权衡
Promise、Generator 等关注流程控制，适合复杂异步流程，但可能增加代码复杂度（如 redux-thunk 的冗余）；Reactive 综合流程控制与消息通知，理念先进，但理解成本高、改动难度大。建议根据异步复杂度选择：若可控则用 redux-saga，若异步极复杂则用 redux-observable。
Q&A
数据中间层在React应用中的作用是什么？
数据中间层位于组件之上、视图渲染之下，用于理清复杂业务数据。它的意义包括：实现视图层之间的数据共享、避免组件的过度封装、兼容服务端推送、异步获取和本地缓存，以及进行数据聚合。
搭建数据中间层的主要难点有哪些？
主要难点包括：统一同步和异步数据的处理方式、统一获取与订阅的逻辑（因为数据可能来自缓存或异步获取，也可能被动推送更新），以及处理数据组合（多条数据实体在渲染前需要组合，且新数据源到来时需要重新组合）。
Promise和Reactive在处理同步和异步数据时有何不同？
Promise通过将同步数据包装成Promise.resolve来统一同步和异步，但只能响应一次；Reactive通过Observable.of或fromPromise统一，且subscribe可以响应多次。Reactive更适合处理数据更新（推送）的场景，而Promise编写更简单。
为什么说Reactive在按需获取方面优于Promise？
因为Reactive是从使用者的角度看问题，只对订阅的数据更新。如果数据实体a变了，但引用它的c没有被订阅，c就不会更新，避免了不必要的副作用。而Promise或主动更新状态的方式可能会更新不需要显示的数据，产生副作用。
redux-saga和redux-observable分别基于什么思想？如何选择？
redux-saga基于Generator，关注流程控制，适合异步流程可控、复杂度适中的场景；redux-observable基于Reactive（rxjs），关注刺激与响应，适合异步数据流非常多且复杂的场景。如果异步复杂度不高，用redux-saga；如果异步数据流实在太多太复杂，用redux-observable。
Reactive编程在实际使用中存在哪些问题？
主要问题有：代码理解成本高，一旦使用Reactive，不方便再融入其他思路的写法；改动难度大，因为Reactive不关心流程，链式操作在迭代中难以调整。
