一、 數據模型

1.領域模型
領域模型是業務數據，往往要持久化到數據庫或localStorage中，屬于可跨模塊復用的公共數據
減少了代碼重復問題，減少網絡請求，跨模塊數據同步問題不復存在

2.應用狀態模型
視圖相關的狀態數據

二、視圖層組件
1.展示型組件
保持職責單一，僅做視圖呈現和最基本交互行為，通過props接收數據和回調函數輸出結果，
如果展示型組件粒度切分能很好的遵循高內聚低耦合和職責單一原則的話，可以沉淀出很多可復用的通用業務組件。

三、公共服務
所有的HTTP請求放在一起統一管理
日志服務、本地存儲服務、錯誤監控、Mock服務等統一存放在公共服務層；

四、跨模塊通信
為避免模塊間相互耦合、確保架構長期干凈可維護：
不在一個模塊內部直接調用其他模塊的Dispatch方法（寫操作、變更其他模塊的state）
不在一個模塊內部直接讀取其他模塊的state方法（讀操作）
建議將跨模塊通信的邏輯代碼放在父模塊中，或者在一個叫做Mediator層中單獨維護

五、數據流管理
Redux單向數據流，Redux架構的設計核心是單向數據流
1. Action
用戶操作行為：click drag input ...
服務端返回數據后續的行為

2. Reducer
每個Action都會對應一個數據處理函數，即Reducer。特別強調，Reducer必須是純函數（pure function），這個規定帶來一個非常大的好處，數據處理層代碼變的非常容易寫單元測試。
純函數的特征是入參相同的情況下，返回值恒等，舉個栗子?：
純函數：
function add(a, b) { return a + b; }
非純函數：
function now() { let now = new Date(); return now; }
函數中如果包含 Math.random，new Date(), 異步請求等內容，且影響到最終結果的返回，即為非純函數。

3. Store
Store 數據存放的地方，store保存從進入頁面開始所有Action操作生成的數據狀態（state），每次Action引發的數據變更都必須生成一個新的state對象，且確保舊的state對象不被修改。這樣做可以保證
應用的狀態的可預測、可追溯，也方便設計Redo/Undo功能。
使用輕量級的immutable方案immutability-helper，相比完全拷貝一份（deep clone）性能更優、存儲空間利用率更高。

總結：
嚴格遵循架構規范和單向數據流規范，可以保證我們的前端應用在比較粗的粒度上的可維護性和擴展性

?

轉載于:https://www.cnblogs.com/lyls/p/7606915.html

總結

以上是生活随笔為你收集整理的前端架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。