class Checkbox extends React.Component { 
  
  
  
  
  constructor(props) { 
  
  
  
  
    //  這時(shí)候還不能使用this 
  
  
  
  
    super(props); 
  
  
  
  
    //  現(xiàn)在開(kāi)始可以使用this 
  
  
  
  
    console.log(props);      //  {} 
  
  
  
  
    console.log(this.props); //  {} 
  
  
  
  
    this.state = {};  
  
  
  
  
  } 
  
  
  
  
} 
 
 
 

 
 
 
 
  
  
  
  
// React 內(nèi)部 
  
  
  
  
class Component { 
  
  
  
  
  constructor(props) { 
  
  
  
  
    this.props = props; // 初始化 this.props 
  
  
  
  
    // ... 
  
  
  
  
  } 
  
  
  
  
} 
  
  
  
  
 
  
  
  
  
// React 內(nèi)部 
  
  
  
  
const instance = new Button(props); 
  
  
  
  
instance.props = props; // 給實(shí)例設(shè)置 props 
  
  
  
  
 
  
  
  
  
// Button類(lèi)組件 
  
  
  
  
class Button extends React.Component { 
  
  
  
  
  constructor(props) { 
  
  
  
  
    super(); //  我們忘了傳入 props 
  
  
  
  
    console.log(props);      //  {} 
  
  
  
  
    console.log(this.props); //  undefined 
  
  
  
  
  } 
  
  
  
  
} 
 
 
 

 
 
 
 
  
  
  
  
let currentHook: Hook | null = null; 
  
  
  
  
let nextCurrentHook: Hook | null = null; 
  
  
  
  
 
  
  
  
  
type Hooks = { 
  
  
  
  
  memoizedState: any, // 指向當(dāng)前渲染節(jié)點(diǎn) Fiber 
  
  
  
  
  baseState: any, // 初始化 initialState， 最新的state 
  
  
  
  
  baseUpdate: Update | null, 
  
  
  
  
  // 當(dāng)前需要更新的 Update ，每次更新完之后，會(huì)賦值上一個(gè) update，方便 react 在渲染錯(cuò)誤的邊緣，數(shù)據(jù)回溯 
  
  
  
  
  queue: UpdateQueue | null,// 可以讓state變化的，即update或dispach產(chǎn)生的update 
  
  
  
  
  next: Hook | null, // link 到下一個(gè) hooks 
  
  
  
  
} 
 
 
 

 
 
 
 
  
  
  
  
const fiber = { 
  
  
  
  
  stateNode: {},    // 節(jié)點(diǎn)實(shí)例 
  
  
  
  
  child: {},        // 子節(jié)點(diǎn) 
  
  
  
  
  sibling: {},      // 兄弟節(jié)點(diǎn) 
  
  
  
  
  return: {},       // 表示處理完成后返回結(jié)果所要合并的目標(biāo)，通常指向父節(jié)點(diǎn) 
  
  
  
  
}; 
 
 
 

 
 
 
 
  
  
  
  
// 定義 
  
  
  
  
const RenderProps = props => 
 
  
  
  
  
   {props.children(props)} 
  
  
  
  

 2.通過(guò)props中的任何函數(shù), 自行定義傳入內(nèi)容

 
 
 
 
  
  
  
  
// 定義 
  
  
  
  
const LoginForm = props => { 
  
  
  
  
  const flag = false; 
  
  
  
  
  const allProps = { flag, ...props }; 
  
  
  
  
 
  
  
  
  
  if (flag) { 
  
  
  
  
    return <>{props.login(allProps)} 
  
  
  
  
  } else { 
  
  
  
  
    return <>{props.notLogin(allProps)} 
  
  
  
  
  } 
  
  
  
  
} 
  
  
  
  
 
  
  
  
  
// 調(diào)用 
  
  
  
  
  
  
  
  
  login={() => 
LOGIN
} 
  
  
  
  
  noLogin={() => 
NOT LOGIN
} 
  
  
  
  
/> 
 
 
 

 優(yōu)點(diǎn)：

1、支持ES6

2、不用擔(dān)心props命名問(wèn)題，在render函數(shù)中只取需要的state

3、不會(huì)產(chǎn)生無(wú)用的組件加深層級(jí)

4、render props模式的構(gòu)建都是動(dòng)態(tài)的，所有的改變都在render中觸發(fā)，可以更好的利用組件內(nèi)的生命周期。

HOC: 接受一個(gè)組件作為參數(shù)，返回一個(gè)新的組件的函數(shù)。

 
 
 
 
  
  
  
  
class Home extends React.Component { 
  
  
  
  
  // UI 
  
  
  
  
} 
  
  
  
  
 
  
  
  
  
export default Connect()(Home); 
 
 
 

高階組件由于每次都會(huì)返回一個(gè)新的組件，對(duì)于react來(lái)說(shuō)，這是不利于diff和狀態(tài)復(fù)用的，所以高階組件的包裝不能在render 方法中進(jìn)行，而只能像上面那樣在組件聲明時(shí)包裹，這樣也就不利于動(dòng)態(tài)傳參。

優(yōu)點(diǎn)：

1、支持ES6

2、復(fù)用性強(qiáng)，HOC為純函數(shù)且返回值為組件，可以多層嵌套

3、支持傳入多個(gè)參數(shù)，增強(qiáng)了適用范圍

缺點(diǎn)：

1、當(dāng)多個(gè)HOC一起使用時(shí)，無(wú)法直接判斷子組件的props是哪個(gè)HOC負(fù)責(zé)傳遞的

2、多個(gè)組件嵌套，容易產(chǎn)生同樣名稱(chēng)的props

3、HOC可能會(huì)產(chǎn)生許多無(wú)用的組件，加深了組件的層級(jí)

總的來(lái)說(shuō)，render props其實(shí)和高階組件類(lèi)似，就是在puru component上增加state，響應(yīng)react的生命周期。

React 通信

react的數(shù)據(jù)流是單向的，最常見(jiàn)的就是通過(guò)props由父組件向子組件傳值。

• 父向子通信：傳入props
• 子向父通信：父組件向子組件傳一個(gè)函數(shù)，然后通過(guò)這個(gè)函數(shù)的回調(diào)，拿到子組件傳過(guò)來(lái)的值
• 父向?qū)O通信：利用context傳值。React.createContext()
• 兄弟間通信：

1、找一個(gè)相同的父組件，既可以用props傳遞數(shù)據(jù)，也可以用context的方式來(lái)傳遞數(shù)據(jù)。

2、用一些全局機(jī)制去實(shí)現(xiàn)通信，比如redux等

3、發(fā)布訂閱模式

react合成事件

React 合成事件(SyntheticEvent)是 React 模擬原生 DOM 事件所有能力的一個(gè)事件對(duì)象，即瀏覽器原生事件的跨瀏覽器包裝器。

為什么要使用合成事件?

1.進(jìn)行瀏覽器兼容，實(shí)現(xiàn)更好的跨平臺(tái)

React 采用的是頂層事件代理機(jī)制，能夠保證冒泡一致性，可以跨瀏覽器執(zhí)行。React 提供的合成事件用來(lái)抹平不同瀏覽器事件對(duì)象之間的差異，將不同平臺(tái)事件模擬合成事件。

2.避免垃圾回收

事件對(duì)象可能會(huì)被頻繁創(chuàng)建和回收，因此 React 引入事件池，在事件池中獲取或釋放事件對(duì)象。即 React 事件對(duì)象不會(huì)被釋放掉，而是存放進(jìn)一個(gè)數(shù)組中，當(dāng)事件觸發(fā)，就從這個(gè)數(shù)組中彈出，避免頻繁地去創(chuàng)建和銷(xiāo)毀(垃圾回收)。

3.方便事件統(tǒng)一管理和事務(wù)機(jī)制

實(shí)現(xiàn)原理

在 React 中，“合成事件”會(huì)以事件委托方式綁定在 document 對(duì)象上，并在組件卸載(unmount)階段自動(dòng)銷(xiāo)毀綁定的事件。

合成事件和原生事件

當(dāng)真實(shí) DOM 元素觸發(fā)事件，會(huì)冒泡到 document 對(duì)象后，再處理 React 事件;所以會(huì)先執(zhí)行原生事件，然后處理 React 事件;最后真正執(zhí)行 document 上掛載的事件。

合成事件和原生事件最好不要混用。原生事件中如果執(zhí)行了stopPropagation方法，則會(huì)導(dǎo)致其他React事件失效。因?yàn)樗性氐氖录o(wú)法冒泡到document上，所有的 React 事件都將無(wú)法被注冊(cè)。

合成事件的事件池

合成事件對(duì)象池，是 React 事件系統(tǒng)提供的一種性能優(yōu)化方式。合成事件對(duì)象在事件池統(tǒng)一管理，不同類(lèi)型的合成事件具有不同的事件池。

react 虛擬dom

什么是虛擬dom?

在 React 中，render 執(zhí)行的結(jié)果得到的并不是真正的 DOM 節(jié)點(diǎn)，而是輕量級(jí)的 JavaScript 對(duì)象，我們稱(chēng)之為 virtual DOM。它通過(guò)JS的Object對(duì)象模擬DOM中的節(jié)點(diǎn)，然后再通過(guò)特定的render方法將其渲染成真實(shí)的DOM節(jié)點(diǎn)。

虛擬 DOM 是 React 的一大亮點(diǎn)，具有batching(批處理) 和高效的 Diff 算法。batching 把所有的 DOM 操作搜集起來(lái)，一次性提交給真實(shí)的 DOM。diff 算法時(shí)間復(fù)雜度也從標(biāo)準(zhǔn)的的 Diff 算法的 O(n^3) 降到了 O(n)。

batching(批處理)

主要思想是，無(wú)論setState您在React事件處理程序或同步生命周期方法中進(jìn)行多少次調(diào)用，它都將被批處理成一個(gè)更新, 最終只有一次重新渲染。

虛擬 DOM 與 原生 DOM

如果沒(méi)有 Virtual DOM，就需要直接操作原生 DOM。在一個(gè)大型列表所有數(shù)據(jù)都變了的情況下，直接重置 innerHTML還算合理，但是，只有一行數(shù)據(jù)發(fā)生變化時(shí)，它也需要重置整個(gè) innerHTML，這就造成了大量浪費(fèi)。

innerHTML 和 Virtual DOM 的重繪性能消耗：

innerHTML: render html string + 重新創(chuàng)建所有 DOM 元素

Virtual DOM: render Virtual DOM + diff + 必要的 DOM 更新

Virtual DOM render + diff 顯然比渲染 html 字符串要慢，但是它依然是純 js 層面的計(jì)算，比起后面的 DOM 操作來(lái)說(shuō)，依然便宜了太多。innerHTML 的總計(jì)算量不管是 js 計(jì)算還是 DOM 操作都是和整個(gè)界面的大小相關(guān)，但 Virtual DOM 的計(jì)算量只有 js 計(jì)算和界面大小相關(guān)，DOM 操作是和數(shù)據(jù)的變動(dòng)量相關(guān)。

虛擬 DOM 與 MVVM

相比起 React，其他 MVVM 系框架比如 Angular, Knockout , Vue ，Avalon 采用的都是數(shù)據(jù)綁定。通過(guò) Directive/Binding 對(duì)象，觀察數(shù)據(jù)變化并保留對(duì)實(shí)際 DOM 元素的引用，當(dāng)有數(shù)據(jù)變化時(shí)進(jìn)行對(duì)應(yīng)的操作。MVVM 的變化檢查是數(shù)據(jù)層面的，而 React 的檢查是 DOM 結(jié)構(gòu)層面的。

MVVM 的性能也根據(jù)變動(dòng)檢測(cè)的實(shí)現(xiàn)原理有所不同：Angular 依賴(lài)于臟檢查;Knockout/Vue/Avalon 采用了依賴(lài)收集。

• 臟檢查：scope digest(watcher count) ) + 必要 DOM 更新
• 依賴(lài)收集：重新收集依賴(lài)(data change) ) + 必要 DOM 更新

Angular 最不效率的地方在于任何小變動(dòng)都有的和 watcher 數(shù)量相關(guān)的性能代價(jià)，當(dāng)所有數(shù)據(jù)都變了的時(shí)候，Angular更有效。依賴(lài)收集在初始化和數(shù)據(jù)變化的時(shí)候都需要重新收集依賴(lài)，這個(gè)代價(jià)在小量更新的時(shí)候幾乎可以忽略，但在數(shù)據(jù)量龐大的時(shí)候也會(huì)產(chǎn)生一定的消耗。

性能比較

在比較性能的時(shí)候，要分清楚初始渲染、小量數(shù)據(jù)更新、大量數(shù)據(jù)更新這些不同的場(chǎng)合。Virtual DOM、臟檢查 MVVM、數(shù)據(jù)收集 MVVM 在不同場(chǎng)合各有不同的表現(xiàn)和不同的優(yōu)化需求。

Virtual DOM 為了提升小量數(shù)據(jù)更新時(shí)的性能，也需要針對(duì)性的優(yōu)化，比如 shouldComponentUpdate 或是 immutable data。

• 初始渲染：Virtual DOM > 臟檢查 >= 依賴(lài)收集
• 小量數(shù)據(jù)更新：依賴(lài)收集 >> Virtual DOM + 優(yōu)化 > 臟檢查(無(wú)法優(yōu)化)> Virtual DOM 無(wú)優(yōu)化
• 大量數(shù)據(jù)更新：臟檢查 + 優(yōu)化 >= 依賴(lài)收集 + 優(yōu)化 > Virtual DOM(無(wú)法/無(wú)需優(yōu)化)>> MVVM 無(wú)優(yōu)化

diff 算法

傳統(tǒng) diff 算法通過(guò)循環(huán)遞歸對(duì)節(jié)點(diǎn)進(jìn)行依次對(duì)比，算法復(fù)雜度達(dá)到 O(n^3)，其中 n 是樹(shù)中節(jié)點(diǎn)的總數(shù)。O(n^3) 意味著如果要展示1000個(gè)節(jié)點(diǎn)，就要依次執(zhí)行上十億次的比較， 這是無(wú)法滿足現(xiàn)代前端性能要求的。

diff 算法主要包括幾個(gè)步驟：

• 用 JS 對(duì)象的方式來(lái)表示 DOM 樹(shù)的結(jié)構(gòu)，然后根據(jù)這個(gè)對(duì)象構(gòu)建出真實(shí)的 DOM 樹(shù)，插到文檔中。
• 當(dāng)狀態(tài)變更的時(shí)候，重新構(gòu)造一棵新的對(duì)象樹(shù)。然后用新的樹(shù)和舊的樹(shù)進(jìn)行比較，記錄兩棵樹(shù)的差異, 最后把所記錄的差異應(yīng)用到所構(gòu)建的真正的DOM樹(shù)上，視圖更新。

diff 策略

React 通過(guò)制定大膽的diff策略，將diff算法復(fù)雜度從 O(n^3) 轉(zhuǎn)換成 O(n) 。

• React 通過(guò)分層求異的策略，對(duì) tree diff 進(jìn)行算法優(yōu)化;
• React 通過(guò)相同類(lèi)生成相似樹(shù)形結(jié)構(gòu)，不同類(lèi)生成不同樹(shù)形結(jié)構(gòu)的策略，對(duì) component diff 進(jìn)行算法優(yōu)化;
• React 通過(guò)設(shè)置唯一 key的策略，對(duì) element diff 進(jìn)行算法優(yōu)化;

tree diff(層級(jí)比較)

React 對(duì)樹(shù)進(jìn)行分層比較，兩棵樹(shù)只會(huì)對(duì)同一層次的節(jié)點(diǎn)進(jìn)行比較。

當(dāng)發(fā)現(xiàn)節(jié)點(diǎn)已經(jīng)不存在，則該節(jié)點(diǎn)及其子節(jié)點(diǎn)會(huì)被完全刪除掉，不會(huì)進(jìn)行進(jìn)一步的比較。

這樣只需要對(duì)樹(shù)進(jìn)行一次遍歷，便能完成整個(gè) DOM 樹(shù)的比較。

當(dāng)出現(xiàn)節(jié)點(diǎn)跨層級(jí)移動(dòng)時(shí)，并不會(huì)出現(xiàn)移動(dòng)操作，而是以該節(jié)點(diǎn)為根節(jié)點(diǎn)的樹(shù)被重新創(chuàng)建，這是一種影響 React 性能的操作，因此 React 官方建議不要進(jìn)行 DOM 節(jié)點(diǎn)跨層級(jí)的操作。

• 先進(jìn)行樹(shù)結(jié)構(gòu)的層級(jí)比較，對(duì)同一個(gè)父節(jié)點(diǎn)下的所有子節(jié)點(diǎn)進(jìn)行比較;
• 接著看節(jié)點(diǎn)是什么類(lèi)型的，是組件就做 Component Diff;
• 如果節(jié)點(diǎn)是標(biāo)簽或者元素，就做 Element Diff;

注意：在開(kāi)發(fā)組件時(shí)，保持穩(wěn)定的 DOM 結(jié)構(gòu)會(huì)有助于性能的提升。例如，可以通過(guò) CSS 隱藏或顯示節(jié)點(diǎn)，而不是真的移除或添加 DOM 節(jié)點(diǎn)。

component diff(組件比較)

• 如果是同一類(lèi)型的組件，按照原策略繼續(xù)比較 virtual DOM tree。
• 如果不是，則將該組件判斷為 dirty component，替換整個(gè)組件下的所有子節(jié)點(diǎn)。舉個(gè)例子，當(dāng)一個(gè)元素從 變成

對(duì)于同一類(lèi)型的組件，有可能其 Virtual DOM 沒(méi)有任何變化，如果能夠確切的知道這點(diǎn)那可以節(jié)省大量的 diff 運(yùn)算時(shí)間。因此 React 允許用戶通過(guò) shouldComponentUpdate() 來(lái)判斷該組件是否需要進(jìn)行 diff。

對(duì)于兩個(gè)不同類(lèi)型但結(jié)構(gòu)相似的組件，不會(huì)比較二者的結(jié)構(gòu)，而且替換整個(gè)組件的所有內(nèi)容。不同類(lèi)型的 component 是很少存在相似 DOM tree 的機(jī)會(huì)，因此這種極端因素很難在實(shí)現(xiàn)開(kāi)發(fā)過(guò)程中造成重大影響的。

element diff (元素比較)

當(dāng)節(jié)點(diǎn)處于同一層級(jí)時(shí)，React diff 提供了三種節(jié)點(diǎn)操作，分別為：INSERT_MARKUP(插入)、MOVE_EXISTING(移動(dòng))和 REMOVE_NODE(刪除)。

• INSERT_MARKUP，新的 component 類(lèi)型不在老集合里， 即是全新的節(jié)點(diǎn)，需要對(duì)新節(jié)點(diǎn)執(zhí)行插入操作。
• MOVE_EXISTING，在老集合有新 component 類(lèi)型，且 element 是可更新的類(lèi)型，這種情況下需要做移動(dòng)操作，可以復(fù)用以前的 DOM 節(jié)點(diǎn)。
• REMOVE_NODE，老 component 類(lèi)型，在新集合里也有，但對(duì)應(yīng)的 element 不同則不能直接復(fù)用和更新，需要執(zhí)行刪除操作，或者老 component 不在新集合里的，也需要執(zhí)行刪除操作。

 
 
 
 
  
  
  
  
   
  
  
  
  
Duke
   
  
  
  
  
Villanova
   
  
  
  
 
  
  
  
  
 
  
  
  
  
   
  
  
  
  
Connecticut
   
  
  
  
  
Duke
   
  
  
  
  
Villanova
   
  
  
  
 
 
 
 

 React 并不會(huì)意識(shí)到應(yīng)該保留

key 優(yōu)化

為了解決上述問(wèn)題，React 引入了 key 屬性, 對(duì)同一層級(jí)的同組子節(jié)點(diǎn)，添加唯一 key 進(jìn)行區(qū)分。

當(dāng)子元素?fù)碛?key 時(shí)，React 使用 key 來(lái)匹配原有樹(shù)上的子元素以及最新樹(shù)上的子元素。如果有相同的節(jié)點(diǎn)，無(wú)需進(jìn)行節(jié)點(diǎn)刪除和創(chuàng)建，只需要將老集合中節(jié)點(diǎn)的位置進(jìn)行移動(dòng)，更新為新集合中節(jié)點(diǎn)的位置。

• 在開(kāi)發(fā)過(guò)程中，盡量減少類(lèi)似將最后一個(gè)節(jié)點(diǎn)移動(dòng)到列表首部的操作，當(dāng)節(jié)點(diǎn)數(shù)量過(guò)大或更新操作過(guò)于頻繁時(shí)，在一定程度上會(huì)影響 React 的渲染性能。
• key 不需要全局唯一，但在列表中需要保持唯一。
• Key 應(yīng)該具有穩(wěn)定，可預(yù)測(cè)，以及列表內(nèi)唯一的特質(zhì)。不穩(wěn)定的 key(比如通過(guò) Math.random() 生成的)會(huì)導(dǎo)致許多組件實(shí)例和 DOM 節(jié)點(diǎn)被不必要地重新創(chuàng)建，這可能導(dǎo)致性能下降和子組件中的狀態(tài)丟失。

react與vue區(qū)別

1. 監(jiān)聽(tīng)數(shù)據(jù)變化的實(shí)現(xiàn)原理不同

Vue通過(guò) getter/setter以及一些函數(shù)的劫持，能精確知道數(shù)據(jù)變化。

React默認(rèn)是通過(guò)比較引用的方式(diff)進(jìn)行的，如果不優(yōu)化可能導(dǎo)致大量不必要的VDOM的重新渲染。

2. 數(shù)據(jù)流不同

Vue1.0中可以實(shí)現(xiàn)兩種雙向綁定：父子組件之間props可以雙向綁定;組件與DOM之間可以通過(guò)v-model雙向綁定。

Vue2.x中父子組件之間不能雙向綁定了(但是提供了一個(gè)語(yǔ)法糖自動(dòng)幫你通過(guò)事件的方式修改)。

React一直不支持雙向綁定，提倡的是單向數(shù)據(jù)流，稱(chēng)之為onChange/setState()模式。

3. HoC和mixins

Vue組合不同功能的方式是通過(guò)mixin，Vue中組件是一個(gè)被包裝的函數(shù)，并不簡(jiǎn)單的就是我們定義組件的時(shí)候傳入的對(duì)象或者函數(shù)。

React組合不同功能的方式是通過(guò)HoC(高階組件)。

4. 模板渲染方式的不同

模板的語(yǔ)法不同，React是通過(guò)JSX渲染模板， Vue是通過(guò)一種拓展的HTML語(yǔ)法進(jìn)行渲染。

模板的原理不同，React通過(guò)原生JS實(shí)現(xiàn)模板中的常見(jiàn)語(yǔ)法，比如插值，條件，循環(huán)等。而Vue是在和組件JS代碼分離的單獨(dú)的模板中，通過(guò)指令來(lái)實(shí)現(xiàn)的，比如 v-if 。

舉個(gè)例子，說(shuō)明React的好處：react中render函數(shù)是支持閉包特性的，所以我們import的組件在render中可以直接調(diào)用。但是在Vue中，由于模板中使用的數(shù)據(jù)都必須掛在 this 上進(jìn)行一次中轉(zhuǎn)，所以我們import 一個(gè)組件完了之后，還需要在 components 中再聲明下。

5. 渲染過(guò)程不同

Vue可以更快地計(jì)算出Virtual DOM的差異，這是由于它會(huì)跟蹤每一個(gè)組件的依賴(lài)關(guān)系，不需要重新渲染整個(gè)組件樹(shù)。

React當(dāng)狀態(tài)被改變時(shí)，全部子組件都會(huì)重新渲染。通過(guò)shouldComponentUpdate這個(gè)生命周期方法可以進(jìn)行控制，但Vue將此視為默認(rèn)的優(yōu)化。

6. 框架本質(zhì)不同

Vue本質(zhì)是MVVM框架，由MVC發(fā)展而來(lái);

React是前端組件化框架，由后端組件化發(fā)展而來(lái)。

性能優(yōu)化

1. 靜態(tài)資源使用 CDN

CDN是一組分布在多個(gè)不同地理位置的 Web 服務(wù)器。當(dāng)服務(wù)器離用戶越遠(yuǎn)時(shí)，延遲越高。

2. 無(wú)阻塞

頭部?jī)?nèi)聯(lián)的樣式和腳本會(huì)阻塞頁(yè)面的渲染，樣式放在頭部并使用link方式引入，腳本放在尾部并使用異步方式加載

3. 壓縮文件

壓縮文件可以減少文件下載時(shí)間。

1.在 webpack 可以使用如下插件進(jìn)行壓縮：

JavaScript：UglifyPlugin

CSS ：MiniCssExtractPlugin

HTML：HtmlWebpackPlugin

2.使用 gzip 壓縮。通過(guò)向 HTTP 請(qǐng)求頭中的 Accept-Encoding 頭添加 gzip 標(biāo)識(shí)來(lái)開(kāi)啟這一功能。

4. 圖片優(yōu)化

1. 圖片懶加載
2. 響應(yīng)式圖片：瀏覽器根據(jù)屏幕大小自動(dòng)加載合適的圖片。
3. 降低圖片質(zhì)量：方法有兩種，一是通過(guò) webpack 插件 image-webpack-loader，二是通過(guò)在線網(wǎng)站進(jìn)行壓縮。

5. 減少重繪重排

• 降低 CSS 選擇器的復(fù)雜性
• 使用 transform 和 opacity 屬性更改來(lái)實(shí)現(xiàn)動(dòng)畫(huà)
• 用 JavaScript 修改樣式時(shí)，最好不要直接寫(xiě)樣式，而是替換 class 來(lái)改變樣式。
• 如果要對(duì) DOM 元素執(zhí)行一系列操作，可以將 DOM 元素脫離文檔流，修改完成后，再將它帶回文檔。推薦使用隱藏元素(display:none)或文檔碎片(DocumentFragement)，都能很好的實(shí)現(xiàn)這個(gè)方案。

6. 使用 requestAnimationFrame 來(lái)實(shí)現(xiàn)視覺(jué)變化

window.requestAnimationFrame() 告訴瀏覽器——你希望執(zhí)行一個(gè)動(dòng)畫(huà)，并且要求瀏覽器在下次重繪之前調(diào)用指定的回調(diào)函數(shù)更新動(dòng)畫(huà)。該方法需要傳入一個(gè)回調(diào)函數(shù)作為參數(shù)，該回調(diào)函數(shù)會(huì)在瀏覽器下一次重繪之前執(zhí)行

7. webpack 打包， 添加文件緩存

index.html 設(shè)置成 no-cache，這樣每次請(qǐng)求的時(shí)候都會(huì)比對(duì)一下 index.html 文件有沒(méi)變化，如果沒(méi)變化就使用緩存，有變化就使用新的 index.html 文件。

其他所有文件一律使用長(zhǎng)緩存，例如設(shè)置成緩存一年 maxAge: 1000 * 60 * 60 * 24 * 365。

前端代碼使用 webpack 打包，根據(jù)文件內(nèi)容生成對(duì)應(yīng)的文件名，每次重新打包時(shí)只有內(nèi)容發(fā)生了變化，文件名才會(huì)發(fā)生變化。

max-age: 設(shè)置緩存存儲(chǔ)的最大周期，超過(guò)這個(gè)時(shí)間緩存被認(rèn)為過(guò)期(單位秒)。在這個(gè)時(shí)間前，瀏覽器讀取文件不會(huì)發(fā)出新請(qǐng)求，而是直接使用緩存。

指定 no-cache 表示客戶端可以緩存資源，每次使用緩存資源前都必須重新驗(yàn)證其有效性

輸入url后發(fā)生了什么

1. DNS域名解析;
2. 建立TCP連接(三次握手);
3. 發(fā)送HTTP請(qǐng)求;
4. 服務(wù)器處理請(qǐng)求;
5. 返回響應(yīng)結(jié)果;
6. 關(guān)閉TCP連接(四次握手);
7. 瀏覽器解析HTML;
8. 瀏覽器布局渲染;

1. DNS域名解析：拿到服務(wù)器ip

客戶端收到你輸入的域名地址后，它首先去找本地的hosts文件，檢查在該文件中是否有相應(yīng)的域名、IP對(duì)應(yīng)關(guān)系，如果有，則向其IP地址發(fā)送請(qǐng)求，如果沒(méi)有，再去找DNS服務(wù)器。

2. 建立TCP鏈接：客戶端鏈接服務(wù)器

TCP提供了一種可靠、面向連接、字節(jié)流、傳輸層的服務(wù)。對(duì)于客戶端與服務(wù)器的TCP鏈接，必然要說(shuō)的就是『三次握手』。“3次握手”的作用就是雙方都能明確自己和對(duì)方的收、發(fā)能力是正常的。

客戶端發(fā)送一個(gè)帶有SYN標(biāo)志的數(shù)據(jù)包給服務(wù)端，服務(wù)端收到后，回傳一個(gè)帶有SYN/ACK標(biāo)志的數(shù)據(jù)包以示傳達(dá)確認(rèn)信息，最后客戶端再回傳一個(gè)帶ACK標(biāo)志的數(shù)據(jù)包，代表握手結(jié)束，連接成功。

SYN —— 用于初如化一個(gè)連接的序列號(hào)。

ACK —— 確認(rèn)，使得確認(rèn)號(hào)有效。

RST —— 重置連接。

FIN —— 該報(bào)文段的發(fā)送方已經(jīng)結(jié)束向?qū)Ψ桨l(fā)送數(shù)據(jù)。

• 客戶端：“你好，在家不?！?-- SYN
• 服務(wù)端：“在的，你來(lái)吧。” -- SYN + ACK
• 客戶端：“好嘞?！?-- ACK

3. 發(fā)送HTTP請(qǐng)求

4. 服務(wù)器處理請(qǐng)求

5. 返回響應(yīng)結(jié)果

6. 關(guān)閉TCP連接(需要4次握手)

為了避免服務(wù)器與客戶端雙方的資源占用和損耗，當(dāng)雙方?jīng)]有請(qǐng)求或響應(yīng)傳遞時(shí)，任意一方都可以發(fā)起關(guān)閉請(qǐng)求。

關(guān)閉連接時(shí)，服務(wù)器收到對(duì)方的FIN報(bào)文時(shí)，僅僅表示客戶端不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)，而服務(wù)器也未必全部數(shù)據(jù)都發(fā)送給客戶端，所以服務(wù)器可以立即關(guān)閉，也可以發(fā)送一些數(shù)據(jù)給對(duì)方后，再發(fā)送FIN報(bào)文給對(duì)方來(lái)表示同意現(xiàn)在關(guān)閉連接，因此，己方ACK和FIN一般都會(huì)分開(kāi)發(fā)送，從而導(dǎo)致多了一次。

• 客戶端：“兄弟，我這邊沒(méi)數(shù)據(jù)要傳了，咱關(guān)閉連接吧。” -- FIN + seq
• 服務(wù)端：“收到，我看看我這邊有木有數(shù)據(jù)了?！?-- ACK + seq + ack
• 服務(wù)端：“兄弟，我這邊也沒(méi)數(shù)據(jù)要傳你了，咱可以關(guān)閉連接了?！?- FIN + ACK + seq + ack
• 客戶端：“好嘞?！?-- ACK + seq + ack

7. 瀏覽器解析HTML

瀏覽器需要加載解析的不僅僅是HTML，還包括CSS、JS，以及還要加載圖片、視頻等其他媒體資源。

瀏覽器通過(guò)解析HTML，生成DOM樹(shù)，解析CSS，生成CSSOM樹(shù)，然后通過(guò)DOM樹(shù)和CSSPOM樹(shù)生成渲染樹(shù)。渲染樹(shù)與DOM樹(shù)不同，渲染樹(shù)中并沒(méi)有head、display為none等不必顯示的節(jié)點(diǎn)。

• 瀏覽器的解析過(guò)程并非是串連進(jìn)行的，比如在解析CSS的同時(shí)，可以繼續(xù)加載解析HTML，但在解析執(zhí)行JS腳本時(shí)，會(huì)停止解析后續(xù)HTML，會(huì)出現(xiàn)阻塞問(wèn)題。

8. 瀏覽器渲染頁(yè)面

根據(jù)渲染樹(shù)布局，計(jì)算CSS樣式，即每個(gè)節(jié)點(diǎn)在頁(yè)面中的大小和位置等幾何信息。HTML默認(rèn)是流式布局的，CSS和js會(huì)打破這種布局，改變DOM的外觀樣式以及大小和位置。最后瀏覽器繪制各個(gè)節(jié)點(diǎn)，將頁(yè)面展示給用戶。

replaint：屏幕的一部分重畫(huà)，不影響整體布局，比如某個(gè)CSS的背景色變了，但元素的幾何尺寸和位置不變。

reflow：意味著元素的幾何尺寸變了，需要重新計(jì)算渲染樹(shù)。

參考：

細(xì)說(shuō)瀏覽器輸入U(xiǎn)RL后發(fā)生了什么

瀏覽器輸入 URL 后發(fā)生了什么?

前端路由

什么是路由

路由是用來(lái)跟后端服務(wù)器進(jìn)行交互的一種方式，通過(guò)不同的路徑請(qǐng)求不同的資源。

路由這概念最開(kāi)始是在后端出現(xiàn), 在前后端不分離的時(shí)期, 由后端來(lái)控制路由, 服務(wù)器接收客戶端的請(qǐng)求,解析對(duì)應(yīng)的url路徑, 并返回對(duì)應(yīng)的頁(yè)面/資源。

前端路由

Ajax，全稱(chēng) Asynchronous JavaScript And XML，是瀏覽器用來(lái)實(shí)現(xiàn)異步加載的一種技術(shù)方案。

在Ajax沒(méi)有出現(xiàn)時(shí)期，大多數(shù)的網(wǎng)頁(yè)都是通過(guò)直接返回 HTML，用戶的每次更新操作都需要重新刷新頁(yè)面，及其影響交互體驗(yàn)。為了解決這個(gè)問(wèn)題，提出了Ajax(異步加載方案), 有了 Ajax 后，用戶交互就不用每次都刷新頁(yè)面。后來(lái)出現(xiàn)SPA單頁(yè)應(yīng)用。

SPA 中用戶的交互是通過(guò) JS 改變 HTML 內(nèi)容來(lái)實(shí)現(xiàn)的，頁(yè)面本身的 url 并沒(méi)有變化，這導(dǎo)致了兩個(gè)問(wèn)題：

• SPA 無(wú)法記住用戶的操作記錄，無(wú)論是刷新、前進(jìn)還是后退，都無(wú)法展示用戶真實(shí)的期望內(nèi)容。
• SPA 中雖然由于業(yè)務(wù)的不同會(huì)有多種頁(yè)面展示形式，但只有一個(gè) url，對(duì) SEO 不友好，不方便搜索引擎進(jìn)行收錄。

前端路由就是為了解決上述問(wèn)題而出現(xiàn)的。

前端路由的實(shí)現(xiàn)方式

前端路由的實(shí)現(xiàn)實(shí)際上是檢測(cè) url 的變化，截獲 url 地址，解析來(lái)匹配路由規(guī)則。有下面兩種實(shí)現(xiàn)方式：

1. Hash模式

hash 就是指 url 后的 # 號(hào)以及后面的字符。 #后面 hash 值的變化，并不會(huì)導(dǎo)致瀏覽器向服務(wù)器發(fā)出請(qǐng)求，瀏覽器不發(fā)請(qǐng)求，也就不會(huì)刷新頁(yè)面。

hash 的改變會(huì)觸發(fā) hashchange 事件，可以用onhashchange事件來(lái)監(jiān)聽(tīng)hash值的改變。

 
 
 
 
  
  
  
  
// 監(jiān)聽(tīng)hash變化，點(diǎn)擊瀏覽器的前進(jìn)后退會(huì)觸發(fā) 
  
  
  
  
window.onhashchange = function() { ... } 
  
  
  
  
 
  
  
  
  
window.addEventListener('hashchange', function(event) { ...}, false); 
 
 
 

2.History 模式

在 HTML5 之前，瀏覽器就已經(jīng)有了 history 對(duì)象。但在早期的 history 中只能用于多頁(yè)面的跳轉(zhuǎn)：

 
 
 
 
  
  
  
  
history.go(-1);       // 后退一頁(yè) 
  
  
  
  
history.go(2);        // 前進(jìn)兩頁(yè) 
  
  
  
  
history.forward();    // 前進(jìn)一頁(yè) 
  
  
  
  
history.back();       // 后退一頁(yè) 
 
 
 

在 HTML5 的規(guī)范中，history 新增了幾個(gè) API:

 
 
 
 
  
  
  
  
history.pushState();   // 向當(dāng)前瀏覽器會(huì)話的歷史堆棧中添加一個(gè)狀態(tài) 
  
  
  
  
history.replaceState();// 修改了當(dāng)前的歷史記錄項(xiàng)（不是新建一個(gè)） 
  
  
  
  
history.state          // 返回一個(gè)表示歷史堆棧頂部的狀態(tài)的值 
 
 
 

由于 history.pushState() 和 history.replaceState() 可以改變 url 同時(shí)，不會(huì)刷新頁(yè)面，所以在 HTML5 中的 histroy 具備了實(shí)現(xiàn)前端路由的能力。

window對(duì)象提供了onpopstate事件來(lái)監(jiān)聽(tīng)歷史棧的改變,一旦歷史棧信息發(fā)生改變, 便會(huì)觸發(fā)該事件。

• 調(diào)用history.pushState()或history.replaceState()不會(huì)觸發(fā)popstate事件。只有在做出瀏覽器動(dòng)作時(shí)，才會(huì)觸發(fā)該事件，例如執(zhí)行history.back()或history.forward()后觸發(fā) window.onpopstate事件。

 
 
 
 
  
  
  
  
// 歷史棧改變 
  
  
  
  
window.onpopstate = function() { ... } 
 
 
 

注意：pushState() 不會(huì)造成 hashchange 事件調(diào)用, 即使新的URL和之前的URL只是錨的數(shù)據(jù)不同。

兩種模式對(duì)比

前端路由實(shí)踐

vue-router/react-router 都是基于前端路由的原理實(shí)現(xiàn)的~

react-router常用的 history 有三種形式:

• browserHistory: 使用瀏覽器中的History API 用于處理 URL。history 在 DOM 上的實(shí)現(xiàn)，用于支持 HTML5 history API 的瀏覽器。
• hashHistory: 使用 URL 中的 hash(#)部分去創(chuàng)建路由。history 在 DOM 上的實(shí)現(xiàn)，用于舊版瀏覽器。
• createMemoryHistory: 不會(huì)在地址欄被操作或讀取，history 在內(nèi)存上的實(shí)現(xiàn)，用于測(cè)試或非 DOM 環(huán)境(例如 React Native)。

Babel Plugin與preset區(qū)別

Babel是代碼轉(zhuǎn)換器，比如將ES6轉(zhuǎn)成ES5，或者將JSX轉(zhuǎn)成JS等。借助Babel，開(kāi)發(fā)者可以提前用上新的JS特性。

• 原始代碼 --> [Babel Plugin] --> 轉(zhuǎn)換后的代碼

Plugin

實(shí)現(xiàn)Babel代碼轉(zhuǎn)換功能的核心，就是Babel插件(plugin)。Babel插件一般盡可能拆成小的力度，開(kāi)發(fā)者可以按需引進(jìn), 既提高了性能，也提高了擴(kuò)展性。比如對(duì)ES6轉(zhuǎn)ES5的功能，Babel官方拆成了20+個(gè)插件。開(kāi)發(fā)者想要體驗(yàn)ES6的箭頭函數(shù)特性，那只需要引入transform-es2015-arrow-functions插件就可以，而不是加載ES6全家桶。

Preset

可以簡(jiǎn)單的把Babel Preset視為Babel Plugin的集合。想要將所有ES6的代碼轉(zhuǎn)成ES5，逐個(gè)插件引入的效率比較低下, 就可以采用Babel Preset。比如babel-preset-es2015就包含了所有跟ES6轉(zhuǎn)換有關(guān)的插件。

Plugin與Preset執(zhí)行順序

可以同時(shí)使用多個(gè)Plugin和Preset，此時(shí)，它們的執(zhí)行順序非常重要。

1. 先執(zhí)行完所有Plugin，再執(zhí)行Preset。
2. 多個(gè)Plugin，按照聲明次序順序執(zhí)行。
3. 多個(gè)Preset，按照聲明次序逆序執(zhí)行。

比如.babelrc配置如下，那么執(zhí)行的順序?yàn)椋?/p>

1. Plugin：transform-react-jsx、transform-async-to-generator
2. Preset：es2016、es2015

 
 
 
 
  
  
  
  
{ 
  
  
  
  
  "presets": [  
  
  
  
  
    "es2015", 
  
  
  
  
    "es2016"     
  
  
  
  
  ], 
  
  
  
  
  "plugins": [  
  
  
  
  
    "transform-react-jsx", 
  
  
  
  
    "transform-async-to-generator" 
  
  
  
  
  ] 
  
  
  
  
} 
 
 
 

怎樣開(kāi)發(fā)和部署前端代碼

為了進(jìn)一步提升網(wǎng)站性能，會(huì)把靜態(tài)資源和動(dòng)態(tài)網(wǎng)頁(yè)分集群部署，靜態(tài)資源會(huì)被部署到CDN節(jié)點(diǎn)上，網(wǎng)頁(yè)中引用的資源也會(huì)變成對(duì)應(yīng)的部署路徑。當(dāng)需要更新靜態(tài)資源的時(shí)候，同時(shí)也會(huì)更新html中的引用。

如果同時(shí)改了頁(yè)面結(jié)構(gòu)和樣式，也更新了靜態(tài)資源對(duì)應(yīng)的url地址，現(xiàn)在要發(fā)布代碼上線，是先上線頁(yè)面，還是先上線靜態(tài)資源?

1. 先部署頁(yè)面，再部署資源：在二者部署的時(shí)間間隔內(nèi)，如果有用戶訪問(wèn)頁(yè)面，就會(huì)在新的頁(yè)面結(jié)構(gòu)中加載舊的資源，并且把這個(gè)舊版本的資源當(dāng)做新版本緩存起來(lái)，其結(jié)果就是：用戶訪問(wèn)到了一個(gè)樣式錯(cuò)亂的頁(yè)面，除非手動(dòng)刷新，否則在資源緩存過(guò)期之前，頁(yè)面會(huì)一直執(zhí)行錯(cuò)誤。
2. 先部署資源，再部署頁(yè)面：在部署時(shí)間間隔之內(nèi)，有舊版本資源本地緩存的用戶訪問(wèn)網(wǎng)站，由于請(qǐng)求的頁(yè)面是舊版本的，資源引用沒(méi)有改變，瀏覽器將直接使用本地緩存，這種情況下頁(yè)面展現(xiàn)正常;但沒(méi)有本地緩存或者緩存過(guò)期的用戶訪問(wèn)網(wǎng)站，就會(huì)出現(xiàn)舊版本頁(yè)面加載新版本資源的情況，導(dǎo)致頁(yè)面執(zhí)行錯(cuò)誤，但當(dāng)頁(yè)面完成部署，這部分用戶再次訪問(wèn)頁(yè)面又會(huì)恢復(fù)正常了。

這個(gè)奇葩問(wèn)題，起源于資源的 覆蓋式發(fā)布，用 待發(fā)布資源 覆蓋 已發(fā)布資源，就有這種問(wèn)題。

解決它也好辦，就是實(shí)現(xiàn) 非覆蓋式發(fā)布。用文件的摘要信息來(lái)對(duì)資源文件進(jìn)行重命名，把摘要信息放到資源文件發(fā)布路徑中，這樣，內(nèi)容有修改的資源就變成了一個(gè)新的文件發(fā)布到線上，不會(huì)覆蓋已有的資源文件。

上線過(guò)程中，先全量部署靜態(tài)資源，再灰度部署頁(yè)面，整個(gè)問(wèn)題就比較完美的解決了。

大公司的靜態(tài)資源優(yōu)化方案，基本上要實(shí)現(xiàn)這么幾個(gè)東西：

1. 配置超長(zhǎng)時(shí)間的本地緩存 —— 節(jié)省帶寬，提高性能
2. 采用內(nèi)容摘要作為緩存更新依據(jù) —— 精確的緩存控制
3. 靜態(tài)資源CDN部署 —— 優(yōu)化網(wǎng)絡(luò)請(qǐng)求
4. 更改資源發(fā)布路徑實(shí)現(xiàn)非覆蓋式發(fā)布 —— 平滑升級(jí)

大數(shù)相加

 
 
 
 
  
  
  
  
function add(a, b){ 
  
  
  
  
   const maxLength = Math.max(a.length, b.length); 
  
  
  
  
   a = a.padStart(maxLength, 0); 
  
  
  
  
   b = b.padStart(maxLength, 0); 
  
  
  
  
   let t = 0; 
  
  
  
  
   let f = 0;  
  
  
  
  
   let sum = ""; 
  
  
  
  
 
  
  
  
  
   for (let i = maxLength - 1; i >= 0; i--) { 
  
  
  
  
      t = parseInt(a[i]) + parseInt(b[i]) + f; 
  
  
  
  
      f = Math.floor(t / 10); 
  
  
  
  
      sum = `${t % 10}${sum}`; 
  
  
  
  
   } 
  
  
  
  
   if (f === 1){ 
  
  
  
  
      sum = "1" + sum; 
  
  
  
  
   } 
  
  
  
  
   return sum; 
  
  
                                                  

                                                分享標(biāo)題：前端基礎(chǔ)知識(shí)整理匯總（下）                                                

                                                文章轉(zhuǎn)載：http://m.fisionsoft.com.cn/article/dpshgpd.html