建立一個複雜一點的應用應該如何做：

• 模組化應用的要點
• 程式碼檔案的組織方式
• 狀態數的設計
• 開發輔助工具

一、模組化應用的要點
1.構建一個應用的基礎要做如下3件事情：

• 程式碼檔案的組織結構
• 確定模組的邊界
• store的狀態樹設計

2. 程式碼檔案的組織方式：
   按功能組織
   Redux應用適用於按功能組織劃分，即把完成同一應用功能的程式碼放在一個目錄下，一個應用功能包含多個角色的程式碼。在Redux中，不同的角色就是reducer、actions和檢視，而應用功能對應的就是使用者介面上的互動模組。
   拿Todo應用為例子，這個應用的兩個基本功能就是TodoList和Filter，所以程式碼就這樣組織，檔案目錄列表如下：
   

   
   每個基本功能對應的其實就是一個功能模組，每個功能模組對應一個目錄，每個目錄下包含同樣名字的角色檔案。
   • actionTypes.js定義action型別；
   • actions.js定義action建構函式，決定了這個功能模組可以接受的動作；
   • reducer.js定義這個功能模組如何響應actions.js中定義的動作；
   • views目錄，包含這個功能模組中所有的React元件，包括傻瓜元件和容器元件；
   • index.js這個檔案把所有的角色匯入，然後統一匯出
     在這種組織方式下，當你要修改某個功能模組的程式碼的時候，只要關注對應的目錄就行了，所有需要修改的程式碼檔案都能在這個目錄下找到。
3. 模組介面
   每個功能模組下都有一個index.js檔案，這個檔案就是我們的模組介面。
   舉例如下：
   import * as actions from './actions.js'
   import reducer from './reducer.js'
   import view from './views/container.js'
   export {actions,reducer,view}
   如果filter中的元件想要使用todoList中的功能，應該匯入todoList這個目錄。因為匯入這個目錄的時候，預設匯入的就是這個目錄下的index.js檔案，就是這個模組想要公開出來的介面。

4.狀態樹的設計
狀態樹的設計建議遵循以下幾個原則：

• 一個模組控制一個狀態節點
• 避免冗餘資料
• 樹形結構扁平

4.1 一個狀態節點只屬於一個模組
在Redux應用中，store上的每一個state都只能通過reducer來更改，而我們每個模組都有機會匯出一個自己的reducer，這個匯出的reducer只能最多更改Redux的狀態樹上一個節點下的資料，因為reducer之間對狀態樹上的修改權是互斥的，不能讓兩個reducer都可以修改同一個狀態樹上的節點。比如，如果A模組的reducer負責修改狀態樹a欄位下的資料，那麼另一個模組B的reducer就不可能有機會修改a欄位下的資料。這裡指的是‘修改權’，不是‘讀取權’（讀取權對任何模組都是開放的）。

4.2 避免冗餘資料
在Redux的Store中，一定要避免資料的冗餘，因為這可能會導致資料不一致的問題。

4.3 樹形結構扁平
在設計Redux Store的狀態樹時，要儘量保持樹形結構的扁平（樹形結構不要深）。

4.4 不使用ref

4.5 開發輔助工具