這幾天在使用小程序的模板消息推送接口的時候，出現了個報錯信息 「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源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。