實用卻易忽視的DevTools除錯技巧
作為前端開發者，免不了要和 DevTools 打交道,熟練的使用 DevTools 能夠大大提高我們的工作效率。然而，開發者工具的使用並沒有得到足夠的重視。
工欲善其事必先利其器，更何況，工具的學習成本比專業技能的學習成本小的多。
Chrome 有不同版本，如果想第一時間體驗一些新的功能可以使用除穩定版本的其它版本。
本次主要圍繞著 Workspace 和 Blockbox script 這兩點來感受它們帶來的便利。
Workspace
Workspace 主要還是將瀏覽器關聯本地檔案，使得瀏覽器擁有讀寫本地檔案的權利。
隨著前端的發展，業務和邏輯也越來越複雜。還好打包壓縮工具應運而生，還有 sourceMap 的使用，又讓我們從壓縮混淆的程式碼中有了看原始碼的體驗。
此時我們依然可以 DevTools 裡Sources
頁籤裡的Filesystem
頁籤新增本地資料夾，從瀏覽器裡修改本地檔案。
這個功能或許還有點用，但是還是不如人意。因為修改後的檔案需要重新整理後才能顯示變動，而檔案被更改後，打包工具需要重新編譯，編譯時間或許很長或許很短，而且頁面被被整體重新整理了，給人一種很生硬的感覺。
不過，還好有熱元件替換
這麼一說。給我們的應用程式加上這貨之後，我們的開發將會更加絲滑:wink:。
熱元件替換
以create-react-app
為例:chestnut:（最新版本），步驟如下。也可以看看:eyes:官方怎麼說react-hot-loader
.
1⃣️：
npm install react-hot-loader --save-dev
2⃣️：在entry
中新增isEnvDevelopment && 'react-hot-loader/patch',
3⃣️：在 oneOf 中babel-loader
的 plugins 中新增['react-hot-loader/babel'],
4⃣️：在入口檔案新增以下內容
import { AppContainer } from 'react-hot-loader'
const root = document.getElementById('root')
const render = (Component) => {
ReactDOM.render(
<AppContainer>
<Component />
</AppContainer>,
root
)
}
render(App)
if (module.hot) {
module.hot.accept('./App', () => {
const NextApp = require('./App').default
render(NextApp)
})
}
至此，熱元件替換改造完成，讓我們再次感受下。
通過以上展示，我們可以發現，整個介面只是區域性被替換了，過渡得很自然。這應該才是我們想要的效果:sparkles:。插一句，在Network
頁籤中，Preserve log 一定要勾選上:ballot_box_with_check:。這樣的話，即使頁面重新整理了，也是有記錄:memo:的，非常方便在頁面跳轉重新整理時使用。
Blockbox script
如果說以上是提高了開發上的效率，那麼這個Blockbox script
功能將會在定位上省下不少時間。
在斷點排查問題時，程式碼總會在不同的位置切換。但是，經常會遇到各種不是我們程式裡的程式碼跳出來。不過，只要我們把該檔案標記為Blockbox script
時，下次就不會再出現了。當然這只是最基本的操作，要想充分利用這個功能，還是要配合其它功能的使用。
Call Stack
呼叫棧在排查問題是很有用的，我們知道，函式的執行是有執行上下文的，函式由最外層到最內層依次壓入棧中，在執行的時候，依次從棧中彈出。這樣我們就可以從最內層沿著鏈找到最外層。
排查錯誤時也是這個道理，我們經常遇到不知名的錯誤:x:，可能是呼叫第三方的，也可能是底層，總之不是我們寫的程式碼（我信你個鬼:smirk:）。
遇到這種情況就可以嘗試用呼叫棧的方法，既然執行了，肯定是有呼叫的地方，我們可以沿著鏈去找源頭（十有八九是我們自己寫的程式碼:smirk:）。不過呼叫棧中可能混雜了不是我們自己寫的函式，這時候Blockbox script
就派上用場了。
Event Listener Breakpoints
可能在熟悉一個新的專案時，想知道某個 dom 繫結的處理事件。Blockbox script
頁簽下的Event Listener Breakpoints
可以定位到程式碼具體的位置，不過和上次一樣，好多其它程式碼混淆視聽，我們需要把他們標記為Blockbox script
。標記完後，下次就會直接在自己的程式碼裡停住了。
Initiator
其實和Event Listener Breakpoints
並排的XHR/fetch Breakpoints
也很有用，不過和接下來要講的功能比，就顯得雞肋了。
在 Network 頁籤中，記錄的都是請求的資料。在開發的時候常遇到這兩種情況，
1⃣️：介面報錯，在 Network 頁籤中可以看到整個URL被標紅了，要快速定位到呼叫介面的地方。
2⃣️：請求出去了，請看看響應時，如何處理資料。
其實，兩個實質上都是一樣，就是快速定位程式碼。快速定位在大型專案中還是挺麻煩的，除非業務比較熟，剩下只能全域性搜尋了。
還好，Network 頁簽下的Initiator
也有類似呼叫棧的東西，我們可以在其列表中找到，Blockbox script
的功能依然時遮蔽無關的程式碼。
補充
除了以上還有很多除錯技巧，
1⃣️：有時候我們看見了控制有錯誤:x:輸出，卻不知道是哪裡的問題。或者是控制有報錯:x:，但一閃而過，無法捕捉。這時候可以嘗試使用異常斷點的功能(最右:arrow_right:的那個)。倒數第二個，是用來恢復函式執行的，使斷點不起作用。
2⃣️：資料量過大時，可能由於某一條資料的問題導致了頁面渲染問題。如果打斷點的話，資料量太大了，每一次都跳到迴圈的處理邏輯中會很麻煩。不過斷點是支援條件斷點的，還可以列印我們想要的變數（在最新的 Chrome dev版本中，已單獨拎出來了）。
3⃣️：有時候頁面載入過快，都來不及看明白頁面是怎麼展示的。比如跳轉問題，比如模擬網速慢、電腦效能卡慢問題。（這裡十有八九是併發引起的競態問題:smirk:）右下角 Oneline 可自選模式。
4⃣️：......