微信小程序自定义组件化UI框架开发尝试！

说起小程序的UI框架，目前流行的有很多：

• 官方WeUI——https://github.com/Tencent/weui-wxss
• iView  ——https://github.com/TalkingData/iview-weapp
• ColorUI ——https://github.com/weilanwl/ColorUI
• TaroUI ——https://github.com/NervJS/taro-ui
• MinUI ——https://github.com/meili/min-cli
• Vant——https://github.com/youzan/vant-weapp
• ......

可以说是“百花争鸣”吧，用起来都很不错，上手过iView、ColorUI、WeUI，算了不提官方的，都各有所长。但是，很多功能组件我们用不到，按需引入还好一些，对于全局引入的，特别占内存，而且有时间兼容起来恨不得自己重新写一个，所以对于一个新项目，我考虑再三，决定根据小程序功能自己造一个“UI”组件库。

为什么“闭门造轮子”？

公司的小程序要改版升级，想起来公司接收的小程序，技术经理用的是 ColorUI组件库：http://demo.color-ui.com/ ，组件很丝滑，但是需要引入整个组件。然后页面堆积很多的css样式，代码重复利用率很低，几乎每个列表都需要重新兼容一遍，导致最后小程序的体积很“臃肿”，最后都不能称为小程序了。

给大家看一组数据：
1.老版本共2.5M大小，当然还做了分包处理，同时将不用的页面剥离出项目，带上溢出的文件和页面，大致3M左右，共用了85个页面。

2.新版本，到目前为止共用了72个页面，当然商城部分和分销部分还没有做，共808KB。而且没有做分包处理，我只是将全部的图片和图标也做了优化，变成了线上地址；html和css尽量重复使用，提高了组件的使用率，首页的布局，在其他地方都可以用，共同样式在app.wxss里面。

所以在升级的时候，我突发奇想，网上的UI框架要么全局引入瞬间占好几百K的空间；有的样式布局不适用，还需要手动兼容；更有一些部分还收费......作为一个优秀的前端开发者，不服就是要干，因此：我，我，独立自定义DIY定制了一套UI框架。

自定义UI框架的“诞生”背景就这样产生了，Q.A.Q

关于命名，很多基础样式和布局样式，都是基于之前的QUI的，当然小程序公共样式表中也有她的影子，我觉得还是称之为“QUI小程序版”更为准确。

QUI小程序框架都有哪些组件？

到目前为止，一共更新了 字体组件、图片和头像组件、按钮组件、布局组件以及状态栏和导航栏。

• 字体组件，允许自定义字体大小、字重、颜色、对齐方式、多行隐藏。
• 图片和头像组件，image的mode属性固定为widthFix，允许自定义图片类型：图片（img）/头像（ava）、大小以及圆角。
• 按钮组件，允许自定义不同类型按钮：标签式、描边、渐变、填充色等类型以及按钮大小、是否选中、是否禁用。
• 布局组件row，允许自定义盒子渲染规则类型：BFC块级格式化（浮动布局）、flex弹性布局以及grid网格布局。
• 布局组件span，允许自定义盒子宽度，默认允许2等分、3等分...5等分，允许修改盒子对齐方式：左对齐和右对齐。
• 导航栏组件，允许自定义状态栏，默认有带“返回”状态栏、带“搜索”的、自定义状态栏等等以及状态栏可固定头部，可传递参数等常用功能。
• 状态栏组件，允许自定义状态栏，弥补了小程序自带状态栏不能修改的缺陷，可通过组件自定义。

ui组件大小共38kb，后续功能有待补充：Tab切换、弹框模拟态、上传组件等，当然在实际开发中还有一些功能都没有封装，直接样式实现了，嘻嘻~

存在的问题

从刚开始打造这个UI就知道，后期会一直优化补充她的功能，果不其然，在具体使用的过程中，也在不断扩展其功能。

例如：字体组件中颜色、头像组件大小太少了、导航栏功能补充、布局只能用等比分割的......

由于外部修改组件相当麻烦，所以只能不断扩展组件去适应新的属性功能，当一个小程序开发完毕的时候，这个组件也就组建成熟了。目前的话，自己用来做项目最为合适，自己开发的组件ui，想怎么改怎么改，还是很任性的！

关于兼容性

小程序不兼容grid网格布局，我也仅仅引入，并未使用，还有一点：组件里面不能用CSS3伪元素和后代选择器等属性，给布局造成不小的麻烦，因此只默认添加了等比等宽的布局，带间隔的组件还是很难解决的，除非外部样式可以控制组件内的样式，但是又会造成组件和正常样式冲突——命名冲突、样式冲突。So，只能......
真机上，大问题没有，满足当前小程序的需求，配合弹性布局flex，造页面真的快。