小程序頁面統計埋點設計思路

背景

須要對小程序的頁面訪問進行統計，但小程序並無頁面或者路由攔截，若是要重寫page或者寫mixs函數太麻煩，因此但願有個以後擴展方便，改動成本低的方式進行頁面埋點統計。

思路

埋點頁面中的請求方法

咱們知道在不一樣頁面中寫入同一功能的代碼是件很煩惱的事情，重複的工做量，各個頁面間的差別性處理，都很糟心。因此在小程序這資源有限的環境裏，咱們但願儘可能減小這部分的工做量，最好每一個頁面的功能代碼都同樣，而且精。，考慮到每一個頁面的差別能夠用路由體現，而且能拿到當前頁面的路由參數，因而採用了這個策略。

page({
    ...
    onLoad() {
        app.countViewer(this.route) //數據埋點
        ...
    }
    ...
})
複製代碼

路由——頁面id映射表

後端接口須要格式大概是：

{
    id: 0, // 頁面id
    detailId: 255 // 具體業務狀況下的id，例如商品的id、廣告的id等
}
複製代碼

因此咱們須要維護的映射表大概會長這樣：

const RouteList = [
    {
      id: 1,
      route: 'page/index/index',
      name: '活動專題',
    },
    {
      id: 2,
      route: 'page/active/inde',
      name: '活動專題',
    },
]
複製代碼

封裝成個類，構造函數接受當前頁的route，和具體的業務id做爲參數，並向外提供得到完整RouteList的方法，和當前頁面對映信息的方法：

// router.js
class Route {
    RouteList = [
    {
      id: 1,
      route: 'page/index/index',
      name: '活動專題',
    },
    {
      id: 2,
      route: 'page/active/inde',
      name: '活動專題',
    }]
    
    constructor(route, detailId) {
        const currentRoute = this.RouteList.find(item => item.route === route) || {} // 查找符合的當前route的對象， 若是沒找到返回空對象，避免報錯
        this.page_id = currentRoute.id
        this.page_detail_id = page_detail_id
    }
    
    getRouteList() { // 返回完成對映表
        return RouteList
    }
    
    getData() { // 返回當前對映項
        return {
          page_id: this.page_id,
          page_detail_id: this.page_detail_id
        }
    }
}

module.exports = Route

複製代碼

發送方法

// countViewer.js 假設$request是已經封裝好的方法

let Router = require('./router.js')

export default function countViewer(router, detailId = 0) { // 給業務id一個默認值
  const app = getApp() // 得到全局的$request封裝好的小程序請求
  const params = new Router(router, detailId).getData() //得到當前路由對映的參數信息

  app.$request('countviewer', params)
}

複製代碼

並將該方法綁定到全局的app實例上，頁面中使用就不用引入了。頁面深度不一樣，小程序裏引入真的很麻煩。

// app.js

import countViewer from "./utils/countViewer.js"

App({
    ...
    countViewer,
    ...
})
複製代碼

結尾

很久不更新了，最近正好來了個需求，想一想以前剛接手這個小程序的時候想寫個路由/頁面攔截器，發現網上提供的方法都挺麻煩的，每一個頁面戳進去改一大段page簡直難過，因此一開始聽到這個需求是有點想哭的。當任務真砸到頭上，仍是能想出辦法的。怎麼說呢，開發原則大概就是，避免去戳頁面和糟糕的重複代碼，實在要重複，就儘可能抽出公共部分把以後更改的時候的工做量下降扒。