繼續聊聊MVVM和元件化

原文來自小寒的部落格，歡迎大家來踩踩

MVVM已經是更多前端的標配

上次說到MVVM，MVVM其實是MVC的變種，它讓把C分配給了V和VM，然後就出現了元件和store，這樣寫可以讓檢視更好的互動，讓資料更好的服務。而MVVM的創始人John Gossman也說了

實現MVVM的開銷對於簡單的UI操作是“過度的”。他說，對於更大的應用來說，推廣ViewModel變得更加困難。而且，他說明了非常大的應用程式中的資料繫結會導致相當大的記憶體消耗。

這句話很好理解，MVVM對於寫個部落格系統或者後臺管理系統來說是過度的，沒必要，還費記憶體。但對於前端分離的開發，和越來越高的使用者體驗要求以及電腦記憶體越來越大，這句話我個人覺得已經過時了。

作為一個有追求的前端開發，理所當然更加註重使用者體驗了，而且面向未來的看，很快2G記憶體的筆記本都比較罕見了，放開200M記憶體一個頁面也很難燒完。

react提供了自上而下的state和props來表達網站的狀態的功能，但在大多數網站裡邊，redux或者mobx通常回去充當VM。

mobx對後端很友好

對於深愛store的原因，有很多。

用了很久之後，我發現MVVM的一個超級大的好處，就是背鍋。

這個背鍋怎麼理解呢，就是在前後端分離的專案裡邊，面對規範並不嚴格或者或者js配合不算舒服的一些後端語言對接介面，store可以很輕鬆的抗下來，幾乎不會顯得難受。即便後端不會模組化，我們仍然可以用mobx實現一個完備的模組化資料集合，最後再用store去給元件提供最舒服的資料，那麼開發元件的時候就會很愉快了。

也就是說我們從store裡取資料，然後用store更新資料，把資料放在store裡就好了。

為什麼用store代替state，可以讀一下這篇文章 我用Store代替setState的三個原因 。

文章主要內容是這樣的

1. setState是非同步的

2. setState會造成沒必要的渲染

3. setState還會觸發一些無關緊要的life cycle。

其實使用mobx控制資料很爽，很統一一致，讓資料管理變得十分容易。相比之下更重要的是，

mobx對產品經理很友好

這句話怎麼理解呢，就是說全域性的狀態管理機制讓資料一直保持在外層，我們只是在變花樣的去呼叫它而已。那麼面對產品的需要，我們可以很容易的通過改變資料的呼叫方式而重構業務。

最後說了一下做為V的React。

用了react之後的第一件事就是告訴自己你應該習慣用一種新的方式表達你的網站了，這也是react比vue的學習曲線陡峭的原因，react希望使用者用一種全新的方式描述和表達網站，而vue的模板親和力更高一點。

網站的描述和表達是什麼意思呢，就是說寫網站就像在寫文章一樣，只是這次我們用的語言不是漢語，英語，而是javascript，沒有react之前我們寫網站也是在描述網站，但很low啊，我們在用html描述

而react是換了一種方式描述網站，用有狀態和生命週期的元件去描述網站，我覺得當理解這一層的時候，那麼就會找到新的做前端的感覺，水平也會有質的提升。就像我天天在吐槽後端一樣，你們不要管業務，你們的視野應該放在資料上，應該怎麼去更好的提供資料。前端也一樣，視野應該放在如何去管理資料，表達UI和互動，而不是如何完成業務。

粗曠的說元件只有兩種，業務元件和UI元件。

UI元件是和業務無關的元件，主要是幫助設計師解決的問題的。

業務元件是封裝產品功能，主要是幫助產品經理解決問題的。

UI元件庫必須要做，沒有UI元件庫React寫頁面的能力會掉百分之七八十，大多數前端雖然理解UI的能力不夠強，但還是去積極的做吧，這點可以從本質上提升你的React水平。

大多數人對元件的理解都只是UI層面的，在高階一點就是彈窗之類了，react一切都是元件，路由都是元件，元件並不是UI，元件可以是任何東西，理解了js一切都是物件，函式是一等公民，那麼這點也很容易理解了。react讓複雜多變的UI介面更容易表達。

不管是不是可以複用，都去拆分元件，按照資料和功能拆分元件

一個錯誤的示範

<Page>
 {this.renderSearch()}
 {this.renderFilter()}
 {this.renderList()}
</Page>複製程式碼

一個正確的示範

<Page>
  <Search/>
  <Filter/>
  <List/>
</Page>複製程式碼

但是可以有比較多的可選引數支援更多的配置

react-router v4的特點就是拋棄以前靜態路由的僵局，迎合react的本質一切都是元件。

減少componentWillMount componentWillUpdate的使用，props驅動state，這個是getDerivedStateFromProps的本質。

當可以做到以上的這些之後，你會發現開發變得越來越簡單，越來越流暢，然後囂張到變形，你會覺得產品的需求可能不夠複雜，設計圖太無聊了，後端給的資料還是挺不錯的。這個時候需要考慮的一個很關鍵的問題就是優化，當然優化還是早點考慮，但是對於強大的計算機計算來說，小小的優化可能並不會造成感官上的使用者體驗，但是保證良好的優化習慣，積少成多，遲早會有質的飛躍的。

如果可以react提供了shouldComponentUpdate來判斷是否應該渲染

很多場合計算並不需要放在render裡，會造成不必要的計算

越往底層的元件越需要成為PureComponent

React的精華所在，通過公用元件庫來提升整個專案的開發效率，但是這個前提是 良好的編碼習慣，高效能的編碼習慣以及長期堅持封裝元件和對使用者體驗的追求。

最後說到了視野，我覺得大多數人的視野並不開闊，是因為他只能看到眼前的利益。

舉幾個栗子：

1. 比方說去寫元件庫這個東西花費了本來完成業務所用時間的1.4倍，但是下次下下次他會縮短完成業務所用時間到本應該的0.5倍。事實上封裝熟練，去寫元件庫可能只會用到原來的1.1倍的時間，收益卻是提高了水平，簡化了業務，提升了效率。
2. 用store代替state可以讓產品業務越來越容易寫，雖然要管理和構建一個複雜的資料系統，只要開頭了，剩下的只是習慣而已。
3. 花1天的時間修一下webpack，可能會讓自己的開發更新時間快一倍以上。當然即使快0.2倍我也願意去花這一天的時間。
4. 規範也很重要，最佳實踐也很重要，這些對效率的提升更難表現出來。最佳實踐這個詞聽起來很決絕，憑什麼是最佳。對，我很喜歡那些不遵循最佳實踐的人，但是是那種可以很好理解所謂最佳實踐意義的人。
5. 關於拖延症，每個人都有，我現在就拖延睡覺到1點半了，但是面對寫程式碼，對自己對別人可以嚴格一點，可以認為這是作為程式設計師的工匠精神。

日漫裡的名言，所有悲劇的發生都是緣於當事人的能力不足。這句話看起來很粗鄙的在排除各種因素，歸結為人的因素，但仔細回味起來卻很深奧。

最後希望所有的讀者可以按照更好的實踐和規範去踐行所做的事，遇到問題及時更正，以免推到無法挽回的地步。

我用Store代替setState的三個原因

React 實戰：設計模式和最佳實踐