用 vue-antd-admin 開發了一個專案後，我悟了
前言
前段時間公司要做 toB 營銷專案，因為各種原因，決定使用 vue-antd-admin 這個開源的前端解決方案，在那之前我聽說過 Ant Design Pro,應該是阿里內部團隊出的，vue-antd-admin 是它的 vue 仿版，其實還有個 Ant Design Pro Vue ，也是 一個 開源的 vue 仿版，這種整合方案可以快速提升業務開發效率，但是據我所知也有一些缺點：
一是這種專案考慮的場景比較全面，對一個具體的公司專案來說，卻顯得設計比較冗餘，在通讀文件後，可以較快的速度完成業務功能開發，但是是在它的框架內；定製化的需求是千變萬化的，這時候如果和它的設計理念不相符的話，就要做比較大的相容二次開發。
二是效能優化會很麻煩，也是因為太多冗餘設計，導致檔案量比較大，這和精簡的優化策略違背。
三是缺乏挑戰性，專案技術升級不太方便。
所以團隊要合理評估決定是否適合當前專案，對於當時我們這個專案來說還是比較合適的，我們團隊，產品、設計沒有過多幹擾，前端話語權還在，所以效率真的很快，而且它提供了一些很 cool 的效果和模組，跟自己重新開發比，能節省大量的時間，比如 配置 setting ,可以快速的修改專案佈局方式、主題色、多語言、動畫等，這些通常作為專案亮點的功能都被包含進去了。
這段時間以來，在使用vue-antd-admin 的過程中，有一些心得，雖然可能不是很大的坑，但是覺得還是值得記錄和分享一下的。
登入系統
官方用 js-cookie 來注入登入返回的 token 到請求 header 中，後端據此驗證；我們因為需要單點登入，使用統一的 cookie 注入，所以這個環節不需要。
單點登入（Single Sign On，SSO），即使用者通過登入一個應用系統，就可以訪問其他所有相互信任的應用系統，實現使用者單點多系統登入。
一般多用於企業內網各個獨立且互相信任的專案之間使用，有一個專門的登入系統用於各個業務系統的使用。
選單：icon的 渲染
選單提供了非同步和同步兩種載入方式，同步的就沒什麼說的，一般是 404 之類的頁面；業務功能頁面一般用非同步載入，通過介面獲取路由資料，結合本地 router.map.js 檔案，來生成最終的路由 json, 這裡注意：官方提到在 routes 的元資料屬性 meta 中注入了三個屬性 icon、invisible 和 page，它們將在生成選單和頁頭時發揮作用; 我發現它這裡的icon 是渲染到 Ant Design Vue 元件庫的icon 元件的type 屬性, 原始碼位置 在 menu/menu.js
``` return !icon || icon == 'none' ? null : h(Icon, { props: { type: icon } })
``` 元件庫提供的幾百個 icon 肯定無法滿足所有需求，一般都是自己公司的設計師設計的，這裡需要做一下改造，{ type: icon } 其實就是傳遞給 a-icon 元件 prop 的資料。
``` return !icon || icon == 'none' ? null : h(Icon, { props: { component: icon} })
``` 這裡我改用 component 屬性，根據官方的定義：component 控制如何渲染圖示，通常是一個渲染根標籤為
我這裡使用 component 將自定義的 svg icon 渲染到選單中; 在業務開發中，處處有這種需要修改源設計的地方，每個作者的思維邏輯不一樣，設計的架構也千差萬別，像這種巢狀蠻多層級的，需要梳理他的設計理念，找到那行最終渲染的函式。
最小畫素問題
記得在谷歌瀏覽器中，預設支援的最小畫素為 12px, 有些場景UI 提供的文字是 10px，該如何實現呢
下面提供幾種方案供思考：
1. 瀏覽器設定中是可以修改最小顯示的畫素的，設定 =》 外觀 =》 自定義字型 =》 最小字號，但是這不具有廣泛操作性，總不能讓使用者去操作吧。
2. 通過svg 圖片的形式，svg 在縮放時候不會影響清晰度。
3. 字型縮放，這是最推薦的，相容性也可以
.scale10px {
font-size: 12px
transform: scale(0.8);
transform-origin: left;
}
Drawer 、Select 元件的下拉選項錯位問題
這兩個元件的下拉選項和自身定位位置預設 會渲染到body 上，在默寫情況下選單滾動定位會出現異常，所以要修改其渲染的元素節點：
可以用 getContainer 和 getPopupContainer 屬性來進行配置。
主題定製
vue Antd Admin 提供了豐富的主題定製功能，像主題顏色、主題模式、導航佈局、動畫等 都是不缺的，這些‘亮點’功能讓專案看起來cool 了許多，我記得一個小插曲，本來我是準備在dev、sit 環境放開配置入口的，但是因為恩一個環境變數配置的 bug，導致第一次版本上線的時候被放開了，業務驗收的時候才發現，當時我挺緊張都準備好緊急再發一版了，然而業務和產品們都覺得這個功能很不錯，呃，竟然強烈要求保留。
不過後來和老大商量了，為了防止他們亂玩引起bug, 後來還是給分環境禁用了，開啟 setting.config.js 檔案，看到沒，那個 hideSetting 屬性，預設是 false ,只要線上環境改為 true 就好了。
``` //隱藏設定抽屜，true:隱藏，false:不隱藏 hideSetting: process.env.VUE_APP_ENV_NAME === 'prod' ? true : false
``` 也許你注意到了，VUE_APP_ENV_NAME 這個我自定義的變數就代表當前的執行時環境，那麼 這個變數是哪裡定義的呢，別急，關於環境變數我想再稍微詳細的講一下，請往後看。
環境變數
在瀏覽器中 window 代表全域性物件，而node 中的全域性物件叫global, process 就掛載在 global 下，所以它可以作為全域性使用，process 物件提供了有關當前 Node.js 程序的資訊並對其進行控制，前端開發中最常用的就是 process.env，這個屬性返回包含當前使用者環境的物件,當需要區分多個環境時候也會在 env中自定義全域性變數，比如需要區分不同環境的介面域名、埋點專案配置等。具體的配置方案：
vue-cli 腳手架
vue cli 腳手架提供了 ‘模式’ 這一概念，預設提供了 development、test、production，三個模式，這多數情況是不夠用的，我們可以通過傳遞 --mode 選項引數為命令列覆寫預設的模式。例如，如果你想要在構建命令中使用開發環境變數：
vue-cli-service build --mode development
當執行 vue-cli-service 命令時，所有的環境變數都從對應的環境檔案中載入(需要手動新建),你可以在你的專案根目錄中放置下列檔案來指定環境變數
.env # 在所有的環境中被載入
.env.local # 在所有的環境中被載入，但會被 git 忽略
.env.[mode] # 只在指定的模式中被載入
.env.[mode].local # 只在指定的模式中被載入，但會被 git 忽略
示例： package.json: ``` "serve": "vue-cli-service serve --mode=sit", 新增 .env.sit 檔案
內容為：
VUE_APP_CURRENT=sit
``
VUE_APP_CURRENT 就是我們定義的變數，請注意，只有 NODE_ENV，BASE_URL 和以 VUE_APP_ 開頭的變數將通過webpack.DefinePlugin` 靜態地嵌入到客戶端側的程式碼中。這是為了避免意外公開機器上可能具有相同名稱的私鑰。
通用方案 cross-env
如果沒有使用 vue-cli 或其他整合的腳手架，而是自己基於 webpack 搭建的專案，則是完全不同的寫法，首先介紹下 cross-env, 這是為了統一多個平臺中使用環境變數的語法差異而產生的 npm 工具，比如在window 平臺，直接 NODE_ENV=production 是不生效的，而 macOs 可以 ；它可以抹除這種差異，給不同平臺使用者統一的操作體驗。
我最初建立它是為了解決我在 angular-formly中使用 npm 指令碼時遇到的問題。這使得 Windows 使用者更容易為專案做出貢獻。 摘自：http://www.npmjs.com/package/cross-env
其使用也是很簡單的，首先 安裝到專案裡，
npm install --save-dev cross-env
在package.json 的 script 指令碼中這樣使用：
"build:sit": "cross-env CDN_ENV=sit vue-cli-service build"
通過上面指令，已將自定義的 CDN_ENV 變數配置到 process.env 物件裡 了，但是在執行時環境還不能訪問，為了在執行時環境中訪問需要 CDN_ENV 變數，則還需要進一步配置：
``` 1. 若是 vue-cli 則 在vue.config.js 檔案下
chainWebpack: config => { config.plugin('define').tap(args => { args[0]['process.env'].CDN_ENV = JSON.stringify(process.env.CDN_ENV) return args }) }
其實vue-cli 就不建議用 cross-env 了，直接用官方封裝的方案。
- 若純 webpack 專案則 plugins：[ new webpack.DefinePlugin({ NODE_ENV: JSON.stringify(process.env.CDN_ENV), }) ]
```
通過以上方式，在任意 .vue 或者 .js 檔案中 通過 process.env 就可訪問到包含 CDN_ENV 在內的所有自定義變數物件了。
在這裡，說一下 definePlugin 這個外掛，它的作用是在編譯時候將你程式碼中的自定義變數替換為其他值或表示式，上面的示例中也就是替換成了 process.env.CDN_ENV 的值，所以在訪問前的編譯階段 CDN_ENV 變數已經被修改替換了。
總結
在用 vue-antd-admin 開發業務專案的這段時間，總體上體驗是不錯的，有很多省心的地方（哈欠），像一些常用的元件如 search、table 、keep-alive 快取多頁籤頁面，主題配置等，節省了我們很多時間，並且學習了作者的架構思路。
不過有充足的時間和人員儲備的前提下，還是建議自己搭建架構，成就感和收穫會更多。
謝謝觀看，下篇準備寫寫前端埋點，主要是神策的方案實踐，敬請期待。