數據驅動模式藉助react的實踐探索

以前談到過不少次數據驅動的理解，此次經過實際項目檢驗了一下本身的想法。

相關文件

《前端數據驅動的價值》

《前端數據驅動的陷阱》

項目詳設

詳設的重要性

對於複雜一點的項目，作一個詳細設計很是重要。有人會疑惑，前端還須要詳設嗎？
根據個人經驗，詳設很是重要，很是體現能力。
對於一個新人，詳設可以給開發作一些提早準備。
對於一個老手，詳設能夠提早預見一些隱藏的坑。
對於一個高手，詳設須要達到隨便給一個有點經驗的人，都能直接寫代碼。

在某種程度上，開發者詳設在整個開發週期中佔得比重越大，能力就越強。
新人可能只佔5%，高手肯能佔到50%以上（架構徹底想清楚了，而後剩下用代碼去實踐設計）。

react詳設的步驟

1. 吃透業務，這個無論用什麼選型都很重要

2. 頂層數據結構，model必須梳理清晰，model須要可以完整的覆蓋業務

3. 業務React Component中每個的props，state佈局，props，state中每一項的用處，計算方式，與頂層數據結構的映射函數

4. 業務React Component中每個的Action對於的model改變

5. 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的處理能力，這種徹底的數據驅動性能問題很是大。

從上面看，代碼其實能夠分爲兩大部分：

1. render: 根據model寫渲染邏輯，這部分就交給react,你們仔細看看react的生命週期，都是圍繞render的

2. change model: 根據用戶的action，修改model的數據，這部分交給redux的模式

數據驅動副產物

單元測試

某種程度上，前端是很是難去寫單側的，由於涉及到dom，哪怕是時間容許，單側的使用度也不是很高。
對於數據驅動這種模式，至少從數據層，能夠規避dom，作一層數據變化的效驗（這個和寫服務端單側差很少）。而後有精力和時間，能夠加一層model-to-dom邏輯的測試。

用戶行爲回放

回答上面那個圖片，經過model能夠記錄一個頁面的快照，那麼若是對於單個用戶，單個終端，按照時間軸記錄一連串的model，咱們就能夠回放用戶的操做行爲。
以及利用大數據去批量分析用戶行爲數據。

數據驅動的思考

這種模式某種程度上，是爲了提升開發效率，減小頁面的複雜度（參考《前端數據驅動的價值》），減小開發的複雜度。

想一想5-6年前，仍是多頁面時代，每一個模塊都是一個頁面，數據都由後端去套模板。而後用戶每一個操做基本上都會觸發一些刷新。數據驅動和有點相似，只是借用react在單頁面上實現了。前端也承擔了更多的數據處理工做。

博客地址

http://tangguangyao.github.io/

微信公衆號