1. 程式人生 > 實用技巧 >vue的一個簡單分享

vue的一個簡單分享

vue大致內容結構
模組要點
vue

漸進式框架、MVVM的設計模型

雙向資料繫結(vue2.0 & vue3.0)(單向資料流,單向資料繫結)

虛擬dom

事件指令(v-if、v-for、v-show)

計算屬性computed & watch

單頁面 & 多頁面

元件

元件通訊的幾種方式

註冊模式

路由

註冊模式

使用(hash 跟history 的模式)

vuex

單一狀態樹

四個模組

this.$store的註冊 及使用

官網用一句話來概括了vue 是個什麼樣的框架

“vue是一個漸進式框架”

關於漸進式這三個字,我可是查的的太久啦!

1、來詳細解釋下就是,一開始我們在開發h5頁面的時候,內容少的情況下,會把一個頁面的內容都寫在一個html檔案內。

2、但是當內容變的非常多的時候,要是還寫在一個檔案內,就會顯得內容非常的雜亂,臃腫,所以這個時候會把內容進行拆分,在vue裡就是拆分成不同的元件,例如一個title、一個input輸入框、一個列表等等,根據功能模組進行拆分。

3、那麼要是在開發單頁面的時候,涉及到頁面內容的替換,這時候就會需要用到我們的路由(vue-router),來實現頁面內容的更替。

4、在第二步中,咱們使用元件的時候,要是有元件之間的資料共享,會避免不了元件傳值的關係,父子之間的通訊官網有介紹,那麼兄弟元件的通訊,其實也是通過共同的父級來進行通訊的,那麼要是當需要共享的資料變多,元件關係變得複雜,通訊無疑就變得非常麻煩,因此就可以引入vuex來幫我們來管理資料(vuex一般在大型專案中使用,在小型專案用也沒啥必要哈哈哈哈)

下面再來展開描述。。。

首先來說下vue的一些基本的內容


一、使用來MVVM的設計模式

1、MVC

  • MVC分為:Model(模型),View(檢視),Controller(控制器)。Controller是Model和View的協調者,基本都是單向聯絡使用了MVVM的設計模式

2、MVVM

  • model - view - viewmodel,View的變化會自動更新到ViewModel,ViewModel的變化也會自動同步到View上顯示,通過資料來顯示檢視層,View和Model不直接聯絡

二、雙向資料繫結

雙向資料繫結(自動更新其實就是資料 邏輯層跟 檢視層 實現了資料繫結)

  1. 實現方法:資料劫持 結合釋出者-訂閱者模式
  2. vue2.0 核心方法:Object.defineProperty
    • 通過Object.defineProperty()來實現資料劫持的,內部有兩個屬性:get/set。get就是在讀取name屬性這個值觸發的函式,set就是在設定name屬性這個值觸發的函式。
    • 實現步驟:
      • 實現監聽器:observe;用來劫持並監聽所有屬性,如果有變動的,就通知訂閱者
        • Observer是一個數據監聽器,其實現核心方法就是Object.defineProperty( )。
      • 實現訂閱者:Watcher;收到屬性的變化通知並執行相應的函式,從而更新檢視
      • 實現解析器:compile;對每個節點元素進行掃描和解析,將相關指令對應初始化成一個訂閱者Watcher,並替換模板資料或者繫結相應的函式
      • 圖解:Dep就是一箇中間管理器;當訂閱者有很多個,需要有一個訊息訂閱器Dep來專門收集這些訂閱者,然後在監聽器Observer和訂閱者Watcher之間進行統一管理

  3. vue3.0 核心:proxy
    • 針對2.0版本:defineProperty的缺陷是隻能監聽一個屬性,所以要監聽一個物件裡面的所有屬性的畫,就需要做一個遞迴處理
    • 消除了之前 Vue2.x 中基於 Object.defineProperty 的實現所存在的很多限制:無法監聽 屬性的新增和刪除、陣列索引和長度的變更,並可以支援 Map、Set、WeakMap 和 WeakSet
  4. 單向資料繫結
    • 只有UI控制元件才存在雙向資料繫結,非UI控制元件只有單向
      • 單向:普通的渲染資料 v-bind:{{ }}
      • 雙向:像表單的view層更改直接同步到model層 v-model
    • 單雙向繫結,指的是View層跟Model層之間的對映關係
  5. 單向資料流
    • 單向資料流跟單雙向的資料繫結,其實是兩回事
    • 前面有解釋過單雙向繫結,單向資料流則是,元件之間的通訊要求
    • 父級與子級的通訊,規定父級prop的更新會向下流動到子元件中,但是反過來則不行。這樣會防止從子元件意外改變父級元件的狀態,否則導致應用的資料流向難以理解

三、虛擬DOM

  1. 真實的DOM及其解析過程
    1. 瀏覽器渲染引擎大概分成五步:

      1、建立DOM數,用html解析器解析html元素

      2、生成樣式表,用css解析器,分析css檔案

      3、構建render樹(渲染樹),attachment

      4、渲染樹佈局(position、margin、float等)

      5、繪製渲染樹(color、background等)

    2. 執行dom缺點:每次操作dom的時候,瀏覽器都會從構建dom樹開始從頭到位執行一遍流程,浪費計算機效能
  2. 虛擬dom的出現:為了解決瀏覽器的效能問題而被設計出來的
    1. 虛擬dom其實就是一個虛擬物件
    2. 更新dom的時候,不會立即去操作dom,而是將變化都儲存到一個JS物件中(虛擬dom),然後再一次性的attach到dom樹上
    3. 優勢:操作js物件 速度要快得多
  3. 比較兩棵虛擬dom的差異-diff演算法

    對比出差異之後,才會應用到真正的dom樹

四、計算屬性、事件監聽

  • 計算屬性 computed
    • 計算屬性是由data中的已知值,得到的一個新的值,不在data內部
    • 是依賴於某個或者某些屬性值,只有當依賴的資料發生變化時,才會發生變化
    • 具有快取能力,所以只有當資料再次改變時才會重新渲染,否則就會直接拿取快取中的資料
    • computed擅長處理的場景:一個數據受多個數據影響
  • 資料監聽 watch
    • 監聽某個資料的變化,支援深度監聽,可以接受2個引數(newValue, oldValue),即變化的最新值和上一次變化的舊值
    • 會生成一個watcher物件,在監視的屬性每次變動時都會觸發回撥,可以執行非同步操作
    • watch擅長處理的場景:一個數據影響多個數據

五、單頁面 / 多頁面

抽象派解釋……&&%*

  1. 單頁面: 簡單理解,只有一個html
  2. 多頁面:就是有多個html
  3. 對比優缺點:單頁面 首次載入損耗大,多頁面 首次載入快 ,但是頁面之間切換可能卡殼

接下來就說下元件了-_-


元件這裡有一個需要注意的地方,“單向資料流”,前面有介紹過了,對比單向資料傳遞,應該能區分開了吧~~~~~

元件這邊值得探討的,大概就是元件之間的通訊哈哈哈哈,別的呢(註冊啊、插槽啊balabala 太多了,感興趣的同志可以自己查一下了)

我們常用的prop/$emit ,這個都知道了,列舉一下,大概就是以下幾種通訊方式:

(下面的程式碼圖,當時學習的時候就給)

  1. Prop(常用)/$emit(元件封裝用的較多)
    • 父元件通過props的方式向子元件傳遞資料,而通過$emit子元件可以向父元件通訊
    • 父元件向子元件傳值

    • 子元件向父元件傳值
      • $emit繫結一個自定義事件, 當這個語句被執行時, 就會將引數arg傳遞給父元件,父元件通過v-on監聽並接收引數
      • 其實,我認為,這只是在子元件觸發了一個改變父級引數的指令,然後在父級對對應的引數進行操作,這也符合單向資料流的特點
  2. $children / $parent
    • 通過$parent和$children就可以訪問元件的例項,代表可以訪問此元件的所有方法和data

    • 使用:
      • 邊界情況
        • 如在#app上拿$parent得到的是new Vue()的例項,在這例項上再拿$parent得到的是undefined
        • 在最底層的子元件拿$children是個空陣列。
        • 得到$parent和$children的值不一樣,$children的值是陣列,而$parent是個物件
  3. vuex
  4. provide& inject(高階元件/元件庫用的較多)
  5. localStorage/sessionStorage
    • 通過window.localStorage.getItem(key)獲取資料
    • 通過window.localStorage.setItem(key,value)儲存資料
    • 使用時要注意資料格式的轉換
      • JSON.parse()/JSON.stringify()
    • 缺點是資料和狀態比較混亂,不太容易維護
    • localStorage/sessionStorage可以結合vuex, 實現資料的持久儲存,同時使用vuex解決資料和狀態混亂問題