什么是redux

redux 的概念来源于前端，是一个“可预测的状态容器”，采用“单向数据流”的思想，目的是为了让JS的状态管理变得更加可预期。

为什么使用redux

redux 存在的目的是为了解决组件之间的通信以及集中保存管理项目的状态。随着项目变得越来越大，组件之间的通信越来越复杂，状态越来越多，项目就变得难以维护。
使用redux管理状态，是将所有状态都保存在store中，各组件可以直接从store中获取到自己需要的状态。这样将全局状态保存到一处统一管理，使项目更加容易维护，组件之间的通信更加清晰。

不使用Redux和使用Redux时父子组件之间的通信方式

没有使用Redux的情况，如果两个组件(非父子关系)之间需要通信的话，可能需要多个中间组件为他们进行消息传递，这样既浪费了资源，代码也会比较复杂。
Redux中提出了单一数据源Store用来存储状态数据，所有的组件都可以通过Action修改Store，也可以从Store中获取最新状态，使用redux可以完美解决组件之间的通信问题。

4 张动图解释为什么（什么时候）使用 Redux

redux的核心概念及rekotlin的应用

redux的工作流程

rekotlin的工作流程

Store

Store可以看作一个状态容器，一个应用只能有一个Store。Store提供一些方法用于存取状态，分发状态及注册监听。以下是rekotlin中对于Store的接口定义中的几个常用方法

interface StoreType<State: StateType>: DispatchingStoreType {

    /**
     * 当前Store中存储的State
     */
    val state: State

    /**
     * 所有方便的 `dispatch` 方法使用的主要调度函数。
     * 这个调度功能可以通过提供中间件来扩展。
     * typealias DispatchFunction = (Action) -> Unit
     */
    var dispatchFunction: DispatchFunction

    /**
     * 将订阅者注册到Store，当Store中的State发生改变时，订阅者的`newState`方法将被调用
     */
    fun <S: StoreSubscriber<State>> subscribe(subscriber: S)

    /**
     * 解注册订阅者，State更新时订阅者将不再收到通知
     */
    fun <SelectedState> unsubscribe(subscriber: StoreSubscriber<SelectedState>)

    /**
     * 分发一个Action用于修改Store中的State
     *（这是DispatchingStoreType中定义的方法）
     */
    fun dispatch(action: Action)
    
    ···
}

State

State代表状态，是某个时刻表示一个View渲染所需所有数据状态的集合，实际上是一个状态树。
Redux 规定，一个 State 对应一个 View。只要 State 相同，View 就相同。你知道 State，就知道 View 是什么样，反之亦然。

interface StateType

data class ViewState(
    // 表示当前State对应的View中渲染所需内容
    val isVisible: Boolean = true,
    val titleText: String = "title",
    // 表示子View对应的State，形成一个状态树
    val statusLayerState: StatusLayerState? = null,
    val businessLayerState: BusinessLayerState? = null
) : StateType

kotlin中使用data class表示State，方便进行copy()操作

Action

State 的变化，会导致 View 的变化。但是，用户接触不到 State，只能接触到 View。所以，State 的变化必须是 View 导致的。Action 就是 View 发出的通知，表示 State 应该要发生变化了。

/**
 * 所有被分发的Action都需要实现这个接口
 */
interface Action

class ViewVisibleAction(val isVisible: Boolean) : Action

Reducer

Store 收到 Action 以后，必须给出一个新的 State，这样 View 才会发生变化。这种 State 的计算过程就叫做 Reducer。
Reducer 是一个纯函数，它接收 Action 和当前 State 作为参数，返回一个新的 State。

fun viewReducer(action: Action, viewState: ViewState?): ViewState {
      var newState = viewState ?: viewState()
      when(action) {
            is ViewVisibleAction -> {
                  newState = newState.copy(isVisible = action.isVisible)
            }
      }
      newState = newState.copy(statusLayerState = statusLayerReducer(action, viewState?.statusLayerState))
      newState = newState.copy(businessLayerState = businessLayerReducer(action, viewState?.businessLayerState))
      return newState
}

fun statusLayerReducer(action: Action, statusLayerState: StatusLayerState?): StatusLayerState {
      ···
}

fun businessLayerReducer(action: Action, businessLayerState: BusinessLayerState?): BusinessLayerState {
      ···
}

Reducer 函数最重要的特征是，它是一个纯函数。也就是说，只要是同样的输入，必定得到同样的输出。
由于 Reducer 是纯函数，就可以保证同样的State，必定得到同样的 View，任何时候，与某个 View 对应的 State 总是一个不变的对象。但也正因为这一点，Reducer 函数里面不能改变 State，必须返回一个全新的对象。因而State最好是只读的。

高阶用法 Middleware

Middleware中间件，在store.dispatch()分发Action到Reducer之间被调用，常用于添加、改造功能。

// typealias别名，仅做内联替换，不生成新的函数
typealias DispatchFunction = (Action) -> Unit
typealias Middleware<State> = (DispatchFunction, () -> State?) -> (DispatchFunction) -> DispatchFunction

class viewMiddleware(): Middleware<ViewState> {
    override fun invoke(
        p1: DispatchFunction,
        p2: () -> ViewState?
    ): (DispatchFunction) -> DispatchFunction {
        return fun(next: DispatchFunction): (Action) -> Unit {
            return fun(action: Action) {
                next(action)
            }
        }
    }
}

Store中dispatchFunction的实现

    override var dispatchFunction: DispatchFunction = middleware
            .reversed()
            .fold({ action: Action -> this._defaultDispatch(action) }, { dispatchFunction, middleware ->
                val dispatch = { action: Action -> this.dispatch(action) }
                val getState = { this._state }
                middleware(dispatch, getState)(dispatchFunction)
            })

redux的三大原则

Single source of truth 单一数据源
- The global state of your application is stored in an object tree within a single store. 应用的全局状态以树的形式存储在单一store中
State is read-only 状态只读
- The only way to change the state is to emit an action, an object describing what happened. 唯一改变state的方式是发送一个表示发生了什么的action
Changes are made with pure functions 变化由纯函数计算
- To specify how the state tree is transformed by actions, you write pure reducers. 编写纯函数去通过actions计算state发生了什么变化

redux使用场景

“如果你不知道是否需要 Redux，那就是不需要它。”

如果你的UI层非常简单，没有很多互动，redux 就是不必要的，用了反而增加复杂性。在应用程序增长到管理状态变得麻烦的规模的情况下，可以使用redux，使状态管理和溯源变得容易和简单。所以总体原则是能不用就不用, 实在干不动了再用。
某个组件的状态，需要共享。
某个状态需要在任何地方都可以拿到。
一个组件需要改变全局状态。
一个组件需要改变另一个组件的状态。

使用redux的优势

状态可预测：相同的State和Action传递给Reducer，输出的结果总是相同的（纯函数特性）。且当你需要修改状态时，必须重新开始走一个修改的流程，这种限制状态修改的方式，让状态变得可预测，容易调试。
可维护性：具有 Redux 知识的人更容易理解任何 Redux 应用程序的结构，且有助于用户将业务逻辑与组件树分离。
单向数据流：所有状态的改变可记录、可跟踪，源头易追溯，数据具有唯一出口和入口，使得数据操作更直观更容易理解。