搭建Typescript+React專案模板(2) --- 提升開發體驗

YDJFE發表於2018-09-27

TypeScriptReact

專案地址

前言

本章主要介紹的是建立在專案初始化的基礎上如何優化開發體驗內容包含如下:

支援sass
支援css module
配置公用的sass屬性
支援裝飾器
路徑優化
構建快取
構建加速

支援`sass`

什麼是sass sass是一款css預處理語言，支援變數，巢狀，mixin和匯入等功能，可以極大地方便和簡化css寫法。
支援sass 支援sass首先需要安裝sass-loader和node-sass npm install -D node-sass sass-loader 另外還需要安裝style-loader和css-loader npm install -D style-loader css-loader
配置webpack 在這裡有一個點是需要注意的，因為將sass程式碼編譯成可用的樣式程式碼需要用到三個loader，所以就會產生順序問題，首先sass-loader將sass程式碼編譯為css(預設使用node-sass)，然後css-loader將編譯出來的程式碼再次編譯成為符合CommonJS的程式碼，最後style-loader將第二步編譯出來的程式碼轉為js程式碼，然後webpack進行loader編譯的順序是從下到上的: 知道上面的順序後我們在webpack中的配置就非常簡單了，直接在module.rules下面加上.scss檔案型別的編譯配置即可:
檢視效果這時候我們在src下面新建一個index.scss，然後在index.tsx裡面引入這個檔案檢視效果

效果如圖:

支援`css module`

什麼是css module css module是針對css類名作用域做出限定的一種規範，用以解決css類名衝突的問題，此外還能避免一些爬蟲進行資料爬取(當然厲害的爬蟲除外)，同等的還有BEM規範。
安裝對應的包因為在這裡我們用的是TypeScript，所以可以用typings-for-css-modules-loader這個包，這個包也可以替代css-loader的功能，此外這個包還能根據.scss檔案裡面的類名自動生成對應的.d.ts檔案: npm install -D typings-for-css-modules-loader
配置webpack 這個配置接非常簡單了，因為要用typings-for-css-modules-loader替代css-loader的功能，所以直接替換即可，將前面sass的配置修改為如下:
使用和問題這個時候我們將index.tsx檔案修改為如下:
修改為這樣既可，但是同時我們也發現一個問題:
這個問題導致的原因是因為.scss檔案中並沒有類似export這樣的關鍵詞用於匯出一個模組，所以也就導致報錯找不到模組，這個問題可以通過ts的模組宣告(declare module)來解決。
解決模組宣告問題這時候我們在根目錄下新建一個typings資料夾，用於存放.scss的模組宣告，以及後續需要用到的全域性校驗介面，然後新建typed-css-modules.d.ts檔案用於存放.scss模組宣告，目錄結構和宣告內容如下:
效果這個時候回到index.tsx檔案中你會發現錯誤標紅消失了，然後我們在index.scss檔案中新增如下程式碼
儲存後你會發現當前目錄下新增了一個index.scss.d.ts檔案，開啟裡面可以發現是針對每個類名的型別校驗，當以後新增類名的時候，typed-css-modules.d.ts都會自動在index.scss.d.ts裡面新增對應的型別校驗:
這時候回到頁面檢視，你會發現類名變成了一個hash值，這樣可以有效地避免類名全域性汙染問題:

配置公共`sass`屬性

既然已經可以使用sass進行更加簡便的css程式碼編寫，那麼我們也可以將常用的一些樣式程式碼和sass變數寫入公共檔案中，當使用的時候就可以直接引入使用，這可以提高一定的效率節約時間:

新建公共樣式目錄首先在src目錄下新建styles資料夾，然後在styles資料夾下新建var.scss檔案用於存放樣式變數。之後在var.scss檔案裡寫入一個顏色變數和一個樣式:
檢視效果然後在index.scss檔案裡面引入var.scss，接著就可以直接使用裡面的變數了：
效果:
優化上面的效果其實已經達成，但還是存在一個不好的問題，就是在引入var.scss的路徑上要根據每個資料夾的路徑相對來引入非常麻煩，那麼我們能否做到只需要@import var.scss就行呢？答案是可以的，我們可以使用一個node-sass的屬性includePaths進行路徑優化:

支援裝飾器

前置工作在src目錄下新建一個components資料夾，用於存放通用元件，然後在components檔案及裡面新建一個元件Test，然後在網頁入口引入這個元件，如下圖所示:
什麼是裝飾器，為什麼需要裝飾器裝飾器本質上就是一個函式，這個函式對類(class)本身進行一些處理，也可以將裝飾器的寫法當做一種語法糖，如果不用裝飾器的話，可以寫成下圖這樣：
但是如果裝飾器多的話就會變成如下樣子:
這樣會導致程式碼非常難以理解，於是裝飾器就登上舞臺了。這在今後使用了mobx(or redux)的時候也是非常有用的。
設定裝飾器可用根據裝飾器的語法，我們可以將上面的程式碼寫成如下:
但是你會發現這裡報了一個錯誤，這是因為裝飾器語法在es6標準中還只是一個提案，並未正式支援，但是在ts中，裝飾器已經被正式支援了，不用ts的可以自行安裝babel相關包進行支援。
那麼怎麼解決這個錯誤呢？我們根據錯誤提示進入到tsconfig檔案中，將experimentalDecorators設定為true即可，然後回到頁面檢視log裝飾器已經生效了:

優化路徑

為什麼在上面的例子中我們新建了components資料夾，然後在入口處引入了其中的Test元件
但是這時候需要考慮到一個問題，如果以後在一個層級比較深的檔案中引入這個元件會不會產生如下這種情況呢?

import Test from '../../../../components/Test'
複製程式碼

這樣不僅書寫起來麻煩還容易出錯，因此這時候就需要進行一些路徑上的優化，使得無論在哪個地方引入這些元件都能用同一種寫法，例如:

import Test from '@comonents/Test'
複製程式碼

路徑優化這裡針對路徑的優化有兩種方案，第一種是直接在webpack.resolve.alias中進行路徑配置:
但是在這裡我們使用了ts，所以還需要在tsconfig中進行配置:
這樣也能用，不過我們還可以用tsconfig-paths-webpack-plugin這個包將tsconfig中對路徑的設定對映到webpack配置中去，這樣就不需要在webpack中再進行一次路徑的配置了，首先安裝: npm install -D tsconfig-paths-webpack-plugin 然後就採用前面tsconfig裡面對baseUrl和paths的配置。之後進入webpack配置中，引入tsconfig-paths-webpack-plugin
接著在webpack.resolve中新增配置項plugins(這裡要注意的是新增的不是webpack.plugins，而是webpack.resolve.plugins)，配置如下程式碼:
接著我們就可以愉快地使用簡化後的路徑了：

構建快取

什麼是構建快取我們一般會使用webpack-dev-server來進行專案開發，當我們執行webpack-dev-server的時候它會在記憶體中進行專案的構建，但是當使用了babel之類的程式碼轉換工具後，會對專案構建產生較大的效能影響，這是因為每一次的構建都會對程式碼進行重新轉換。而構建快取就是將構建的公用程式碼快取在磁碟上，這樣做的效果就是第一次構建的時間花銷會比不用快取的構建大，但是在之後每次構建的時間花銷都會大大減少。
對比我們拿一個較大的專案來看區別。注: 左邊是沒有設定構建快取，右邊進行了構建快取。首先進行對比的是第一次構建時候的時間花銷:
然後是第二次構建的時間花銷:
可以看出在第二次構建的時候時間花銷減少了百分之五十以上。
設定構建快取在設定構建快取之前我們首先要考慮的是那些地方需要進行設定，那麼在前面的配置過程中，可以看出花銷較大的地方有對ts(x)的轉換並且以後還會新增對應的babel進去，然後還有針對sass型別的轉換，那麼我們就先對這兩個地方的轉換進行配置

對ts(x)的轉換這裡因為我們使用的是awesome-typescript-loader，這個庫本身自帶了開啟快取的選項useCache，然後我們需要指定一個儲存快取檔案的地方cacheDirectory，所以配置改為如下:
對sass型別的轉換這個地方我們需要使用到一個庫cache-loader npm install -D cache-loader, 然後在對.scss檔案型別的轉換配置中使用它，在這裡我們主要是針對轉換出來的css進行快取，所以需要寫在typings-for-css-modules-loader配置的前面:
這樣就配置好當前的構建快取了，當你npm run dev的時候會發現根目錄下生成了快取檔案.cache-loader。
開啟它看會發現有對應的快取程式碼:
不過現在只是根據目前需要進行的快取配置，當後面整合antd等相關庫的時候因為需要使用到less型別，所以以後還需要根據需要進行新增。