小程序对组件化的“支持”情况微信小程序(以下简称“小程序”,版本)虽然默认定义了很多有用的组件,但是在开发小程序过程中,往往需要自定义业务组件。而小程序开发者文档中却未对自定义组件给出很好的解决方案或 ...
微信小程序(以下简称“小程序”,版本)虽然默认定义了很多有用的组件,但是在开发小程序过程中,往往需要自定义业务组件。
而小程序开发者文档中却未对自定义组件给出很好的解决方案或示例。
猜其原因可能有两方面:
微信的组件化,总体而言,目标就是把具有特定功能和样式的wxml、wxss、js(可选)文件抽取出来,以便不同页面之间进行复用。
我们从实现上来考虑是否可行:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
// tab component - |- tab.wxml |- tab.js |- tab.wxss // tab.wxss .tab { ... } .tab .itme { ... } ... |
因为我们采用了include的方式共享了作用域,在简单页面的情况这种方式也不会出现什么问题,如果变量名或事件名被占用的时候换一个就好了。
但是在页面引用多个组件的情况下如何保证它们之间不产生冲突?你可能想到了用老办法命名隔离,组件内部变量和事件添加组件前缀用来和其它组件区分。
OK,在组件名不重复的情况下这是可行的。但是如果一个组件要同时触发自身内部事件和父页面事件就不是这么简单了。
所以我们需要解决的一个关键问题是:组件如何隔离作用域,并暴露属性或接口(函数)给页面或其它组件?
我们在探索组件化实现方式时,有一个第三方模块wepy脱颖而出。star数量超过了1k,文档清晰简约。
看看它的主要功能:
MVVM多用于web单页应用,而小程序明显不是单页应用,而且也不支持双数据绑定,转为MVVM方式更多只是习惯上的喜好,谈不上什么优点。
小程序也支持ES6特性(以前也支持ES7,不知道为什么新版本取消了),用ES6特性可以完成外部NPM包引用。
所以最吸引人的功能就是第二点:支持组件化。
拿到官方给的示例wepy-wechat-demo编译后对比源码和编译后的代码来探究其实现组件化的思路。
整个项目非常清晰简单,我们以index页面调用tab组件为例进行分析。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
// src目录 - |- components - tab.wpy ... |- pages - index.wpy ... // dist目录 - dist |- components - tab.wxss - tab.js |- pages - index.js - index.json - index.wxml - index.wxss |
js文件用ES6编写,通过babel转成ES5形式,看起来比较费劲,不过幸好我们暂时也不需要分析它。打开index.wxss和tab.wxss可以看到组件样式的编写和引用方式如我们所料,通过微信的@import方式引入。
1 2 3 4 5 6 7 8 9 10 11 12 |
// dist/components/tab.wxss .tab { ... } .tab .item { ... } ... // dist/pages/index.wxss @import "./../components/tab.wxss"; ... |
很奇怪,在编译好的components文件夹中只能看到组件命名的js和wxss文件,wxml文件消失了~
所以先来看看index.wxml中怎么体现的
这段编译后的代码和tab.wxml源文件基本一致,发生改变的是数据绑定和事件绑定的地方,进行了重命名。
由此可以推断,是通过wepy的编译工具wepy-cli,把页面上的组件引用替换成了源码并通过修改变命名来隔离组件作用域避免冲突。
而这些重新修改的变量和事件如何起作用?
wepy的文档中提到组件支持回调和事件冒泡、事件下发,要支持这个特性除了按其要求的格式进行编写之外,还需要在js中引用一个叫wepy的模块,如
import wepy from 'wepy'
由此可以推断,wepy-cli编译的时候进行了模板替换和变量名(事件名)替换,然后wepy模块来处理替换后的事件调用以及组件之间的通信。
如果仔细翻阅文档会发现其对组件的支持非常接近Vue.js 2.x,比如computed、watcher属性。行文此处,给作者由衷地点个赞。
那么这种方式是否就是最理想的组件化方式,或者说这种方式有什么缺陷呢?