自建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 组件。那时候但愿这些文章能对这群人达到一些帮助，少走点弯路，奥利给~~~。

系列文章: