這幾天(tian)陸陸續(xu)續(xu)抽(chou)了(le)點時(shi)間迭代(dai)了(le)一版我的(de)(de)小程序版博客，一來是因為云(yun)開發的(de)(de)出(chu)現(xian)，讓(rang)很(hen)多功能成為了(le)可(ke)能，二來正好也正好深(shen)度熟悉下云(yun)開發。

這(zhe)(zhe)次(ci)迭代(dai)主(zhu)要是(shi)完(wan)善了評論功能(neng)「不(bu)知道審核能(neng)不(bu)能(neng)過」，一(yi)開始覺(jue)得(de)很快能(neng)搞(gao)定，然而(er)真正(zheng)開發的(de)時候還是(shi)碰到很多問(wen)題，這(zhe)(zhe)篇文章既是(shi)回顧(gu)總結，也是(shi)記(ji)錄(lu)下自己在開發過程中遇到的(de)一(yi)些坑(keng)，僅供參考(kao)。

開發回顧

具(ju)體(ti)(ti)思路還是比(bi)較(jiao)簡(jian)單的(de)，利用云開發中的(de)數據(ju)庫來保存評論(lun)(lun)數據(ju)，在文章詳情(qing)頁的(de)底部(bu)呈現具(ju)體(ti)(ti)的(de)評論(lun)(lun)數據(ju)。

在(zai)上一(yi)篇云發開初體驗中，我已經創建了 posts_statistics 集(ji)合，用(yong)來存(cun)儲文章(zhang)的(de) 訪問數(shu) ， 喜歡(huan)數(shu) 和 評論數(shu) ,這(zhe)次(ci)新(xin)建了 posts_comments 集(ji)合用(yong)于存(cun)儲具(ju)體的(de)評論數(shu)據(ju)，結構(gou)如(ru)下：

"_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": "時間戳"}]

在(zai)創建完集合之后，需要編寫對應的(de)查(cha)詢(xun)，新增(zeng)，和(he)新增(zeng)子評(ping)論的(de)方法。

主要說下查(cha)詢和(he)新增子評論。查(cha)詢的話肯定(ding)需(xu)要分頁加載，控(kong)制一次性數據的加載量，會用到 skip 和(he) limit ,大致寫法如下：

return db.collection('posts_comments')
    .where({postId: postId})
    .orderBy('timestamp', 'desc')
    .skip((page - 1) * 10)
    .limit(10)
    .get()

然后是新增子評論(lun)(lun)，相當于在主評論(lun)(lun)下(xia)(xia)回復(fu)別人，主要在集合中 childComment 下(xia)(xia)新增評論(lun)(lun)，這里使(shi)用 db.command.push 更(geng)新指令，往數組尾部添加(jia)一個(ge)或(huo)多個(ge)值。大致寫法如下(xia)(xia)：

const _ = db.command
return db.collection('posts_comments').doc(id).update({
    data: {
      childComment: _.push(data)
    }

在文章詳情底部功能欄的(de)樣(yang)式(shi)上，還是比(bi)較糾(jiu)結的(de)，參考了一些(xie)UI，最終還是使用這種(zhong)折(zhe)疊的(de)方式(shi)，具體的(de)樣(yang)式(shi)代碼就不貼(tie)了。

其中有幾個交(jiao)互可以嘮叨下。

首先是點(dian) 加號 會上拉(la)底部的功能(neng)按(an)鈕，這個(ge)沒什么問題，但細節需要注意(yi)，通常(chang)情況下(xia)點(dian)空(kong)白處(chu)時會自動縮回去，但這個(ge)實現(xian)有點(dian)凌亂，于(yu)是我在功能(neng)菜單以外的視圖外層(ceng)套了層(ceng)view:

<view catchtap="hiddenMenubox">
...文章主題部分...
</view>

/**
 * 非評論區隱藏菜單
*/

hiddenMenubox: function() {
	this.setData({
	  isShow: false,
	  menuBackgroup: false
	})
},

然后是評論(lun)(lun)輸入框中的提示，默認是 評論(lun)(lun)... ，當(dang)點擊回(hui)復具(ju)體某個(ge)人的評論(lun)(lun)時，默認修(xiu)改成 回(hui)復*** 。

然后是喜(xi)歡(huan)和收(shou)藏兩個按(an)鈕，喜(xi)歡(huan)和收(shou)藏之(zhi)后圖標自動點亮。

還有(you)就是提交(jiao)完(wan)評(ping)論(lun)(lun)之(zhi)后(hou)(hou)默認重新刷(shua)新評(ping)論(lun)(lun)列表，最后(hou)(hou)一(yi)條評(ping)論(lun)(lun)之(zhi)后(hou)(hou)停止刷(shua)新，沒有(you)評(ping)論(lun)(lun)友(you)好提示等。總之(zhi)一(yi)些小的交(jiao)互點還是挺多的。

這里(li)就不一(yi)一(yi)說(shuo)明了，有興(xing)趣的(de)可以瀏覽下我的(de)小程序，并看(kan)看(kan)源碼。

問題點整理

 主(zhu)要還是說說開發過程(cheng)中的(de)問題點和如何解(jie)決的(de)。

1.獲取用戶的openid

首先是獲(huo)取(qu)(qu)用戶(hu)的(de)openid問題(ti)，在沒有(you)云函(han)數之前，獲(huo)取(qu)(qu)用戶(hu)的(de)openid還是比較麻煩的(de)，需要(yao)通過wx.login獲(huo)取(qu)(qu)code，然后通過code和小程序的(de)appid和secret請(qing)求接口(kou)從而獲(huo)取(qu)(qu)到openid。

 而(er)有云(yun)函數之(zhi)后，可以(yi)簡單調用下云(yun)函數，經(jing)過(guo)微信鑒權之(zhi)后可直(zhi)接獲取(qu)到(dao)用戶的openid：

exports.main = (event, context) => {
  return {
    openid: event.userInfo.openId,
  }
}

2. 數據庫操作權限問題

因為每月(yue)云函數有調(diao)用(yong)次數的限制，所(suo)以(yi)想直接在客(ke)戶(hu)(hu)端調(diao)用(yong)數據庫。一開始挺順利的，但當更新子評論的時候出現問題(ti)了，由于(yu)客(ke)戶(hu)(hu)端對于(yu)數據庫最大權限是(shi) 所(suo)有用(yong)戶(hu)(hu)可讀(du)，僅創建者(zhe)及管理員可寫 ,所(suo)以(yi)導致子評論無法更新進(jin)去「創建者(zhe)和子評論者(zhe)是(shi)兩個用(yong)戶(hu)(hu)」。

所以沒(mei)辦法，只能(neng)包一層云函數(shu)，云函數(shu)中調用(yong)數(shu)據(ju)庫，因為(wei)服務端(duan)調用(yong)數(shu)據(ju)庫沒(mei)有(you)這個權限(xian)的限(xian)制。

// 云函數入口函數
exports.main = async (event, context) => {
  return await db.collection('posts_comments').doc(event.id).update({
    data: {
      childComment: _.push(event.comments)
    }
  })
}

其實(shi)個人感覺(jue)數(shu)據庫操作最好都放在服(fu)務端比較(jiao)好，由云(yun)函數(shu)統一收口，設計(ji)好的話，云(yun)函數(shu)還能(neng)當作路由的作用(yong)。

3.catchtap與bindtap

一開始沒(mei)有仔細看文檔，所以猜了(le)坑，稍微關(guan)注下就可以避免了(le)，同為點擊事(shi)件(jian)(jian)， bindtap 事(shi)件(jian)(jian)綁定(ding)不會阻止冒(mao)泡事(shi)件(jian)(jian)向上(shang)冒(mao)泡,而 catchtap 事(shi)件(jian)(jian)綁定(ding)可以阻止冒(mao)泡事(shi)件(jian)(jian)向上(shang)冒(mao)泡。

所以在由多層嵌套(tao)的(de)時候一定要(yao)注意下，是否需要(yao)冒泡。

4.promise

 上(shang)一版本中的(de)方法基本都采用的(de)回調方式(shi)，之前功能(neng)簡單感覺(jue)閱讀起來還(huan)好。但這(zhe)次改(gai)動之后發(fa)現代碼(ma)就坑了，回調方法太(tai)多感覺(jue)有(you)點(dian)眼花了。

原本打算使(shi)(shi)用(yong)ES7的(de)特性(xing) async/await ，但發現目前(qian)微信(xin)web開發者(zhe)工具還不(bu)支持(chi)(chi)，相信(xin)以(yi)后應該(gai)會支持(chi)(chi)吧，不(bu)太愿意引(yin)用(yong)其他(ta)插件(jian)了，所以(yi)還是使(shi)(shi)用(yong)了 promise ,使(shi)(shi)用(yong)下(xia)(xia)來代碼可(ke)閱(yue)讀性(xing)提高了很多，可(ke)以(yi)一直 then 下(xia)(xia)去。

但(dan)畢竟不(bu)是專業前端，總感覺代碼(ma)寫的還是比較糟糕，后期打算再(zai)迭代優(you)化下代碼(ma)。

5. 樣式

在樣(yang)式上遇到(dao)的問題其實挺多的，主要還是(shi)自己的基本功不扎實，所以踩了很(hen)多的布局(ju)的坑，這里就(jiu)不一一說了，也說不清楚(chu)，自己親(qin)自搭建(jian)之后還是(shi)會有很(hen)深印象的。

其他優化點

在開發評論功能的同(tong)時，也(ye)優(you)化了(le)一些(xie)問題點，這里也(ye)說明下：

引流公眾號組件

也是(shi)最近(jin)更新的(de)功(gong)能(neng)，所(suo)以將(jiang)此功(gong)能(neng)加上(shang)去了(le)，比較簡(jian)單，在公眾(zhong)平臺中(zhong)啟(qi)用關注組(zu)件并綁定(ding)公眾(zhong)號，然后(hou)代碼中(zhong)引用下即可：

<official-account></official-account>

效果可以看(kan)下，還是(shi)挺有(you)意(yi)思的：

2. 授權

原本的(de)(de)授權是跳轉到單獨(du)的(de)(de)頁(ye)面的(de)(de)，訪問(wen)過我的(de)(de)小程序的(de)(de)知道，那(nei)個頁(ye)面有(you)個可愛的(de)(de)gif的(de)(de)萌妹子

但(dan)發現體(ti)驗不(bu)是(shi)很好，首先這(zhe)個gif萌妹(mei)子體(ti)積比較大，影響首次加(jia)載。其次是(shi)跳轉(zhuan)時效果(guo)也不(bu)是(shi)很理(li)想。

所以(yi)改成彈窗的(de)方式(shi)，并首次使用(yong)了(le)模板頁：

3. 修復wxParse的問題

有網(wang)友反(fan)饋部分安(an)卓(zhuo)機文章(zhang)詳情(qing)頁加載不出來(lai)，后來(lai)發現是(shi)因為 wxParse 中(zhong) console.dir 的問題(ti)，部分安(an)卓(zhuo)機不支持，注釋掉即可。

總結

2.0的代(dai)碼(ma)提交審核(he)了，不(bu)懂能(neng)(neng)不(bu)能(neng)(neng)通過，希(xi)望在國(guo)慶節可(ke)以和大(da)家見面吧。

其實要優化的(de)點和開發(fa)的(de)功(gong)能還是有(you)很多，比如生成海(hai)報(bao)還沒有(you)開發(fa)，發(fa)送的(de)文(wen)本框不能換行，體(ti)驗不太好等(deng)等(deng)。

后(hou)期慢慢迭代吧(ba)，也(ye)歡迎(ying)大家使用體驗(yan)，并(bing)多提寶(bao)貴意見。