1.項目初始化css
2.提高開發體驗html
3.整理項目和雜項node
4.項目打包react
5.團隊規範webpack
本章主要介紹的是創建在項目初始化的基礎上如何優化開發體驗 內容包含以下:git
sass
css module
sass
屬性sass
什麼是sass sass是一款css預處理語言,支持變量,嵌套,mixin和導入等功能,能夠極大地方便和簡化css寫法。es6
支持sass 支持sass首先須要安裝sass-loader
和node-sass
npm install -D node-sass sass-loader
另外還須要安裝style-loader
和css-loader
npm install -D style-loader css-loader
github
配置webpack 在這裏有一個點是須要注意的,由於將sass代碼編譯成可用的樣式代碼須要用到三個loader,因此就會產生順序問題,首先sass-loader
將sass代碼編譯爲css(默認使用node-sass
),而後css-loader
將編譯出來的代碼再次編譯成爲符合CommonJS的代碼,最後style-loader
將第二步編譯出來的代碼轉爲js代碼,而後webpack進行loader編譯的順序是從下到上的: 知道上面的順序後咱們在webpack中的配置就很是簡單了,直接在module.rules
下面加上.scss
文件類型的編譯配置便可: web
查看效果 這時候咱們在src下面新建一個index.scss
,而後在index.tsx
裏面引入這個文件查看效果 typescript
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
類型的轉換,那麼咱們就先對這兩個地方的轉換進行配置
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
類型,因此之後還須要根據須要進行添加。此外,在構建這方面的知識在後面的項目打包部分也是很是有用的。