资料内容：
Redux
Redux 是来自前端社区的一个数据管理框架，对 Native 开发同学来说可能会有
一点陌生，我们做一个简单的介绍。
Redux 是做什么的？
Redux 是一个用来做 [ 可预测 ][ 集中式 ][ 易调试 ][ 灵活性 ] 的数据管理的框架。
所有对数据的增删改查等操作都由 Redux 来集中负责。
Redux 是怎么设计和实现的？
Redux 是一个函数式的数据管理的框架。传统 OOP 做数据管理，往往是定
义一些 Bean，每一个 Bean 对外暴露一些 Public-API 用来操作内部数据（充
血模型）。
函数式的做法是更上一个抽象的纬度，对数据的定义是一些 Struct（贫血模型），
而操作数据的方法都统一到具有相同函数签名 (T, Action) => T 的 Reducer 中。
FP:Struct（贫血模型） + Reducer = OOP:Bean（充血模型）
同时 Redux 加上了 FP 中常用的 Middleware（AOP） 模式和 Subscribe 机制，
给框架带了极高的灵活性和扩展性。
Redux 的缺点
Redux 核心仅仅关心数据管理，不关心具体什么场景来使用它，这是它的优点
同时也是它的缺点。
在我们实际使用 Redux 中面临两个具体问题：
● Redux 的集中和 Component 的分治之间的矛盾；
● Redux 的 Reducer 需要一层层手动组装，带来的繁琐性和易错性。
Fish Redux 的改良
Fish Redux 通过 Redux 做集中化的可观察的数据管理。然不仅于此，对于传
统 Redux 在使用层面上的缺点，在面向端侧 flutter 页面纬度开发的场景中，我们通
过更好更高的抽象，做了改良。
一个组件需要定义一个数据（Struct）和一个 Reducer。同时组件之间存在着父
依赖子的关系。通过这层依赖关系， 我们解决了【集中】和【分治】之间的矛盾，同
时对 Reducer 的手动层层 Combine 变成由框架自动完成，大大简化了使用 Redux
的困难。 我们得到了理想的集中的效果和分治的代码。
对社区标准的 follow
State、Action、Reducer、Store、Middleware 以上概念和社区的 ReduxJS
是完全一致的。我们将原汁原味地保留所有的 Redux 的优势。
Component
组件是对局部的展示和功能的封装。 基于 Redux 的原则，我们对功能细分为修
改数据的功能 (Reducer) 和非修改数据的功能 ( 副作用 Effect)。
于是我们得到了，View、 Effect、Reducer 三部分，称之为组件的三要素，分
别负责了组件的展示、非修改数据的行为、修改数据的行为。
这是一种面向当下，也面向未来的拆分。在面向当下的 Redux 看来，是数据管
理和其他。在面向未来的 UI-Automation 看来是 UI 表达和其他。
UI 的表达对程序员而言即将进入黑盒时代，研发工程师们会把更多的精力放在
非修改数据的行为、修改数据的行为上。
组件是对视图的分治，也是对数据的分治。通过逐层分治，我们将复杂的页面和
数据切分为相互独立的小模块。这将利于团队内的协作开发。
