爲什麼我們在Flux/Redux體系結構中分離動作和減速器？

Question

我使用助焊劑第一和終極版之後很長一段時間以來，我做喜歡他們，我看到他們的利益，但有一個問題一直在我腦海裏突然出現的是：

爲什麼我們脫鉤動作和縮減器，並在表示更改狀態（動作）的意圖的調用和更改狀態（reducer）的實際方式之間添加額外的間接指令，這樣更難以提供靜態或運行時保證和錯誤檢查？爲什麼不使用修改狀態的方法或函數？方法或函數將提供靜態保證（使用Typescript或Flow）和運行時保證（找不到方法/函數等），而未處理的操作根本不會引發任何錯誤（無論是靜態還是運行時）我們只能看到預期的行爲沒有發生。

讓我與我們的理論狀態集裝箱（TSC）好一點的例證是：

• 這是超級簡單
• 把它看作陣營組件的狀態界面（的setState，this.state），而不渲染部分。

所以，你唯一需要的是觸發您的組件的重新渲染時，我們TSC的狀態改變，並有可能改變這種狀態，這對我們來說將是修改狀態普通方法：fetchData，setError，setLoading等

我看到的是行動和減速是代碼的動態或靜態調度的解耦，所以不是叫myStateContainer.doSomethingAndUpdateState(...)你打電話actions.doSomethingAndUpdateState(...)，你讓整個通量/ redux機器將該動作連接到狀態的實際修改。這整件事情也帶來了thunk，sagas和其他中間件處理更復雜的動作的必要性，而不是僅僅使用常規的javascript控制流。

的主要問題是，這種脫鉤需要你寫了很多的東西，只是爲了實現這一脫鉤： - 動作類型 - - 行動有效載荷 - 的行動創造者的功能（參數） 接口的形狀你的狀態 - 您如何更新您的狀態

比較這對我們的理論狀態容器（TSC）： - 你的狀態 的形狀 - - 你的方法 界面如何更新您的狀態

那麼我在這裏想念什麼？這種解耦有什麼好處？

這非常類似於此的其他問題：Redux actions/reducers vs. directly setting state

讓我解釋爲什麼最投票回答這個問題不回答，要麼是我還是原來的問題： - 動作/減速讓你問的問題誰和如何？這可以通過我們的TSC完成，它只是一個實現細節，並且與動作/減速器本身無關。 - Actions/Reducers讓你回到你的狀態：這又是一個關於狀態容器的實現細節的問題，可以通過我們的TSC來實現。我們的TSC可以實現狀態改變命令，中間件和目前通過動作/縮減器實現的任何事情，這只是實現它的一個問題。

非常感謝！ Fran

Answer 1

其中一個主要原因是約束通過動作完成的狀態更改允許您將所有狀態更改視爲僅取決於操作和以前的狀態，從而簡化了對每個操作發生的事情的思考。這種架構將任何與「現實世界」的互動陷入行動創造者功能中。因此，狀態變化可以被視爲交易。

在您的理論狀態容器中，狀態變化可能在任何時候都發生不可預測的情況，並激活各種副作用，這會使他們更難以推理，並且更難找到錯誤。 Flux體系結構強制將狀態更改視爲離散事務流。

另一個原因是限制代碼中的數據流只發生在一個方向上。如果我們允許任意的無約束狀態修改，我們可能會得到狀態更改，導致更多的狀態更改，導致更多的狀態更改......這就是爲什麼它是在reducer中分派操作的反模式。我們想知道每個動作來自何處，而不是創建級聯動作。

Flux的創建是爲了解決Facebook上的一個問題：當某些接口代碼被觸發時，可能會導致彼此互相造成幾乎不可預知的副作用級聯。 Flux體系結構通過使每個狀態轉換爲單向的事務和數據流而使這變得不可能。

但是，如果爲了做到這一點而需要的樣板文件困擾您，您可能會很高興知道您的「理論狀態容器」或多或少地存在，雖然這比您的示例稍微複雜一些。它叫做MobX。

順便說一句，我認爲你對整個「這是一個實現細節」的東西過於樂觀。我認爲如果你試圖爲你的理論狀態容器實際實現時間旅行調試，你最終會與Redux非常相似。