幾乎所有構(gòu)建系統(tǒng)都選擇使用watch機制來解決開發(fā)過程中需要反復(fù)生成構(gòu)建后文件的問題，但在watch機制下，長期以來我們必須忍受修改完代碼，保存完代碼必須喝口茶才能刷新看看效果的問題。在這里我們嘗試探討為什么watch不是銀彈，并嘗試尋找一種更好的方案來解決這個問題。

watch基于的事實

當(dāng)一個文件修改，我們能知道其修改可能導(dǎo)致的文件修改，那么重新構(gòu)建這些文件即可。

通常對于文件A，構(gòu)建成文件B這種場景，這種對應(yīng)關(guān)系是極好確定的。但現(xiàn)實場景下，構(gòu)建過程往往不是那么簡單。例如：

文件A ＋ 文件B（被文件A引用） －> 文件C
在這種場景下，文件B的修改，可能難以定位哪些文件需要重新跑構(gòu)建任務(wù)，因為可能有很多文件引用了文件B。

除非我們建立一個依賴樹，并在每次文件更新的情況下更新依賴樹，并根據(jù)新的依賴樹觸發(fā)文件構(gòu)建。但這對每一個插件都需要自行實現(xiàn)這個機制，并且極易出錯。故實際上watch機制僅僅是重跑了整個task。所以當(dāng)項目越來越大的時候，watch機制將越來越慢（因為越來越多文件需要重新跑整個過程，即使通過緩存減少了整個過程所需的耗時）。

解決方案

src直接可用

AlloyTeam & @ldjking，簡單來說直接讓src直接可跑，把構(gòu)建任務(wù)放置在瀏覽器端，甚至根本不構(gòu)建，既可做到及時修改及時刷新，在開發(fā)過程中減少了時間消耗。線下構(gòu)建僅僅負責(zé)性能優(yōu)化上的問題，不負責(zé)開發(fā)效率。
典型代表有LESS、React等。但也有一些問題：

難以在瀏覽器端實現(xiàn)優(yōu)雅的構(gòu)建方式，難以提供強大的功能進一步減少開發(fā)成本，大部分只能采用類似<style type="text/less"></style>的方式引入腳本。
開發(fā)模式下的執(zhí)行順序不一定和實際場景相同，可能導(dǎo)致隱形bug出現(xiàn)，例如實現(xiàn)一個HTML inline由于開發(fā)模式下inline是異步的，而發(fā)布模式下inline時同步的，產(chǎn)生莫名其妙的bug。
瀏覽器編譯性能堪憂，例如js版的sass，編譯速度幾乎無法忍受。
需要維護線上、線下兩套構(gòu)建系統(tǒng)，增加了工具開發(fā)成本。
本地服務(wù)器動態(tài)構(gòu)建

一個事實是：在合理的規(guī)范支持下，我們可以從瀏覽器請求的文件，回溯到該文件構(gòu)建過程中的入口文件。這樣我們就可以動態(tài)觸發(fā)一次構(gòu)建過程。

通過在本地建立一個服務(wù)器，讓服務(wù)器捕獲請求后，在服務(wù)器中動態(tài)構(gòu)建。只要回溯到入口文件，我們便能將入口文件丟進gulp插件組成的管道中，則輸出便是瀏覽器需要的文件。

這樣我們就能解決上面的所有問題。

最新評論