資訊專欄INFORMATION COLUMN
摘要：之前談到過很多次數(shù)據(jù)驅動的理解，這次通過實際項目檢驗了一下自己的想法。對于數(shù)據(jù)驅動這種模式，至少從數(shù)據(jù)層，可以規(guī)避，做一層數(shù)據(jù)變化的效驗這個和寫服務端單側差不多。數(shù)據(jù)驅動和有點類似，只是借用在單頁面上實現(xiàn)了。
之前談到過很多次數(shù)據(jù)驅動的理解，這次通過實際項目檢驗了一下自己的想法。
相關文件《前端數(shù)據(jù)驅動的價值》
《前端數(shù)據(jù)驅動的陷阱》
項目詳設 詳設的重要性對于復雜一點的項目，做一個詳細設計非常重要。有人會疑惑，前端還需要詳設嗎？
根據(jù)我的經(jīng)驗，詳設非常重要，非常體現(xiàn)能力。
對于一個新人，詳設能夠給開發(fā)做一些提前準備。
對于一個老手，詳設可以提前預見一些隱藏的坑。
對于一個高手，詳設需要達到隨便給一個有點經(jīng)驗的人，都能直接寫代碼。
在某種程度上，開發(fā)者詳設在整個開發(fā)周期中占得比重越大，能力就越強。
新人可能只占5%，高手肯能占到50%以上（架構完全想清楚了，然后剩下用代碼去實踐設計）。
吃透業(yè)務，這個不管用什么選型都很重要
頂層數(shù)據(jù)結構，model必須梳理清晰，model需要能夠完整的覆蓋業(yè)務
業(yè)務React Component中每一個的props，state布局，props，state中每一項的用處，計算方式，與頂層數(shù)據(jù)結構的映射函數(shù)
業(yè)務React Component中每一個的Action對于的model改變
model上面添加和后端的關聯(lián)
基本上上面梳理清楚了，后面就可以直接寫代碼了。
道和術網(wǎng)上看到很多講解redux+react的實踐思路，設計模型。感覺都是實踐方式上面的講解。
比較經(jīng)典的一張圖：
今天我這邊想換一種思路去解釋他。
數(shù)據(jù)驅動+react實踐的一個前提相信react的性能！
相信react的性能！
相信react的性能！
model能力超級強大，請記住，每個model都必須能夠對應一種頁面狀態(tài)（能夠像恢復快照一樣）。model和頁面狀態(tài)存在一種一一對應的關系。
如下圖：
每一個M都和下面的頁面對應，用M1可以render出第一個頁面，M2可以render第二個頁面。
當用戶有交互行為時，通過action改變M1到M2，這時大家注意了
慢動作：
用戶對M1的頁面一做了一個操作（action）讓M1產(chǎn)生了改變M",這時M1變成了M2,對應的頁面也由頁面一刷新成了M2對應的頁面二。同理，M2通過交互變成了M3,頁面也會刷新成M3對應的頁面三。
注意我強調了刷新兩個字。
核心就是頁面的行為使得數(shù)據(jù)改變，數(shù)據(jù)渲染出數(shù)據(jù)改變后相應的頁面。
這個就是我所理解的數(shù)據(jù)驅動。
為了達到上面目的，其實我們有意忽略了性能問題。就是用戶每次操作都會重新渲染數(shù)據(jù)，生成對應的新頁面。
那么性能問題如何解決，這時react就出場了，性能上，我們需要借助react的虛擬dom，去比較每一次頁面修改的最小diff，然后重新渲染diff部分。所以我上面提到，你需要相信react的性能。
說實話，如果沒有這種最小diff的處理能力，這種完全的數(shù)據(jù)驅動性能問題非常大。
從上面看，代碼其實可以分為兩大部分：
render: 根據(jù)model寫渲染邏輯，這部分就交給react,大家仔細看看react的生命周期，都是圍繞render的
change model: 根據(jù)用戶的action，修改model的數(shù)據(jù)，這部分交給redux的模式
數(shù)據(jù)驅動副產(chǎn)物 單元測試某種程度上，前端是非常難去寫單側的，因為涉及到dom，哪怕是時間允許，單側的使用度也不是很高。
對于數(shù)據(jù)驅動這種模式，至少從數(shù)據(jù)層，可以規(guī)避dom，做一層數(shù)據(jù)變化的效驗（這個和寫服務端單側差不多）。然后有精力和時間，可以加一層model-to-dom邏輯的測試。
回答上面那個圖片，通過model可以記錄一個頁面的快照，那么如果對于單個用戶，單個終端，按照時間軸記錄一連串的model，我們就可以回放用戶的操作行為。
以及利用大數(shù)據(jù)去批量分析用戶行為數(shù)據(jù)。
這種模式某種程度上，是為了提高開發(fā)效率，減少頁面的復雜度（參考《前端數(shù)據(jù)驅動的價值》），減少開發(fā)的復雜度。
想想5-6年前，還是多頁面時代，每個模塊都是一個頁面，數(shù)據(jù)都由后端去套模板。然后用戶每個操作基本上都會觸發(fā)一些刷新。數(shù)據(jù)驅動和有點類似，只是借用react在單頁面上實現(xiàn)了。前端也承擔了更多的數(shù)據(jù)處理工作。
博客地址http://tangguangyao.github.io/
微信公眾號文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://systransis.cn/yun/79204.html
摘要：上例的功能塊定義了如下節(jié)點樹入口節(jié)點是面板，結合該節(jié)點的函數(shù)書寫特點，我們接著介紹最佳實踐如何處理功能塊之內(nèi)的編程。 本文介紹 React + Shadow Widget 應用于通用 GUI 開發(fā)的最佳實踐，只聚焦于典型場景下最優(yōu)開發(fā)方法。分上、下兩篇講解，上篇概述最佳實踐，介紹功能塊劃分。 showImg(https://segmentfault.com/img/bVWu3d?w=6...
摘要：是前端開發(fā)領域新興的方法論體系，它繼承了與編程理念，在技術上有不少創(chuàng)新。但專利與開源協(xié)議是平行的兩個世界，改底層也不大容易解決問題。此外，要求在中結合各屬性的是否變化，判斷是否該觸發(fā)更新。 ReRest (Reactive Resource State Transfer) 是前端開發(fā)領域新興的方法論體系，它繼承了 MVVM 與 FRP 編程理念，在技術上有不少創(chuàng)新。本文從專利稿修改而來...
摘要：目前，網(wǎng)易云輕舟微服務平臺已經(jīng)應用于銀行證券視頻監(jiān)控物流工業(yè)等行業(yè)不少中大型企業(yè)，幫助其實施微服務化改造，建設符合行業(yè)特點的業(yè)務中臺，支撐企業(yè)數(shù)字化戰(zhàn)略的落地。 微服務技術由于天生支持快速迭代、彈性擴展的特點，使企業(yè)能夠在不確定性下提升發(fā)展速度及抗風險能力，受到了越來越多的關注。當前，云服務商紛紛試水微服務產(chǎn)品，最為典型的，當屬推出輕舟微服務平臺、劍指整個微服務應用生命周期的網(wǎng)易云。 ...
摘要：因為路由層面受業(yè)務影響很大，經(jīng)常修改一些功能的行為，所以后來大部分測試都是針對層面的單元測試。在我了解的過程中，我發(fā)現(xiàn)中文網(wǎng)絡上對的討論非常分散，于是我創(chuàng)建了中文社區(qū)，到年末已經(jīng)有個注冊用戶和個帖子了。 https://jysperm.me/2016/02/programming-of-2015/ 從 2014 年末開始開發(fā)的一個互聯(lián)網(wǎng)金融項目終于在今年三月份上線了，這是一個 Node...
閱讀 1948·2021-11-22 14:44
閱讀 1682·2021-11-02 14:46
閱讀 3674·2021-10-13 09:40
閱讀 2609·2021-09-07 09:58
閱讀 1628·2021-09-03 10:28
閱讀 1669·2019-08-29 15:30
閱讀 987·2019-08-29 15:28
閱讀 1477·2019-08-26 12:20
