在 Android 中實現 Redux 的一點經驗

簡評：Redux是一個用於應用程序狀態管理的 開源JavaScript庫，其核心是經過可管理和控制的狀態來描述一個系統。這意味着其思想實際上是能夠應用於任何類型應用的開發的，包括移動應用。

Redux 架構基於一個嚴格的單向數據流，應用中的全部數據都是經過組件在一個方向上流動。Redux 但願確保應用的視圖是根據肯定的狀態來呈現的。意思就是，在任什麼時候間點，你應用的狀態老是肯定、有效的，而且能夠轉換到另外一個可預測和有效的狀態。而 UI 將根據所處的狀態來進行呈現。

關於 Redux 在網上已經有不少相關的資料，這裏就只介紹下 Redux 核心的三個組件：

1.Store：保存應用的狀態並提供一些幫助方法來存取狀態，分發狀態以及註冊監聽。

2.Actions：簡單說 Actions 就是事件，包含要傳遞給 store 的信息，代表咱們但願怎樣改變應用的狀態。好比，定義以下的一個 action:

data class AddTodoAction(val text: String)

由 store 來進行分發：

store.dispatch(AddTodoAction("Write blog post"))

3.Reducers：進行狀態的轉變。相似這樣：

fun reduce(oldState: AppState, action: Action) : AppState {
    return when (action) {
        is AddToDoAction -> {
            oldState.copy(todo = ...)
        }
        else -> oldState
    }
}

介紹完核心組件，下面來看一下它們是怎麼組合到一塊兒的：

Redux flow

Redux 的流程很簡單，你的應用根據當前狀態呈現 UI，用戶的交互觸發 action，並交給 reducer 來更新狀態。

最近，做者在一個還挺大的項目上試了下 Redux 架構，因此這裏就分享下從中總結的一些經驗。

1. 應用裏最好不要有多個 store
針對不一樣模塊有不一樣的 store 彷佛是個不錯的主意，但從上面的圖能夠看到每一個 store 和其數據流是一個閉環系統，這就使得不一樣 store 之間的狀態難以同步。這樣你就一般須要在一個狀態的變動響應中去進行另外一個 store 的 action 分發，而這很容易形成無限循環。

另外一個緣由是多 store 的架構是很是僵化的，難以靈活的改動。

更好的作法是維護一個包含多個子狀態的全局應用狀態，由一個 store 來表示：

data class AppState(val LoginState,
                    val HomeScreenState,
                    val GridState )

2. 保持應用的狀態層級儘量少
由於 Redux 中 state 是不可變的，所以深層次嵌套的 state 會產生不少的樣板代碼，而且難以更新。好比，考慮下面的一組數據模型：

data class State(val sections: List<Section>)

open class Section(val articles: List<Article>)
class Home(articles: List<Article>) : Section(articles)
class Discover(articles: List<Article>) : Section(articles)

class Article

實例化和更新狀態對象：

val state = State(sections = listOf(
                  Home(listOf(article1, article2)),
                  Discover(listOf(article1, article2))))

即便是用了 Kotlin 的 copy 機制，更新深層嵌套的屬性（好比上面的 Article）也是很是單調乏味的：

val newHome = Home(listOf(newArticle, state.sections[0].articles[1]))
state.copy(sections = listOf(newHome, state.sections[1]))

3. Reducers 只是純函數
Reduce 的做用只是處理 action 並返回新的 state 到 store 的，須要保證相同的輸入總會獲得同樣的輸出。Reduce 自身不該該有狀態和執行任何額外工做，而只是作狀態轉換。

class Reducer {
    fun reduce(state: State, action: Action) : State {
        ...
    }
}

若是你須要響應某個 action，並執行一些操做，那應該考慮使用 Middleware。

4. 只用 Kotlin
Redux 很大部分受到 Flux 的啓發，而關於 Flux 最多見的抱怨就是須要寫一大堆的樣板代碼。而所選擇的語言很大程度會決定你管理樣板代碼的便利性。

Kotlin 中相似 data class，when 語句之類的特性，能讓你的代碼清晰不少。例如，在 Reducer 中匹配 action 時，能夠選擇用 instanceof 方法實現。

if (action instanceof AddTodoAction) {
    return reduceAddTodoAction(oldState, action);
} else if (action instanceof RemoveTodoAction) {
    return reduceRemoveTodoAction(oldState, action);
} else if (...) {
    ...
}
return oldState;

當 action 不少時，這種寫法就很痛苦了。若是用 Kotlin 就是這樣的：

return when (action) {
    is AddTodoAction -> reduceAddTodoAction(oldState, action)
    is RemoveTodoAction -> reduceRemoveTodoAction(oldState, action)
    else -> oldState
}

結論
雖然，Redux 主要是被用於 Web 應用開發，但其思想咱們仍是能夠學習並引入到 Android 中。但 Redux 也不是「銀彈」，事實上也沒有什麼架構是，其在 Android 上的應用還很新，但咱們仍是很但願能看到它的逐漸成熟。

若是你對 Redux 在 Android 上運用有興趣，能夠看看 Redux 和 ReKotlin 這兩個庫。

原文：Lessons learned implementing Redux on Android - Pusher Blog