# Redux 常見問題：代碼結構 ## 目錄 - [文件結構應該是什么樣？項目中該如何對 action 創建函數和 reducer 分組？ selector 又該放在哪里？](#structure-file-structure) - [如何將邏輯在 reducer 和 action 創建函數之間劃分？ “業務邏輯” 應該放在哪里？](#structure-business-logic) ## 代碼結構 <a id="structure-file-structure"></a> ### 文件結構應該是什么樣？項目中該如何對 action 創建函數和 reducer 分組？ selector 又該放在哪里？ 因為 Redux 只是數據存儲的庫，它沒有關于工程應該被如何組織的直接主張。然后，有一些被大多數 Redux 開發者所推薦的模式： - Rails-style：“actions”、“constants”、“reducers”、“containers” 以及 “components” 分屬不同的文件夾 - Domain-style：為每個功能或者域創建單獨的文件夾，可能會為某些文件類型創建子文件夾 - “Ducks”：類似于 Domain-style，但是明確地將 action、 reducer 綁定在一起，通常將它們定義在同一文件內。 推薦做法是將 selector 與 reducer 定義在一起并輸出，并在 reducer 文件中與知道 state 樹真實形狀的代碼一起被重用（例如在 `mapStateToProps` 方法、異步 action 創建函數，或者 saga）。 不管代碼在你的磁盤上是如何存放的，必須記住的是 action 和 reducer 不應該單獨考慮。在一個文件夾中定義的 reducer 可以響應另一個文件夾中定義的 action 是非常常見的（甚至是鼓勵的）。 #### 補充資料 **文檔** - [FAQ: Actions - "1:1 mapping between reducers and actions?"](/docs/faq/Actions.md#actions-reducer-mappings) **文章** - [How to Scale React Applications](https://www.smashingmagazine.com/2016/09/how-to-scale-react-applications/)(accompanying talk:[Scaling React Applications](https://vimeo.com/168648012)) - [Redux Best Practices](https://medium.com/lexical-labs-engineering/redux-best-practices-64d59775802e) - [Rules For Structuring (Redux) Applications ](http://jaysoo.ca/2016/02/28/organizing-redux-application/) - [A Better File Structure for React/Redux Applications](http://marmelab.com/blog/2015/12/17/react-directory-structure.html) - [Organizing Large React Applications](http://engineering.kapost.com/2016/01/organizing-large-react-applications/) - [Four Strategies for Organizing Code](https://medium.com/@msandin/strategies-for-organizing-code-2c9d690b6f33) - [Encapsulating the Redux State Tree](http://randycoulman.com/blog/2016/09/13/encapsulating-the-redux-state-tree/) - [Redux Reducer/Selector Asymmetry](http://randycoulman.com/blog/2016/09/20/redux-reducer-selector-asymmetry/) - [Modular Reducers and Selectors](http://randycoulman.com/blog/2016/09/27/modular-reducers-and-selectors/) - [My journey towards a maintainable project structure for React/Redux](https://medium.com/@mmazzarolo/my-journey-toward-a-maintainable-project-structure-for-react-redux-b05dfd999b5) - [React/Redux Links: Architecture - Project File Structure](https://github.com/markerikson/react-redux-links/blob/master/react-redux-architecture.md#project-file-structure) **討論** - [#839: Emphasize defining selectors alongside reducers](https://github.com/reactjs/redux/issues/839) - [#943: Reducer querying](https://github.com/reactjs/redux/issues/943) - [React Boilerplate #27: Application Structure](https://github.com/mxstbr/react-boilerplate/issues/27) - [Stack Overflow: How to structure Redux components/containers](http://stackoverflow.com/questions/32634320/how-to-structure-redux-components-containers/32921576) - [Twitter: There is no ultimate file structure for Redux](https://twitter.com/dan_abramov/status/783428282666614784) <a id="structure-business-logic"></a> ### 如何將邏輯在 reducer 和 action 創建函數之間劃分？ “業務邏輯” 應該放在哪里？ 關于邏輯的哪個部分應該放在 reducer 或者 action 創建函數中，沒有清晰的答案。一些開發者喜歡 “fat” action 創建函數，“thin” reducer 僅僅從 action 拿到數據并綁定到 state 樹。其他人的則強調 action 越簡單越好，盡量減少在 action 創建函數中使用 `getState()` 方法。 下面的評論恰如其分的概括了這兩種分歧： > 問題是什么在 action 創建函數中、什么在 reducer 中，就是關于 fat 和 thin action 創建函數的選擇。如果你將邏輯都放在 action 創建函數中，最終用于更新 state 的 action 對象就會變得 fat，相應的 reducer 就變得純凈、簡潔。因為只涉及很少的業務邏輯，將非常有利于組合。 > 如果你將大部分邏輯置于 reducer 之中，action 將變得精簡、美觀，大部分數據邏輯都在一個地方維護，但是 reducer 由于引用了其它分支的信息，將很難組合。最終的 reducer 會很龐大，而且需要從更高層的 state 獲取額外信息。 當你從這兩種極端情況中找到一個平衡時，就意味著你已經掌握了 Redux。 #### 補充資料 **文章** - [Where do I put my business logic in a React/Redux application?](https://medium.com/@jeffbski/where-do-i-put-my-business-logic-in-a-react-redux-application-9253ef91ce1) - [How to Scale React Applications](https://www.smashingmagazine.com/2016/09/how-to-scale-react-applications/) - [The Tao of Redux, Part 2 - Practice and Philosophy. Thick and thin reducers.](http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/#thick-and-thin-reducers) **討論** - [How putting too much logic in action creators could affect debugging](https://github.com/reactjs/redux/issues/384#issuecomment-127393209) - [#384: The more that's in a reducer, the more you can replay via time travel](https://github.com/reactjs/redux/issues/384#issuecomment-127393209) - [#1165: Where to put business logic / validation?](https://github.com/reactjs/redux/issues/1165) - [#1171: Recommendations for best practices regarding action-creators, reducers, and selectors](https://github.com/reactjs/redux/issues/1171) - [Stack Overflow: Accessing Redux state in an action creator?](http://stackoverflow.com/questions/35667249/accessing-redux-state-in-an-action-creator/35674575) <a id="structure-action-creators"></a> ### 為什么要使用 action 創建函數? Redux 并不需要 action 創建函數。 你可以自由地用對你最有利的方式創建 action。包括簡單地將一個對象字面量傳遞給 `dispatch` 。action 創建函數產生于 [Flux architecture](https://facebook.github.io/react/blog/2014/07/30/flux-actions-and-the-dispatcher.html#actions-and-actioncreators)， 后被 Redux 社區采用，因為它有很多的好處。 Action 創建函數更容易維護。對于 action 的更新可以在一個地方進行，并應用到任何地方。action 的所有實例都保證具有相同的形狀和相同的默認值。 Action 創建函數更容易測試。 內聯 action 的正確性必須手動驗證。與任何函數一樣，操作創建者的測試可以編寫一次并自動運行。 Action 創建函數更容易寫文檔注釋。 Action 創建函數會枚舉 action 的依賴。而且，集中化的 action 定義為文檔的注釋提供了便利。 如果 action 是內聯編寫的，則很難去捕捉和傳達這些信息。 Action 創建函數是一個更強大的抽象（abstraction）。 創建 action 通常涉及轉換數據和發出 Ajax 請求。 Action 創建函數為這種不同的邏輯提供了一個統一的接口。這種抽象可以使組件發起（dispatch）一個 action 的時候, 不被 action 創建者的細節弄得很復雜。 #### 更多資料 **文章** - [Idiomatic Redux: Why use action creators?](http://blog.isquaredsoftware.com/2016/10/idiomatic-redux-why-use-action-creators/) **討論** - [Reddit: Redbox - Redux action creation made simple](https://www.reddit.com/r/reactjs/comments/54k8js/redbox_redux_action_creation_made_simple/d8493z1/?context=4)