實用卻易忽視的DevTools調試技巧

Chrome DevTools 調試使用 demo地址

做爲前端開發者，免不了要和 DevTools 打交道,熟練的使用 DevTools 可以大大提升咱們的工做效率。然而，開發者工具的使用並無獲得足夠的重視。

工欲善其事必先利其器，更況且，工具的學習成本比專業技能的學習成本小的多。

Chrome 有不一樣版本，若是想第一時間體驗一些新的功能可使用除穩定版本的其它版本。

本次主要圍繞着 Workspace 和 Blockbox script 這兩點來感覺它們帶來的便利。

Workspace

Workspace 主要仍是將瀏覽器關聯本地文件，使得瀏覽器擁有讀寫本地文件的權利。

隨着前端的發展，業務和邏輯也愈來愈複雜。還好打包壓縮工具應運而生，還有 sourceMap 的使用，又讓咱們從壓縮混淆的代碼中有了看源碼的體驗。

此時咱們依然能夠 DevTools 裏 Sources 頁籤裏的 Filesystem 頁籤添加本地文件夾，從瀏覽器裏修改本地文件。

這個功能或許還有點用，可是仍是不如人意。由於修改後的文件須要刷新後才能顯示變更，而文件被更改後，打包工具須要從新編譯，編譯時間或許很長或許很短，並且頁面被被總體刷新了，給人一種很生硬的感受。

不過，還好有 熱組件替換 這麼一說。給咱們的應用程序加上這貨以後，咱們的開發將會更加絲滑😉。

熱組件替換

以 create-react-app 爲例🌰（最新版本），步驟以下。也能夠看看👀官方怎麼說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)
        })
    }

至此，熱組件替換改造完成，讓咱們再次感覺下。

經過以上展現，咱們能夠發現，整個界面只是局部被替換了，過渡得很天然。這應該纔是咱們想要的效果✨。插一句，在 Network 頁籤中，Preserve log 必定要勾選上☑️。這樣的話，即便頁面刷新了，也是有記錄📝的，很是方便在頁面跳轉刷新時使用。

Blockbox script

若是說以上是提升了開發上的效率，那麼這個 Blockbox script 功能將會在定位上省下很多時間。

在斷點排查問題時，代碼總會在不一樣的位置切換。可是，常常會遇到各類不是咱們程序裏的代碼跳出來。不過，只要咱們把該文件標記爲 Blockbox script 時，下次就不會再出現了。固然這只是最基本的操做，要想充分利用這個功能，仍是要配合其它功能的使用。

Call Stack

調用棧在排查問題是頗有用的，咱們知道，函數的執行是有執行上下文的，函數由最外層到最內層依次壓入棧中，在執行的時候，依次從棧中彈出。這樣咱們就能夠從最內層沿着鏈找到最外層。

排查錯誤時也是這個道理，咱們常常遇到不知名的錯誤❌，多是調用第三方的，也多是底層，總之不是咱們寫的代碼（我信你個鬼😏）。

遇到這種狀況就能夠嘗試用調用棧的方法，既然執行了，確定是有調用的地方，咱們能夠沿着鏈去找源頭（十有八九是咱們本身寫的代碼😏）。不過調用棧中可能混雜了不是咱們本身寫的函數，這時候 Blockbox script 就派上用場了。

Event Listener Breakpoints

可能在熟悉一個新的項目時，想知道某個 dom 綁定的處理事件。Sources 頁簽下的 Event Listener Breakpoints 能夠定位到代碼具體的位置，不過和上次同樣，好多其它代碼混淆視聽，咱們須要把它們標記爲 Blockbox script。標記完後，下次就會直接在本身的代碼裏停住了。

Initiator

其實和 Event Listener Breakpoints 並排的 XHR/fetch Breakpoints 也頗有用，不過和接下來要講的功能比，就顯得雞肋了。

在 Network 頁籤中，記錄的都是請求的數據。在開發的時候常遇到這兩種狀況，
1⃣️：接口報錯，在 Network 頁籤中能夠看到整個URL被標紅了，要快速定位到調用接口的地方。
2⃣️：請求出去了，請看看響應時，如何處理數據。

其實，兩個實質上都是同樣，就是快速定位代碼。快速定位在大型項目中仍是挺麻煩的，除非業務比較熟，剩下只能全局搜索了。

還好，Network 頁簽下的 Initiator 也有相似調用棧的東西，咱們能夠在其列表中找到，Blockbox script 的功能依然時屏蔽無關的代碼。

補充

除了以上還有不少調試技巧，

1⃣️：有時候咱們看見了控制有錯誤❌輸出，殊不知道是哪裏的問題。或者是控制有報錯❌，但一閃而過，沒法捕捉。這時候能夠嘗試使用異常斷點的功能(最右➡️的那個)。倒數第二個，是用來恢復函數執行的，使斷點不起做用。

2⃣️：數據量過大時，可能因爲某一條數據的問題致使了頁面渲染問題。若是打斷點的話，數據量太大了，每一次都跳到循環的處理邏輯中會很麻煩。不過斷點是支持條件斷點的，還能夠打印咱們想要的變量（在最新的 Chrome dev版本中，已單獨拎出來了）。

3⃣️：有時候頁面加載過快，都來不及看明白頁面是怎麼展現的。好比跳轉問題，好比模擬網速慢、電腦性能卡慢問題。（這裏十有八九是併發引發的競態問題😏）右下角 Oneline 可自選模式。

4⃣️：......