自建vue組件 air-ui (1) -- 爲啥我要自建一個類 element ui 的組件

時間 2020-01-21

標籤自建 vue 組件 air 爲啥一個 element 简体版

原文原文鏈接

前言

最近的一個月大部分時間都在忙這個事情，就是以 element ui 爲基礎，作一個屬於咱們本身的 vue 組件庫，而且擴展。如今已經完成了。而且已經成功替換原項目裏面的 element ui 組件，而且開始要編寫其餘的 element ui 組件沒有的組件。css

效果以下

幾個效果以下： wiki 文檔截圖以下：vue

由於要完整兼容咱們以前用的 element ui 組件，因此這個 air-ui 的組件列表也會跟 element ui 的組件同樣。如下是存放全部組件的效果圖，這個頁面也是咱們後面作主題自定義的時候的對比頁面，存放了全部組件的 demo 的實例：git

爲啥要這麼作

首先不能否認的是， element ui 組件真的寫的很是好了。早期的項目用它徹底沒有問題。可是隨着項目的規模愈來愈大，漸漸暴露了如下幾個問題：程序員

有些組件 element ui 沒有，咱們得本身封裝到咱們的項目。好比如下這幾個組件：vue-cli
1. 圖片裁剪組件 (圖像根據比例裁剪，可指定分辨率裁剪)
1. 圖片拖動上傳popover
1. 文字內容與顏色popover
有些組件用 element ui 的，可是有些屬性咱們想要，可是沒有，好比如下這個顏色選擇器npm

咱們以前是基於 element ui 的 color-picker 又作了從新封裝和擴展，增長了左下角顏色預覽顯示，增長了隱藏時候emit事件。才知足咱們的業務需求。element-ui

主題方面，element ui 他有本身的主題定製，這一點很是棒，可是在使用過程當中，咱們發現可定製點仍是少了，或者說有些定製我只但願在 button 組件上應用，結果它這個參數直接應用到全部組件上，這不是我想要的。固然這也不能怪它，畢竟它已經能知足絕大部分 vue 項目的 ui 組件需求。可是比較遺憾，隨着咱們的項目規模愈來愈大，主題定製方面要求愈來愈細，element ui 已經知足不了了，咱們只能在項目裏面，針對 element ui 對應組件的 css 樣式進行重寫來達到咱們的目的，可是這樣子很是的被動

基於以上幾個緣由，咱們萌生出了要基於現有的 element ui 的基礎上，從新定製了咱們本身的 ui 組件，纔有瞭如今的 air-ui。app

air-ui 的優勢

通過我一個月左右的吭哧吭哧的開發，air-ui 總算完成了。固然中間有不少的代碼幾乎徹底借鑑了 element ui，包括絕大部分組件的邏輯，css 樣式，util 方式，甚至包括 demo，幾乎所有借鑑了 element ui 裏面的代碼，由於就像以前說的，element ui 現有的組件真的寫的很是好了，不太須要我去作太多的修改，只要移植過來就好了，我不可能爲了表現出本身特立獨行很牛逼，所有都要本身寫，必定要跟別人不同，結果本身累的要死要死的，結果尚未人家寫的好。事實上要不是大量的組件業務邏輯，樣式，demo 都借鑑 element ui 組件，我也不可能在一個月把這個搞定，固然若是所有都抄 element ui 的，那就真的沒意思，也就不會有這個系列了。事實上在經過讀取 element ui 項目源碼的過程當中，仍是發現了一些我以爲作的不那麼好的地方，而 air-ui 能夠優化的。好比如下幾點：gitlab

目錄結構，element ui 的目錄結構其實比較亂，多是比較早期的項目吧，那時候尚未用 vue-cli 的目錄結構，而 air-ui 就是基於 vue-cli 的目錄結構來建立，能夠說目錄結構一看便知。
文檔方面，element ui 的文檔其實作的還不錯，說白了就是這個站點 element.eleme.io/ ，可是咱們不須要咱們的文檔也寫的這麼複雜，並且在讀源碼的過程當中，我也以爲這個文檔的項目也很複雜，而 air-ui 是基於 vuepress, 能夠實現跟 element.eleme.io 差很少的效果，可是複雜程度就不多。
引用路徑問題，經過看源碼，我發現 element ui 文檔組件和方法的引用，有時候用相對路徑，有時候用絕對路徑引用，固然這個是有緣由的，並且我也知道爲啥它要這麼作，這一點後面我會提到，可是在作 air-ui 的時候，我把這一點合理的避免了，全部的路徑引用所有用相對路徑就能夠了。從可讀性來看，會比 element ui 來的好。
主題定製方面，既然以前是由於主題定製不夠給力，纔想要新寫一個ui組件的，因此主題定製方法也跟 element ui 有點差異，更適合咱們項目。這一點後面也會說道。
多語言方面，多語言確定是必須的，可是在多語言的處理上，air-ui 也有進行了一些優化，會比 element ui 的結構更好。

固然除了以上幾點，還會有一些小的優化，好比 eslint，構建方面等等，後面都會提到。post

air-ui 的引入方式

首先要說明的一點就是 air-ui 並無開源，因此 npmjs 上面的那個 air-ui 不是我作的這個：另外一個 air-ui。

完整來講，air-ui的引入方式其實有 3 個:

1.完整引入

在main.js文件下添加以下配置:

import Vue from 'vue';
import AirUI from 'air-ui'
import 'air-ui/lib/styles/index.css'
import App from './App.vue';

Vue.use(AirUI);

new Vue({
  render: h => h(App)
}).$mount('#app');
複製代碼

以上代碼便完成了 air-ui 的引入。須要注意的是，樣式文件須要單獨引入。

2.部分引入(可是所有加載)

若是你只但願引入部分組件，好比 Button 和 Row，那麼須要在 main.js 中寫入如下內容：

import Vue from 'vue';
import { Button, Row } from 'air-ui';
import 'air-ui/lib/styles/index.css'
import App from './App.vue';

Vue.use(Button)
Vue.use(Row)

new Vue({
  el: '#app',
  render: h => h(App)
});
複製代碼

3.部分組件按需加載

或者你也能夠直接引用單獨組件的 js 和 css：

import Vue from 'vue';
import Button from 'air-ui/lib/button';
import Row from 'air-ui/lib/row';
import 'air-ui/lib/styles/button.css';
import 'air-ui/lib/styles/row.css';
import App from './App.vue';

Vue.use(Button);
Vue.use(Row);

new Vue({
  el: '#app',
  render: h => h(App)
});
複製代碼

第二種和第一種其實沒啥差異，都是所有加載 air-ui.common.js, 不會省打包體積。只能算第一種的另外一種語法糖的變種。爲啥跟 element-ui 的按需加載不同，具體能夠看 {% post_link air-ui-8 %}

第三種纔是真正能夠省打包體積的方式。

暫不開源

目前 air-ui 是放在公司搭建私有的 gitlab 代碼庫的，並無開源，一方面是由於新加的一些組件和新的定製主題都含有公司產品的特色，對其餘人來講，並無太多可借鑑的東西，另外一方面也是大部分的組件都是從 element ui 那邊挪過來的，對於其餘人來講，直接用 element ui 效果更好。

固然這套組件也只是適用於 pc 端，不適合移動端，由於咱們如今的大部分站點項目都是用於 pc 端的。因此並無專門去開發移動端的 ui 組件。由於市面上的第三方的移動端的 vue ui 組件已經夠用了，沒有必要幹啥都要重造車輪。

寫 blog 的初衷

接下來就圍繞着我是怎麼開發 air-ui 組件的，給你們講講個人思路和遇到的一些坑，甚至有些坑到如今都尚未完美的解決。事實上我寫得很是細，甚至都有點囉嗦了，再加上不少篇，每一篇的篇幅也很多，因此估計加起來均可以寫成一本書了，哈哈。固然之因此寫的比較細的緣由，也是由於我想把那段時間的思考，入坑，爬坑的過程都寫清楚，畢竟每一次入坑到爬坑的過程都是一次寶貴的經驗。畢竟對於程序員來講，解決問題的能力纔是最重要的。

事實上之因此寫這個系列是由於網上雖然有一些怎麼教人寫 ui 組件的教程，可是都是淺嘗而止，作出來的東西根本沒有辦法達到大型線上項目能夠用的地步，這也致使我幾乎是啃着 element ui 源碼來重寫air-ui 組件的，雖然中間也借鑑了其餘的一些成熟的開源 ui 項目的方式，可是大部分仍是借鑑 element ui。

而寫這個系列文章的緣由，也是由於我以爲一旦項目到了一個規模，單獨的第三方 ui 組件絕對是知足不了的，爲了更好的維護和擴展，不少時候每每須要本身再建一套更符合本身項目風格和規範的 ui 組件。那時候但願這些文章能對這羣人達到一些幫助，少走點彎路，奧利給~~~。

系列文章: