之前談到過很多次資料驅動的理解，這次通過實際專案檢驗了一下自己的想法。
相關檔案
專案詳設
詳設的重要性
對於複雜一點的專案，做一個詳細設計非常重要。有人會疑惑，前端還需要詳設嗎？
根據我的經驗，詳設非常重要，非常體現能力。
對於一個新人，詳設能夠給開發做一些提前準備。
對於一個老手，詳設可以提前預見一些隱藏的坑。
對於一個高手，詳設需要達到隨便給一個有點經驗的人，都能直接寫程式碼。
在某種程度上，開發者詳設在整個開發週期中佔得比重越大，能力就越強。
新人可能只佔5%，高手肯能佔到50%以上（架構完全想清楚了，然後剩下用程式碼去實踐設計）。
react詳設的步驟
- 吃透業務，這個不管用什麼選型都很重要
- 頂層資料結構，model必須梳理清晰，model需要能夠完整的覆蓋業務
- 業務React Component中每一個的props，state佈局，props，state中每一項的用處，計算方式，與頂層資料結構的對映函式
- 業務React Component中每一個的Action對於的model改變
- model上面新增和後端的關聯
基本上上面梳理清楚了，後面就可以直接寫程式碼了。
道和術
網上看到很多講解redux+react的實踐思路，設計模型。感覺都是實踐方式上面的講解。
比較經典的一張圖：
今天我這邊想換一種思路去解釋他。
資料驅動+react實踐的一個前提
相信react的效能！
相信react的效能！
相信react的效能！
快照概念
model能力超級強大，請記住，每個model都必須能夠對應一種頁面狀態（能夠像恢復快照一樣）。model和頁面狀態存在一種一一對應的關係。
如下圖：
每一個M都和下面的頁面對應，用M1可以render出第一個頁面，M2可以render第二個頁面。
當使用者有互動行為時，通過action改變M1到M2，這時大家注意了
慢動作：
使用者對M1的頁面一做了一個操作（action）讓M1產生了改變M',這時M1變成了M2,對應的頁面也由頁面一重新整理成了M2對應的頁面二。同理，M2通過互動變成了M3,頁面也會重新整理成M3對應的頁面三。
注意我強調了重新整理兩個字。
核心就是頁面的行為使得資料改變，資料渲染出資料改變後相應的頁面。
這個就是我所理解的資料驅動。
為了達到上面目的，其實我們有意忽略了效能問題。就是使用者每次操作都會重新渲染資料，生成對應的新頁面。
那麼效能問題如何解決，這時react就出場了，效能上，我們需要藉助react的虛擬dom，去比較每一次頁面修改的最小diff，然後重新渲染diff部分。所以我上面提到，你需要相信react的效能。
說實話，如果沒有這種最小diff的處理能力，這種完全的資料驅動效能問題非常大。
從上面看，程式碼其實可以分為兩大部分：
- render: 根據model寫渲染邏輯，這部分就交給react,大家仔細看看react的生命週期，都是圍繞render的
- change model: 根據使用者的action，修改model的資料，這部分交給redux的模式
資料驅動副產物
單元測試
某種程度上，前端是非常難去寫單側的，因為涉及到dom，哪怕是時間允許，單側的使用度也不是很高。
對於資料驅動這種模式，至少從資料層，可以規避dom，做一層資料變化的效驗（這個和寫服務端單側差不多）。然後有精力和時間，可以加一層model-to-dom邏輯的測試。
使用者行為回放
回答上面那個圖片，通過model可以記錄一個頁面的快照，那麼如果對於單個使用者，單個終端，按照時間軸記錄一連串的model，我們就可以回放使用者的操作行為。
以及利用大資料去批量分析使用者行為資料。
資料驅動的思考
這種模式某種程度上，是為了提高開發效率，減少頁面的複雜度（參考《前端資料驅動的價值》），減少開發的複雜度。
想想5-6年前，還是多頁面時代，每個模組都是一個頁面，資料都由後端去套模板。然後使用者每個操作基本上都會觸發一些重新整理。資料驅動和有點類似，只是借用react在單頁面上實現了。前端也承擔了更多的資料處理工作。
打賞支援我寫出更多好文章，謝謝！
打賞作者
打賞支援我寫出更多好文章，謝謝！
任選一種支付方式
