Component
组件是对局部的展示和功能的封装。 基于 Redux 的原则，我们对功能细分为修改数据的功能(Reducer)和非修改数据的功能(副作用 Effect)。
于是我们得到了，View、 Effect、Reducer 三部分，称之为组件的三要素，分别负责了组件的展示、非修改数据的行为、修改数据的行为。
这是一种面向当下，也面向未来的拆分。在面向当下的 Redux 看来，是数据管理和其他。在面向未来的 UI-Automation 看来是 UI 表达和其他。
UI 的表达对程序员而言即将进入黑盒时代，研发工程师们会把更多的精力放在非修改数据的行为、修改数据的行为上。
组件是对视图的分治，也是对数据的分治。通过逐层分治，我们将复杂的页面和数据切分为相互独立的小模块。这将利于团队内的协作开发。
关于 View
View 仅仅是一个函数签名: (T,Dispatch,ViewService) => Widget
它主要包含三方面的信息
视图是完全由数据驱动。
视图产生的事件／回调，通过 Dispatch 发出“意图”，不做具体的实现。
-
需要用到的组件依赖等，通过 ViewService 标准化调用。
比如一个典型的符合 View 签名的函数
关于 Effect
Effect 是对非修改数据行为的标准定义，它是一个函数签名: (Context, Action) => Object
它主要包含四方面的信息
接收来自 View 的“意图”，也包括对应的生命周期的回调，然后做出具体的执行。
它的处理可能是一个异步函数，数据可能在过程中被修改，所以我们不崇尚持有数据，而通过上下文来获取最新数据。
它不修改数据， 如果修要，应该发一个 Action 到 Reducer 里去处理。
-
它的返回值仅限于 bool or Future， 对应支持同步函数和协程的处理流程。
比如：良好的协程的支持
关于 Reducer
Reducer 是一个完全符合 Redux 规范的函数签名:(T,Action) => T
一些符合签名的 Reducer
同时我们以显式配置的方式来完成大组件所依赖的小组件、适配器的注册，这份依赖配置称之为 Dependencies。
所以有这样的公式 Component = View + Effect(可选) + Reducer(可选) + Dependencies(可选)。
Adapter
Adapter 也是对局部的展示和功能的封装。它为 ListView 高性能场景而生，它是 Component 实现上的一种变化。
Communication Mechanism
组件|适配器内通信
组件|适配器间内通信
