微信小程序-组件化开发(上)

小程序对组件化的“支持”状况小程序对组件化的“支持”状况:css

微信小程序(如下简称“小程序”,版本)虽然默认定义了不少有用的组件,可是在开发小程序过程当中,每每须要自定义业务组件。
而小程序开发者文档中却未对自定义组件给出很好的解决方案或示例。

猜其缘由可能有两方面:web

  1. 从小程序开放的API来看,它去除了DOM和BOM,视图与数据层交互采用简单的单向数据绑定和事件绑的形式。可能其初衷是想下降开发难度和学习门槛,尽可能减小概念。
  2. 小程序推出时间不到一年,这些功能可能还在完善中。

自定义组件的难点

微信的组件化,整体而言,目标就是把具备特定功能和样式的wxml、wxss、js(可选)文件抽取出来,以便不一样页面之间进行复用。
咱们从实现上来考虑是否可行:json

  • wxss支持文件之间的引用,采用命名隔离的话应该能够支持组件化的需求。即把不一样组件拆成不一样的wxss,经过一致的命名与组件的试图、逻辑对应,同时组件样式选择器都挂载在跟样式下。使用时记得引用该wxss就好。固然预编译语言中所使用的变量、函数什么的就不要想了~
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 {
    ...
}
...
  • wxml也支持引用,两种方式:template和include。区别在于做用域。include至关于把代码拷贝到当前位置,与页面共享做用域,而import拥有本身的独立做用于,通常须要传入对应的参数。这么看彷佛template更适合,但是template的事件绑定却还是和父页面共享做用域,也就是说数据在template独立做用域中,事件绑定在页面内做用域,二者之间的相互引用就会变得至关尴尬,还不如include顺畅。
  • 小程序支持ES6,因此咱们能够用ES6的模块管理方式来引入对应的js文件。
  • 由于json是针对于页面进行的配置,组件关心的是局部样式和逻辑,因此组件化的时候咱们并不须要它。

由于咱们采用了include的方式共享了做用域,在简单页面的状况这种方式也不会出现什么问题,若是变量名或事件名被占用的时候换一个就行了。
可是在页面引用多个组件的状况下如何保证它们之间不产生冲突?你可能想到了用老办法命名隔离,组件内部变量和事件添加组件前缀用来和其它组件区分。
OK,在组件名不重复的状况下这是可行的。可是若是一个组件要同时触发自身内部事件和父页面事件就不是这么简单了。
因此咱们须要解决的一个关键问题是:组件如何隔离做用域,并暴露属性或接口(函数)给页面或其它组件?小程序

组件化解决方案

第三方实现

咱们在探索组件化实现方式时,有一个第三方模块wepy脱颖而出。star数量超过了1k,文档清晰简约。
看看它的主要功能:微信小程序

  1. 将小程序开发模式转为MVVM方式
  2. 支持类Vue.js 2.x风格的组件开发,包括单文件组件,支持scss、pug等。
  3. 支持加载外部NPM包
  4. 使用babel编译,支持ES6/ES7特性

MVVM多用于web单页应用,而小程序明显不是单页应用,并且也不支持双数据绑定,转为MVVM方式更多只是习惯上的喜爱,谈不上什么优势。
小程序也支持ES6特性(之前也支持ES7,不知道为何新版本取消了),用ES6特性能够完成外部NPM包引用。微信

因此最吸引人的功能就是第二点:支持组件化。babel

拿到官方给的示例wepy-wechat-demo编译后对比源码和编译后的代码来探究其实现组件化的思路。xss

整个项目很是清晰简单,咱们以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中怎么体现的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// dist/pages/index.wxml
<view class="tab">
    <view class="tab_item tab_message{{$tab$active == 0 ? ' active' : ''}}" bindtap="$tab$change" data-wepy-params-a="0">
        <image class="icon" src="../images/message{{$tab$active == 0 ? '_active' : ''}}.png"/>
        <text class="title">微信</text>
    </view>
    ...
</view>

// src/components/tab.wxml
<template>
    <view class="tab">
        <view class="tab_item tab_message{{active == 0 ? ' active' : ''}}" @tap="change(0)">
            <image class="icon" src="../images/message{{active == 0 ? '_active' : ''}}.png"></image>
            <text class="title">微信</text>
        </view>
        ...
    </view>
</template>

这段编译后的代码和tab.wxml源文件基本一致,发生改变的是数据绑定和事件绑定的地方,进行了重命名。
由此能够推断,是经过wepy的编译工具wepy-cli,把页面上的组件引用替换成了源码并经过修改变命名来隔离组件做用域避免冲突。
而这些从新修改的变量和事件如何起做用?
wepy的文档中提到组件支持回调和事件冒泡、事件下发,要支持这个特性除了按其要求的格式进行编写以外,还须要在js中引用一个叫wepy的模块,如

import wepy from 'wepy'

由此能够推断,wepy-cli编译的时候进行了模板替换和变量名(事件名)替换,而后wepy模块来处理替换后的事件调用以及组件之间的通讯。

若是仔细翻阅文档会发现其对组件的支持很是接近Vue.js 2.x,好比computed、watcher属性。行文此处,给做者由衷地点个赞。

那么这种方式是否就是最理想的组件化方式,或者说这种方式有什么缺陷呢?

相关文章
相关标签/搜索