初識Vue
今天終於學習了Vue框架,真的特別強大,強大的數據雙向綁定已經代碼修改後,不需要修改頁面,頁面就會被更新(重繪),Vue對數據的操作非常的強大,聲明式渲染、組件化思想、狀態管理都十分的出色、Vue不愧是三大框架中的佼佼者
Vue執行流程
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Hello,Vue</title>
</head>
<body>
<div id="app">
{{message}}
</div>
<script src="vue.js" type="text/javascript" charset="utf-8"></script>
<script type="text/javascript">
var app=new Vue({
el:'#app',
data:{
message:'Hello Vue'
}
});
</script>
</body>
</html>
1.瀏覽器從上到下依次進行解析
瀏覽器對於id= app的 div 內部的{{message}}是不認識的,直接作爲普通的文本輸入到瀏覽器頁面上。當瀏覽器繼續往後執行這段代碼的時候,發現有一個JS的腳本,發起請求進行下載,當頁面環境拿到JS腳本後 Vue.js就會執行,當執行結束的時候,就會全局暴露一個對象:Vue。當解析執行到我們自己寫的JS代碼的時候,就開始執行我們自己的代碼,並且創建Vue的實例(new Vue),通過el屬性指定要控制Vue程序的範圍,通過data想Vue的實例的應用程序初始化了message成員。然後Vue通過el屬性指定id 爲 app的 div,開始解析並執行Vue能夠識別的語法,{{message}}在Vue中被稱爲雙花括號插值表達式,在雙括號插值表達式中可以使用當前元素 所屬的vue程序,控制範圍中的data 數據。
Vue是漸進式框架
爲什麼說Vue是漸進式框架呢?Vue從設計的角度來講, 雖然能夠涵蓋這張圖上所有的東西，但是你並不需要一上手就把所有東西全用上 ，因爲沒有必要。無論從學習角度，還是實際情況，這都是可選的。聲明式渲染和組件系統是Vue的核心庫所包含內容，而客戶端路由、狀態管理、構建工具都有專門解決方案。這些解決方案相互獨立，你可以在覈心的基礎上任意選用其他的部件，不一定要全部整合在一起。
何爲聲明式渲染
現在基本所有的框架都已經認同這個看法——DOM應儘可能是一個函數式到狀態的映射。狀態即是唯一的真相，而DOM狀態只是數據狀態的一個映射。如下圖所示，所有的邏輯儘可能在狀態的層面去進行，當狀態改變的時候，View應該是在框架幫助下自動更新到合理的狀態，而不是說當你觀測到數據變化之後手動選擇一個元素，再命令式地去改動它的屬性。
Vue的編譯器在編譯模板之後，會把這些模板編譯成一個渲染函數 。
而函數被調用的時候就會渲染並且返回一個 **虛擬DOM的樹 **。
這個樹非常輕量，它的職責就是描述當前界面所應處的狀態。當我們 有了這個虛擬的樹之後，再交給一個patch函數，負責把這些虛擬DOM真正施加到真實的DOM上 。在這個過程中，Vue有自身的響應式系統來偵測在渲染過程中所依賴到的數據來源。在渲染過程中，偵測到的數據來源之後，之後就可以精確感知數據源的變動。到時候就可以根據需要重新進行渲染。當重新進行渲染之後，會生成一個新的樹，將新樹與舊樹進行對比，就可以最終得出應施加到真實DOM上的改動。最後再通過patch函數施加改動。
這樣做的主要原因是， 在瀏覽器當中，JavaScript的運算在現代的引擎中非常快，但DOM本身是非常緩慢的東西 。當你調用原生DOM API的時候，瀏覽器需要在JavaScript引擎的語境下去接觸原生的DOM的實現，這個過程有相當的性能損耗。所以，本質的考量是，要把耗費時間的操作儘量放在純粹的計算中去做，保證最後計算出來的需要實際接觸真實DOM的操作是最少的。
組件系統
現在很多的框架都走上了組件化的道路,組件的思想,每一個頁面 都是一個組件,在Vue中，父子組件之間的通信是通過 props 傳遞。從父向子單向傳遞；而如果子組件想要在父組件作用裏面產生副作用，就需要去派發事件。這樣就形成一個基本的父子通信模式，在涉及大規模狀態管理的時候會有額外的方案
狀態管理
狀態管理，本質上就是把整個應用抽象。臉書最早提出 Flux 這個概念的時，也是一個很鬆散的概念，而且官方的實現本身做得很難用。所以，社區就做了各種各樣的探索。圖中的這三個東西是一個單向數據流，State 驅動 View 的渲染，而用戶對 View 進行操作產生 Action，會使State產生變化，從而導致 View 重新渲染
總結
任何情況下都需要 聲明式的渲染功能 ，並希望儘可能避免手動操作，或者說是可變的 命令式操作 ，希望儘可能地讓DOM的更新操作是自動的，狀態變化的時候它就應該自動更新到正確的狀態；我們需要 組件系統 ，將一個大型的界面切分成一個一個更小的可控單元； 客戶端路由——這是針對單頁應用而言，不做就不需要，如果需要做單頁應用，那麼就需要有一個URL對應到一個應用的狀態，就需要有路由解決方案； 大規模的狀態管理 ——當應用簡單的時候，可能一個很基礎的狀態和界面映射可以解決問題，但是當應用變得很大，涉及多人協作的時候，就會涉及多個組件之間的共享、多個組件需要去改動同一份狀態，以及如何使得這樣大規模應用依然能夠高效運行，這就涉及大規模狀態管理的問題，當然也涉及到可維護性，還有 構建工具。現在，如果放眼前端的未來，當HTTP2普及後，可能會帶來構建工具的一次革命。但就目前而言，尤其是在中國的網絡環境下，打包和工程構建依然是非常重要且不可避免的一個環節。