前端學習筆記（十三）

1.Vue 經常使用的指令：

v-model v-if v-else v-show v-for v-bind----簡寫: :class="qq"、:type="text" v-on----簡寫: @click="qq"

2.v-model的原理

text和textarea元素使用value 屬性和 input事件； checkbox 和radio使用checked 屬性和change 事件； select字段將value 做爲prop並將change 做爲事件。 修飾符： .lazy .number .trim

3.修改頁面上綁定的變量值，好比一段文章的title，下一行代碼是否能當即獲取到title的變化

不能。須要nextTick。Vue異步執行DOM 更新。只要觀察到數據變化，Vue 將開啓一個隊列，並緩衝在同一事件循環中發生的全部數據改變。若是同一個 watcher 被屢次觸發，只會被推入到隊列中一次。這種在緩衝時去除重複數據對於避免沒必要要的計算和 DOM 操做上很是重要。而後，在下一個的事件循環「tick」中，Vue 刷新隊列並執行實際 (已去重的) 工做。Vue在內部嘗試對異步隊列使用原生的Promise.then和MessageChannel，若是執行環境不支持，會採用 setTimeout(fn, 0)代替。

4.Vue怎麼進行依賴收集的

Observer 的構造函數使用defineReactive方法給對象的鍵響應式化，給對象的屬性遞歸添加 getter/setter ，當data被取值的時候觸發 getter並蒐集依賴，當被修改值的時候先觸發getter再觸發setter 並派發更新

每一個組件實例都有相應的 Watcher實例對象，它會在組件渲染的過程當中把屬性記錄爲依賴，以後當依賴項的setter 被調用時，會通知watcher從新計算，從而導致它關聯的組件得以更新。

5.爲何須要Vuex

1、多個視圖依賴於同一狀態。
2、來自不一樣視圖的行爲須要變動同一狀態。
對於問題一，傳參的方法對於多層嵌套的組件將會很是繁瑣，而且對於兄弟組件間的狀態傳遞無能爲力。對於問題二，咱們常常會採用父子組件直接引用或者經過事件來變動和同步狀態的多份拷貝。以上的這些模式很是脆弱，一般會致使沒法維護的代碼。

所以，咱們爲何不把組件的共享狀態抽取出來，以一個全局單例模式管理呢？在這種模式下，咱們的組件樹構成了一個巨大的「視圖」，無論在樹的哪一個位置，任何組件都能獲取狀態或者觸發行爲！
另外，經過定義和隔離狀態管理中的各類概念並強制遵照必定的規則，咱們的代碼將會變得更結構化且易維護。

6.介紹一下Vue中的computed

咱們能夠將同一函數定義爲一個方法而不是一個計算屬性。兩種方式的最終結果確實是徹底相同的。然而，不一樣的是計算屬性是基於它們的響應式依賴進行緩存的。只在相關響應式依賴發生改變時它們纔會從新求值。

計算屬性的setter VSwatch
A.當組件初始化的時候，computed 和 data會分別創建各自的響應系統，Observer遍歷 data中每一個屬性設置 get/set數據攔截
B.初始化computed會調用 initComputed 函數
a.註冊一個watcher 實例，並在內實例化一個 Dep消息訂閱器用做後續收集依賴（好比渲染函數的 watcher或者其餘觀察該計算屬性變化的 watcher）
b.調用計算屬性時會觸發其Object.defineProperty的get訪問器函數
c.調用watcher.depend()方法向自身的消息訂閱器dep 的subs 中添加其餘屬性的 watcher
d.調用watcher 的evaluate方法（進而調用watcher的 get 方法）讓自身成爲其餘watcher的消息訂閱器的訂閱者，首先將watcher賦給Dep.target，而後執行 getter求值函數，當訪問求值函數裏面的屬性（好比來自 data、props 或其餘 computed）時，會一樣觸發它們的get訪問器函數從而將該計算屬性的watcher添加到求值函數中屬性的 watcher 的消息訂閱器 dep中，當這些操做完成，最後關閉 Dep.target賦爲 null 並返回求值函數結果。
C.當某個屬性發生變化，觸發set攔截函數，而後調用自身消息訂閱器 dep的 notify 方法，遍歷當前dep中保存着全部訂閱者 wathcer 的 subs 數組，並逐個調用 watcher 的 update方法，完成響應更新。

7.Webpack的流程

• 初始化參數：從配置文件和Shell語句中讀取與合併參數，得出最終的參數；
• 開始編譯：用上一步獲得的參數初始化Compiler 對象，加載全部配置的插件，執行對象的 run方法開始執行編譯；
• 肯定入口：根據配置中的entry找出全部的入口文件
• 編譯模塊：從入口文件出發，調用全部配置的Loader對模塊進行翻譯，再找出該模塊依賴的模塊，再遞歸本步驟直到全部入口依賴的文件都通過了本步驟的處理；
• 完成模塊編譯：在通過第4步使用Loader翻譯完全部模塊後，獲得了每一個模塊被翻譯後的最終內容以及它們之間的依賴關係；
• 輸出資源：根據入口和模塊之間的依賴關係，組裝成一個個包含多個模塊的Chunk，再把每一個Chunk轉換成一個單獨的文件加入到輸出列表，這步是能夠修改輸出內容的最後機會；
• 輸出完成：在肯定好輸出內容後，根據配置肯定輸出的路徑和文件名，把文件內容寫入到文件系統。 在以上過程當中，webpack會在特定的時間點廣播出特定的事件，插件在監聽到感興趣的事件後會執行特定的邏輯，而且插件能夠調用webpack提供的API 改變 webpack 的運行結果。

8.Class的Constructor調用Super

A.看成函數使用
在constructor中必須調用 super方法，由於子類沒有本身的this對象，而是繼承父類的this對象，而後對其進行加工,而super就表明了父類的構造函數。
B.看成對象使用
在普通方法中，指向父類的原型對象；在靜態方法中，指向父類。

9.Node裏面兩個文件互相require怎樣

爲了防止模塊載入的死循環，Node.js在模塊第一次載入後會把它的結果進行緩存，下一次再對它進行載入的時候會直接從緩存中取出結果。因此在這種循環依賴情形下，不會有死循環，可是卻會由於緩存形成模塊沒有按照咱們預想的那樣被導出。 詳細點擊連接🔗

10.移動端響應式、自適應適配

響應式設計與自適應設計的區別：響應式開發一套界面，經過檢測視口分辨率，針對不一樣客戶端在客戶端作代碼處理，來展示不一樣的佈局和內容；自適應須要開發多套界面，經過檢測視口分辨率，來判斷當前訪問的設備是pc端、平板、手機，從而請求服務層，返回不一樣的頁面。 響應式佈局的實現方案： A.媒體查詢 B.百分比佈局 C.rem佈局 D.視口單位vh、vw、vmax、vmin

11.bootstrapt實現響應式的原理是什麼

Bootstrap採起12列的柵格體系，根據主流設備的尺寸進行分段，每段寬度固定，經過百分比和媒體查詢實現響應式佈局。

12.304緩存

強緩存經過Expires和Cache-Control兩種響應頭實現
Expires是http1.0提出的一個表示資源過時時間的header，它描述的是一個絕對時間，由服務器返回。 Expires受限於本地時間，若是修改了本地時間，可能會形成緩存失效
Cache-Control出現於HTTP / 1.1，優先級高於Expires ,表示的是相對時間
Cache-Control: no-cache 是能夠緩存到本地緩存區中的，只是在與原始服務器進行新鮮度再驗證以前，緩存不能將其提供給客戶端使用； Cache-Control: no-store纔是真正的不緩存數據到本地；
Cache-Control: public能夠被全部用戶緩存（多用戶共享），包括終端和CDN等中間代理服務器；
Cache-Control: private只能被終端瀏覽器緩存（並且是私有緩存），不容許中繼緩存服務器進行緩存；
協商緩存是利用的是【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】這兩對Header來管理的

13.react的生命週期函數

React生命週期主要包括三個階段：初始化階段、運行中階段和銷燬階段，在React不一樣的生命週期裏，會依次觸發不一樣的鉤子函數 A.初始化階段

• 設置組件的默認屬性
• 設置組件的初始化狀態
• componentWillMount()
• render()
• componentDidMount() B.運行中階段
• componentWillReceiveProps()
• shouldComponentUpdate()
• componentWillUpdate()
• componentDidUpdate() C.銷燬階段
• componentWillUnmount()

14.react組件之間的傳遞數據

• Props
• context
• redux

15.HTTP2.0

• 二進制傳輸
• 多路複用
• Header壓縮
• 服務器推送
• 更安全

16.position的屬性

• static
• relative
• absolute
• fixed
• stacky

17.HTTPS（securely transferring web pages）服務器

默認端口號爲443/tcp  443/udp

18.21.v-if、v-show

官方解釋：
v-if是「真正」的條件渲染，由於它會確保在切換過程當中條件塊內的事件監聽器和子組件適當地被銷燬和重建。
v-if也是惰性的：若是在初始渲染時條件爲假，則什麼也不作——直到條件第一次變爲真時，纔會開始渲染條件塊。
相比之下，v-show就簡單得多——無論初始條件是什麼，元素老是會被渲染，而且只是簡單地基於 CSS 進行切換。
通常來講，v-if有更高的切換開銷，而 v-show有更高的初始渲染開銷。
所以，若是須要很是頻繁地切換，則使用v-show較好；若是在運行時條件不多改變，則使用v-if較好。
理解：

• 手段：v-if是動態的向DOM樹內添加或者刪除DOM元素；v-show是經過設置DOM元素的display樣式屬性控制顯隱；
• 編譯過程：v-if切換有一個局部編譯/卸載的過程，切換過程當中合適地銷燬和重建內部的事件監聽和子組件；v-show只是簡單的基於css切換；
• 編譯條件：v-if是惰性的，若是初始條件爲假，則什麼也不作；只有在條件第一次變爲真時纔開始局部編譯（編譯被緩存後，而後再切換的時候進行局部卸載); v-show是在任何條件下（首次條件是否爲真）都被編譯，而後被緩存，並且DOM元素保留；
• 性能消耗：v-if有更高的切換消耗；v-show有更高的初始渲染消耗