这几天在使用小程序的模板消息推送接口的时候，出现了个报错信息 “the formId is no longer available in develop or trial version”，去文档查看了一下才发现，模板消息功能在今年1月份已经下架了，如今统一都是使用订阅消息：html
那么这两个功能有什么区别呢？前端
「模板消息推送」web
简单地说，用户每进行一次提交表单或是支付行为，都会产生一个 formId，开发者能够经过这个 formId 向用户推送消息。因为下发权限是在开发者这边，为了防止消息频繁推送对用户形成的骚扰，小程序作出了一个限制：一个 formId 只有 7 天有效期，每推送一次消息会消耗一个 formId，也就是说，正常状况下，开发者 7 天内能够推送的消息数量是有限的。这样固然对用户是友好的，可是对开发者来讲，有些业务场景又确实推送多条消息：好比说 A 用户发布一个二手商品，B 用户点击了“感兴趣”，须要推送消息告知 A 用户，同理，C 用户也点击了“感兴趣”，一样须要推送消息告知 A 用户，这种状况下一个 formId 确定是不够用的。因而在订阅消息出现之前，开发者就使用了一些黑科技来收集 formId：包括基于事件冒泡的多层嵌套表单，以及在小程序里埋藏大量的点击事件等，只要用户点击了就会触发表单提交，生成新的 formId，而后记录下有效期存放到数据库中，方便后续的使用。数据库
不过有很多的黑科技已经被微信官方修复了，并且咱们会发现，最终仍是回到了起点，仍然没有解决用户受到消息骚扰的问题。微信大概也意识到了这一点，因此推出了订阅消息功能。小程序
「订阅消息推送」api
举个订阅消息的例子：当咱们参与某个公众号的抽奖活动以后，会有弹窗提示咱们是否接受抽奖结果的信息推送，这个弹窗就属于订阅消息功能的受权环节。数组
从使用体验来看，订阅消息推送最大的特征就在于，它对于用户和开发者都是友好的。首先，消息下发的权限交还给了用户，由用户本身来决定要不要接受消息推送，再也不像以前那样被动接受了；其次，对于咱们开发者来讲，只须要调用接口询问用户是否接受消息推送便可，只要用户赞成，那么咱们就能够屡次发送消息，再也不须要像之前那样费力去收集 formId 了。微信
「使用」微信公众平台
首先登陆微信公众平台，选择 订阅消息 —— 个人模板 —— 添加，而后根据本身的需求选择一个模板，配置关键字，提交以后便可得到模板对应的模板 Id，这个 Id 稍后调用 api 的时候会用到，固然，一样须要用到的还有关键字对应的参数：async
小程序端代码：
let templateId = 'Ite6-mnfTlONu6rd35AJ-SGQYKQgj1WMvjVj0O5h9kE'
wx.requestSubscribeMessage({
tmplIds: [templateId],
success: (res)=> {
// 若是用户点击容许
if(res[templateId] == 'accept'){
console.log('点击了容许')
wx.cloud.callFunction({
name:'sendMessage',
data:{
templateId,
content: this.data.textContent,
blogId: this.properties.blogid,
}
}).then(res => {
this.setData({
textContent:''
})
})
} else {
console.log('点击了取消')
}
}
fail:(res) => {}
})
wx.requestSubscribeMessage 这个 api 主要用来调起弹窗询问用户是否接受消息推送，tmplIds 数组存放各种模板 Id，由于开发者可能不止使用了一个模板。
这里要注意两个地方，第一个是这个 api 只能在点击事件或者触发支付回调后使用，bindsubmit 表单提交事件是用不了的；第二个是，无论用户点击容许仍是拒绝，都会来到 success 回调，fail 回调是在 api 自己调用失败后执行的。那么怎么判断用户是点击了容许仍是拒绝（取消）呢？若是用户点击了容许，那么 res 中模板 Id 键对应的键值会是 “accept”（反之则是 “reject”），而后调用相应的云函数并传参，进行消息推送。
在云函数中调用相关 api 以前，要先去云函数文件夹下的 config.JSON 文件设置调用权限：
{
"permissions": {
"openapi": [
"subscribeMessage.send"
]
}
}
相关的云函数：
const cloud = require('wx-server-sdk')
cloud.init()
exports.main = async (event, context) => {
const {OPENID} = cloud.getWXContext()
return await cloud.openapi.subscribeMessage.send({
touser: OPENID,
page: `/pages/blog-comments/blog-comments?blogId=${event.blogId}`,
data:{
thing4:{
value:'评价完成'
},
thing1:{
value: event.content
}
},
templateId: event.templateId
})
}
主要是用到了 cloud.openapi.subscribeMessage.send() 这个 api，相关的参数就根据本身的实际状况来：这里的 OPENID 是消息发送目标的 openid，page 则是用户点击消息后进入的页面（这里是评论详情页），data 就对应咱们以前在微信公众平台设置的模板关键字，固然，这里要注意使用此前模板提供的键名（thing4 和 thing1），最后还有一个参数就是咱们的模板 Id 啦。其实和以前模板消息的用法是差很少的，只不过咱们再也不须要传参 fromId 了。
最后，对用户来讲，他也能够在弹窗的时候点击容许和记住选择，这样就是默认每次都接受消息推送了，对应的就是默认执行 wx.requestSubscribeMessage 中的 if 代码块。
其实，不谈技术，单从用户的角度来看，这个功能的调整是很人性化的，选择权确实本就应该掌握在用户手中，若是用户没有权限拒收不须要的消息，这样的产品还谈什么用户体验呢？在查阅相关资料的时候，也看到了一篇从产品角度分析的文章[1]，感受写得不错，感兴趣的能够看一看。
Reference
文章: http://www.woshipm.com/pd/3003619.html
[2]小程序官方文档: https://developers.weixin.qq.com/miniprogram/dev/api-backend/open-api/subscribe-message/subscribeMessage.send.html#method-cloud
本文分享自微信公众号 - 漫游前端世界（gh_6ac344b74a01）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。