動機

隨著 JavaScript 單頁應用程式的需求日益複雜，我們的程式碼必須管理比以往更多的狀態。此狀態可以包含伺服器回應和快取資料，以及尚未儲存在伺服器上的本地建立資料。使用者介面狀態也越來越複雜，因為我們需要管理活動路由、選取的標籤、微調器、分頁控制項等。

管理這個不斷變化的狀態很困難。如果一個模型可以更新另一個模型，那麼一個檢視可以更新一個模型，這會更新另一個模型，而這反過來可能導致另一個檢視更新。在某個時間點，你不再了解應用程式中發生了什麼事，因為你失去了對狀態的何時、為何和如何的控制。當一個系統是不透明且非決定性的，就難以重現錯誤或新增新功能。

如果這還不夠糟，請考慮在前端產品開發中常見的新需求。作為開發人員，我們預計要處理樂觀更新、伺服器端渲染、在執行路由轉換之前擷取資料，等等。我們發現自己試圖管理以前從未處理過的複雜性，我們不可避免地會問這個問題：是時候放棄了嗎？答案是否。

這種複雜性很難處理，因為我們混合了兩個概念，這兩個概念對於人類的心智來說都很難推理：突變和非同步性。我稱它們為Mentos 和可樂。兩者在分離時都很棒，但在一起會造成混亂。像React這樣的函式庫嘗試透過移除非同步性和直接 DOM 操作來解決檢視層中的這個問題。然而，管理資料狀態則交由您負責。這就是 Redux 出現的地方。

遵循Flux、CQRS和事件溯源的步驟，Redux 嘗試透過對更新如何以及何時發生施加某些限制來使狀態突變可預測。這些限制反映在 Redux 的三個原則中。