摘要：沿著管道有兩組偵聽器中間件和訂閱。中間件是可以偵聽傳入的動作的函數，支持諸如，或偵聽器之類的工具。將視為一個帶有更新前更新后鉤子的全局對象，以及能夠以簡單的方式合成新狀態。應將兩者視為一體，并且不再需要文件導出類型的字符串。

難道現在狀態管理不是一個可以解決的問題嗎?直觀地說，開發人員似乎知道一個隱藏的事實:狀態管理的使用似乎比需要的更困難。在本文中，我們將探討一些你可能一直在問自己的問題：

你是否需要一個用于狀態管理的庫？

Redux 的受歡迎程度是否值得我們去使用？ 為什么或者為什么不值得？

我們能否制定更好狀態管理解決方案嗎?如果能，要怎么做？

想閱讀更多優質文章請猛戳GitHub博客,一年百來篇優質文章等著你！

作為前端開發人員，不僅僅是布局，開發的真正藝術之一是知道如何管理存儲狀態。簡而言之:狀態管理是復雜的，但又并非那么復雜。

讓我們看看使用React等基于組件的視圖框架/庫時的選項：

存在于單個組件內部的狀態。在React中，通過setState方法更新state。

從父級傳遞給子級的狀態。在React中，將 props 作為屬性傳遞給子組件。

狀態保存在根 provider (提供者) 組件中，并由 consumer (消費者) 在組件樹的某個地方訪問，而不考慮組件之間的層級關系。在 React 中，通過 context API 可以實現。

大多數的狀態都是存在于視圖中的，因為它是用來反映用戶界面的。那么，對于反映底層數據和邏輯的其它狀態，又屬于誰呢？

將所有內容都放在視圖中可能會導致關注點的分離:它將與javascript視圖庫聯系在一起，使代碼更難測試，而且可能最大的麻煩是:必須不斷地思考和調整存儲狀態的位置。

狀態管理由于設計變更而變得復雜，而且通常很難判斷哪些組件需要哪些狀態。最直接的選擇是從根組件提供所有狀態，如果真要這么做的話，那么選用下一種方式會更好。

狀態可以移出視圖庫。然后，庫可以使用提供者/消費者模式連接以保持同步。

也許最流行的狀態管理庫是Redux。在過去的兩年里，它變得越來越受歡迎。那么為什么這么喜歡一個簡單的庫呢？

Redux 更具性能？答案是否定的。事實上，為了每一個必須處理的新動作(action)，都會稍微慢一些。

Redux是否更簡單？當然不是。

簡單應當是純javascript：比如 TJ Holowaychuk 在twitter上說

那么為什么不是每個人都使用 global.state={}？

在表層之下，Redux 與 TJ 的根對象{}完全相同——只是包裝在了一系列實用工具的管道(pipeline)中。

在 Redux 中，不能直接修改狀態。只有一種方法:派發（Dispatch）一個動作（Action）到管道中，管道會自動根據動作去更新狀態。

沿著管道有兩組偵聽器：中間件(middleware)和訂閱(subscriptions)。 中間件是可以偵聽傳入的動作的函數，支持諸如“logger”，“devtools”或“syncWithServer”偵聽器之類的工具。 訂閱是用于廣播這些狀態更改的函數。

最后，合成器（Reducer）函數負責把狀態變更拆分成更小、更模塊化、更容易管理的代碼塊。

和使用一個全局對象相比，Redux 確實簡化了開發過程。

將 Redux 視為一個帶有更新前/更新后鉤子的全局對象，以及能夠以簡單的方式合成新狀態。

是的。有幾個不可否認的跡象表明 API 需要改進，這些可以用下面的方程來總結

time_saved來表示你開發自己的解決方案所花費的時間，time_invested相當于閱讀文檔，學習教程和研究不熟悉的概念所花費的時間。

Redux 是一個擁有陡峭學習曲線的小型庫。雖然有不少開發者能夠克服深入學習函數式編程的困難并從 Redux 獲益良多，但是也有很多開發者望而卻步，寧愿重新使用 jQuery。

使用jQuery你不需要理解“monad”是什么，你也不需要為了使用Redux去理解函數組合。

使用 jQuery 你不需要理解“comonad”是什么，你也不需要為了使用 Redux 去理解函數組合。

任何框架或者庫的目的都應該是把復雜的事物抽象得更加簡單。

我認為Redux值得重寫，至少有以下 6 個方面可以改進得更友好。

讓我們來看看一個基本的 Redux 初始化過程，如下圖左邊所示：

許多開發人員在第一步后就在這里暫停，茫然地盯著深淵。 什么是 thunk？compose？一個函數能做到這些嗎？

如果 Redux 是基于配置而不是函數組合的話，那么像右邊那樣的初始化過程明顯看起來更加合理。

Redux 中的 reducers 可以通過一個轉換，讓我們遠離已經習慣但不必要且冗長的 switch 語句。

假設reducer與action類型匹配，那么我們可以對參數進行反轉，這樣每個reducer都是一個接受state 和action的純函數。 也許更簡單，我們可以標準化action并僅傳入state和有效負載(payload)。

thunk 通常用于在 Redux 中創建異步 action。 在許多方面，thunk 的工作方式看起來更像是一個聰明的黑客，而不是官方推薦的解決方案。 我們一步一步來看：

你派發一個action(dispatch an action)，它實際上是一個函數而不是預期的對象。

thunk 中間件檢查每個動作，看看它是否是一個函數。

如果是，中間件調用該函數，并傳入一些 store 的方法：dispatch 和 getState。

怎么會這樣？一個簡單的 action 到底是作為一個動態類型的對象、一個函數，還是一個 Promise？這難道不是一種拙劣的實踐嗎？

如上圖右邊所示，難道我們就不能只使用 async/await ？

仔細想想，其實有兩種 action

1.reducer action: 觸發 reducer 并改變狀態。

2.effect action：觸發異步 action，這可能會調用reducer操作，但異步函數不會直接更改任何狀態。

將這兩種類型的 action 區分開來，將比上面的thunk用法更有幫助，也更容易理解。

為什么我們的標準實踐要把 action creator 和 reducer 區分開來呢？能否只用其中一個呢？改變其中一個又是否會影響到另一個？

action creator 和 reducer 是同一枚硬幣的兩面。

const ACTION_ONE = "ACTION_ONE"是分離 action creators 和 reducers 的一個冗余產物。應將兩者視為一體，并且不再需要文件導出類型的字符串。

按照使用方式，把 Redux 中所涉及的概念進行合并分組，那么我們可以得出下面這個更簡單的模式。

可以從 reducer 中自動確定 action creator。 畢竟，在這種情況下，reducer 可以成為action creator。

使用一個基本的命名約定，下面是可預測的：

如果 reducer 命名為 increment，那么 type 就是 increment。更好的做法是加上命名空間 “count/increment”。

每個 action 都通過 payload 鍵來傳遞數據。

現在，從 count.increment 中，我們可以以一個 reducer 生成 action creator。

以上這些痛點就是我們創建 Rematch 的原因。

Rematch 對 Redux 進行了封裝，提供更簡單的 API，但又不失任何可配置性的特點

請參見下面的一個完整的 Rematch 示例：

在過去的幾個月里，我一直在實際業務中使用 Rematch。作為證明，我會說：狀態管理從未變得如此簡單、高效。

Redux 是一個出色的狀態管理工具，有鍵全的中間件生態與出色的開發工具。

Rematch 在 Redux 的基礎上構建并減少了樣板代碼和執行了一些最佳實踐。

說得清楚點，Rematch 移除了 Redux 所需要的這些東西：

聲明 action 類型

action 創建函數

thunks

store 配置

mapDispatchToProps

sagas

讓 Redux 與Rematch 作對比有助于讓理解更加清晰。

1.model

import { init } from "@rematch/core"

const count = {
  state: 0,
  reducers: {
    upBy: (state, payload) => state + payload
  }
}

init({
  model: { count }
})

2.View

import { connect } from "react-redux"

// Component

const mapStateToProps = (state) => ({
  count: state.count
})

const mapDispatchToProps = (dispatch) => ({
  countUpBy: dispatch.count.upBy
})

connect(mapStateToProps, mapDispatchToProps)(Component)

1.store

import { createStore, combineReducers } from "redux"
// devtools, reducers, middleware, etc.
export default createStore(reducers, initialState, enhancers)

2.Action Type

export const COUNT_UP_BY = "COUNT_UP_BY"

3.Action Creator

import { COUNT_UP_BY } from "../types/counter"

export const countUpBy = (value) => ({
  type: COUNT_UP_BY,
  payload: value,
})

4.Reducer

import { COUNT_UP_BY } from "../types/counter"

const initialState = 0

export default (state = initialState, action) => {
  switch (action.type) {
    case COUNT_UP_BY:
      return state + action.payload
    default: return state
  }
}

5.view

import { countUpBy } from "../actions/count"
import { connect } from "react-redux"

// Component

const mapStateToProps = (state) => ({
  count: state.count,
})

connect(mapStateToProps, { countUpBy })(Component)

Redux 并沒有被拋棄，而且也不應該被拋棄。

只是，我們應該以更低的學習成本，更少的樣板代碼和更少的認知成本，來擁抱 Redux 背后的簡單哲學。

你的點贊是我持續分享好東西的動力，歡迎點贊！