插件,是可被添加到小程序内直接使用的功能组件。开发者可以像开发小程序一样开发一个插件,供其他小程序使用。同时,小程序开发者可直接在小程序内使用插件,无需重复开发,为用户提供更丰富的服务。
小程序插件服务对象

小程序插件与组件之间的差异
- 在开发过程中,组件一般以静态文件的形式在文件系统里面被引用,而插件则需要在运行时通过网络请求加载,在使用时无法看到插件代码(除
DOM结构外);- 小程序也无法获取插件提供的组件实例。
- 无法使用方法作用到组件插件的样式。
- 组件可由第三方包管理工具托管代码,而插件只能上传到微信小程序服务器,并且需要审核;
- 自定义组件只提供代码级的复用,而插件基于其独立的域名列表能提供独特的服务。

小程序插件使用场景示例
场景1
假如我们需要对我们的数据进行分析,而刚好有服务商能提供对应的插件服务,我们就能将数据授权给服务商进行分析,小程序开发者就不需要有额外的开发量,要做的只是引入插件,和传入数据:

场景2
广告是工具类小程序获利方式之一,我们将广告提供商的插件植入小程序中,用户通过观看广告达到品牌推广的效果,或进入广告页以及第三方小程序产生消费,都将给广告提供商带来利益,相应的广告提供商将付给小程序广告费:

场景3
类似云票儿插件提供开票等功能,拓展小程序的主业务:

场景4
多个小程序有相关联的业务场景,插件可以提供统一的服务,以及标准化的UI:

小程序插件的获取与使用
获取途径
小程序插件官方并没有提供插件市场,只有微信服务平台上有提供极少部分插件的检索,想搜索更多插件需要到小程序管理后台中查找。

小程序插件的使用
引入插件代码包
// app.json
{
"plugins": {
"myPlugin": { // 引用名
"version": "1.0.0", // 插件可发布多个版本,使用者按需求引用
"provider": "wxidxxxxxxxxxxxxxxxx"
}
},
// 如需使用插件功能页需要以下配置
"functionalPages": {
"independent": true
},
}
// 插件组件使用页
{
"usingComponents": {
"title-tools": "plugin://myPlugin/title-tool" // myPlugin为app.json中声明插件时使用的引用名
}
}
<navigator url="plugin://myPlugin/hello-page"> // myPlugin为app.json中声明插件时使用的引用名
Go to pages/hello-page!
</navigator>
小程序官方文档写的比较详细,可以查看使用文档。
小程序插件在分包项目中使用的注意事项

小程序插件开发
以上面所说的场景1为例,假设小程序开发者有将销量做成实时的图表展示,并能多端显示的需求,插件开发方就能提供这样的服务,小程序提供实时销量数据,插件负责处理数据和展示数据:

插件开发目录结构
在开发者工具中可以直接选择开发模式为插件创建项目:

工具会自动生成完整的目录结构:
miniapp-plugin
├── doc
│ ├── example.jpeg
│ ├── README.md // 插件开发文档
├── miniprogram // 插件开发示例小程序
│ ├── app.js
│ ├── app.json
│ ├── pages
│ │ ├── index
│ │ └── other
│ ├── project.config.json
│ └── sitemap.json
├── plugin
│ ├── components // 插件提供的自定义组件(可以有多个)
│ │ ├── ec-canvas
│ │ └── hello-component
│ ├── index.js // 插件的 js 接口
│ ├── pages // 插件提供的页面(可以有多个,自小程序基础库版本 2.1.0 开始支持)
│ │ └── hello-page
│ └── plugin.json // 插件配置文件
└── project.config.json
插件配置文件plugin.json
{
"publicComponents": {
"hello-component": "components/hello-component" // 插件提供的自定义组件
},
"pages": {
"hello-page": "pages/hello-page" // 插件提供的页面
},
"main": "index.js" // 插件的 js 接口
}
导出的js接口
根据文档插件可以导出函数、变量供小程序使用,但是如果插件中的方法有请求接口的话,考虑到数据安全问题,在发布的版本中会被阻止:

小程序插件中的“插槽”
插件可能会在页面或者自定义组件中,将一部分区域交给使用的小程序来渲染:
在插件的自定义组件中
{
"usingComponents": {
"plugin-comp": "plugin://myPlugin/comp",
"comp-from-miniprogram": "../../component/comp"
}
}
<plugin-view generic:mp-view="comp-from-miniprogram" />
在插件页中
{
"myPlugin": {
"provider": "wxAPPID",
"version": "1.0.0",
"genericsImplementation": {
"plugin-index": { // 插件页的名称为plugin-index
"mp-view": "components/comp-from-miniprogram"
}
}
}
}
作用:提高插件的灵活性;缺陷:使用的是抽象节点无法从小程序动态传值。
插件与小程序之间的数据交换

插件功能页
借助插件功能页能帮助开发者调用某些无法在插件中直接调用的接口,但是在开发过程中,个人开发者是无法在开发者工具上调试这些功能的,需要使用开通了插件功能的企业账号的插件appid才能正常调起,下面是个人小程序中使用云票儿插件打开用户信息功能页在真机上的效果图:

文档解读
要在插件中调用插件功能页,需要先激活插件所有者小程序的功能页特性。具体来说,在插件所有者小程序的
app.json文件中添加functionalPages定义段,并令其值为true。
这段文档解释了个人小程序开发者无法使用插件功能页的原因,是因为functionalPages这个字段要在插件所有者小程序中的app.json中配置,也就是说并不是在插件的配置文件中配置,而个人开发者无法开通插件功能,所以才出现无法使用的原因。
相关代码
<!-- plugin -->
<view wx:if="{{access}}" bindtap='loginAndSwitch'>
<slot></slot>
</view>
<functional-page-navigator wx:elseif="{{!show}}" name="loginAndGetUserInfo" withCredentials="{{true}}" args="{{ args }}" version="release" bind:success="loginSuccess" bind:fail="loginFail">
<slot></slot>
</functional-page-navigator>
<view wx:if="{{show}}" class='yunpiaoer-wrapper'>
<protocol bindcloseProtocol="closeProtocol" wx:if="{{protocolShow}}" />
<enter-title bindgotoProtocol="gotoProtocol" wx:else bindsubmit="saveInfo" />
</view>
<!-- page -->
<title-tools info="{{info}}" bindconfirm="yourSuccessCallback" bindfail="">
<button>编辑抬头</button>
</title-tools>
关于农贸市场交易鉴证小程序插件化的两点问题
- 无法获取手机号码。
- 无法使用
web-view组件。
总结
插件相比组件而言增加了更多的可能,就开发和使用难度而言,与组件相比是没有任何学习上的困难的;它不仅减少重复代码、减轻开发者的开发压力提供了很大的帮助,也开辟了一个面向程序员的市场。
不过就目前社区的活跃程度而言(插件本身更新的活跃度,以及社区有关插件的issue数量),小程序插件现在处于不温不火状态,产生这种状态的原因个人分析主要有三点:
- 由于它本身的一些限制,个人开发者是无法开发和发布插件的,虽然规范了市场,但同样也限制了程序员的想象力。
- 选择使用插件拓展功能的一般属于小程序本身的边缘业务,一般边缘业务是得不到重视的,同样制约了与之相应的插件的发展;
- 插件本身的能力很强大,但是它对于使用插件的小程序而言带来的作用却是并不那么明显(除类似广告、工具等引流之类以及与之有业务关联的小程序方以外),并且由于UI的不统一,造成视觉上的差异也是插件使用者所考量的因素之一。
本文档未提及
相关文档
插件本身包体积会加在小程序中