這幾天陸陸續續抽了點時間迭代了一版我的小程序版博客，一來是因為云開發的出現，讓很多功能成為了可能，二來正好也正好深度熟悉下云開發。
這次迭代主要是完善了評論功能「不知道審核能不能過」，一開始覺得很快能搞定，然而真正開發的時候還是碰到很多問題，這篇文章既是回顧總結，也是記錄下自己在開發過程中遇到的一些坑，僅供參考。
首先來看下我的成果：
開發回顧
具體思路還是比較簡單的，利用云開發中的數據庫來保存評論數據，在文章詳情頁的底部呈現具體的評論數據。
在上一篇云發開初體驗中，我已經創建了集合，用來存儲文章的訪問數，喜歡數和評論數,這次新建了集合用于存儲具體的評論數據，結構如下：
"_id": "集合id"
"_openid": "評論人openid"
"cAvatarUrl": "頭像url"
"cNickName": "昵稱"
"comment": "評論內容"
"createDate": "創建日期"
"flag": 0
"postId": "文章id"
"timestamp": "時間戳"
"childComment":
[{"cAvatarUrl": "評論人url"
"cNickName": "評論人昵稱"
"cOpenId": "評論人openid"
"comment": "評論內容"
"createDate": 2018-09-29
"flag": "數據標識"
"tNickName": "對方昵稱"
"tOpenId": "對方openid"
"timestamp": "時間戳"}]復制
在創建完集合之后，需要編寫對應的查詢，新增，和新增子評論的方法。
主要說下查詢和新增子評論。查詢的話肯定需要分頁加載，控制一次性數據的加載量，會用到skip和limit,大致寫法如下：
return db.collection('posts_comments')
.where({postId: postId})
.orderBy('timestamp', 'desc')
.skip((page - 1) * 10)
.limit(10)
.get()復制
然后是新增子評論，相當于在主評論下回復別人，主要在集合中下新增評論，這里使用mand.push更新指令，往數組尾部添加一個或多個值。大致寫法如下：
const _ = db.command
return db.collection('posts_comments').doc(id).update({
data: {
childComment: _.push(data)
}復制
在文章詳情底部功能欄的樣式上，還是比較糾結的，參考了一些UI，最終還是使用這種折疊的方式，具體的樣式代碼就不貼了。
截圖1
其中有幾個交互可以嘮叨下。
首先是點加號會上拉底部的功能按鈕，這個沒什么問題，但細節需要注意，通常情況下點空白處時會自動縮回去，但這個實現有點凌亂，于是我在功能菜單以外的視圖外層套了層view:
...文章主題部分...
/**
* 非評論區隱藏菜單
*/
hiddenMenubox: function() {
this.setData({
isShow: false,
menuBackgroup: false
})
},
復制
然后是評論輸入框中的提示，默認是評論...，當點擊回復具體某個人的評論時，默認修改成回復***。
然后是喜歡和收藏兩個按鈕，喜歡和收藏之后圖標自動點亮。
還有就是提交完評論之后默認重新刷新評論列表，最后一條評論之后停止刷新，沒有評論友好提示等。總之一些小的交互點還是挺多的。
這里就不一一說明了，有興趣的可以瀏覽下我的小程序，并看看源碼。
問題點整理
主要還是說說開發過程中的問題點和如何解決的。
1.獲取用戶的
首先是獲取用戶的問題，在沒有云函數之前，獲取用戶的還是比較麻煩的，需要通過wx.login獲取code，然后通過code和小程序的appid和請求接口從而獲取到。
而有云函數之后，可以簡單調用下云函數，經過微信鑒權之后可直接獲取到用戶的：
exports.main = (event, context) => {
return {
openid: event.userInfo.openId,
}
}復制
2. 數據庫操作權限問題
因為每月云函數有調用次數的限制，所以想直接在客戶端調用數據庫。一開始挺順利的，但當更新子評論的時候出現問題了，由于客戶端對于數據庫最大權限是所有用戶可讀，僅創建者及管理員可寫,所以導致子評論無法更新進去「創建者和子評論者是兩個用戶」。
所以沒辦法，只能包一層云函數，云函數中調用數據庫，因為服務端調用數據庫沒有這個權限的限制。
// 云函數入口函數
exports.main = async (event, context) => {
return await db.collection('posts_comments').doc(event.id).update({
data: {
childComment: _.push(event.comments)
}
})
}復制
其實個人感覺數據庫操作最好都放在服務端比較好，由云函數統一收口，設計好的話，云函數還能當作路由的作用。
3.與
一開始沒有仔細看文檔，所以猜了坑，稍微關注下就可以避免了，同為點擊事件，事件綁定不會阻止冒泡事件向上冒泡,而 事件綁定可以阻止冒泡事件向上冒泡。
所以在由多層嵌套的時候一定要注意下，是否需要冒泡。
4.
上一版本中的方法基本都采用的回調方式，之前功能簡單感覺閱讀起來還好。但這次改動之后發現代碼就坑了，回調方法太多感覺有點眼花了。
原本打算使用ES7的特性async/await，但發現目前微信web開發者工具還不支持，相信以后應該會支持吧，不太愿意引用其他插件了，所以還是使用了,使用下來代碼可閱讀性提高了很多，可以一直then下去。
但畢竟不是專業前端，總感覺代碼寫的還是比較糟糕，后期打算再迭代優化下代碼。
5. 樣式
在樣式上遇到的問題其實挺多的，主要還是自己的基本功不扎實，所以踩了很多的布局的坑，這里就不一一說了，也說不清楚，自己親自搭建之后還是會有很深印象的。
其他優化點
在開發評論功能的同時，也優化了一些問題點，這里也說明下：
引流公眾號組件
也是最近更新的功能，所以將此功能加上去了小程序評論功能，比較簡單，在公眾平臺中啟用關注組件并綁定公眾號，然后代碼中引用下即可：
復制
截圖2
效果可以看下，還是挺有意思的：
截圖3
2. 授權
原本的授權是跳轉到單獨的頁面的，訪問過我的小程序的知道，那個頁面有個可愛的gif的萌妹子
截圖4
但發現體驗不是很好，首先這個gif萌妹子體積比較大，影響首次加載。其次是跳轉時效果也不是很理想。
所以改成彈窗的方式，并首次使用了模板頁：
截圖5
3. 修復的問題
有網友反饋部分安卓機文章詳情頁加載不出來，后來發現是因為中.dir的問題，部分安卓機不支持，注釋掉即可。
總結
2.0的代碼提交審核了小程序評論功能，不懂能不能通過，希望在國慶節可以和大家見面吧。
其實要優化的點和開發的功能還是有很多，比如生成海報還沒有開發，發送的文本框不能換行，體驗不太好等等。
后期慢慢迭代吧，也歡迎大家使用體驗，并多提寶貴意見。