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

背景

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

思路

埋點頁面中的請求方法

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

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

路由——頁面id映射表

後端接口須要格式大概是:app

{
    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的方法,和當前頁面對映信息的方法:ui

// 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實例上,頁面中使用就不用引入了。頁面深度不一樣,小程序裏引入真的很麻煩。this

// app.js

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

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

結尾

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

相關文章
相關標籤/搜索