scenario

An SDK like TalkingData already provides convenient methods for reporting events, such as the following:

Tdapp. onEvent(" activity homepage ", 'tag name',params);Copy the code

For simple data reporting needs, it is perfectly possible to call the method directly and then complete its function, but not for complex parts. This paper illustrates its necessity in some small points.

Benefits of encapsulation

Simplification and standardization of events

In TalkingData, event names are distinguished by text values, which can cause errors due to user irregularities. To this end, we have made the following agreement on the way of use:

Define a dictionary of events, which can be used to quickly select the event name to be called by introducing a dictionary of buried events

2 When the underlying call, the specific execution of the event name is solidified, not open to the public

Definition:

export const DATA_REPORT_EVENTS = {
    activityPageIndex:'activityPageIndex'.activityIn:'activityIn'
}
export const DATA_REPORT_ORI = {
    activityPageIndex:(params){
        TDAPP.onEvent("Activity Home page", ' ', withParams); },activityIn:(params){
        TDAPP.onEvent("Take part in activities", ' ', withParams); },default: () {//codes here}}Copy the code

Usage:

import { DATA_REPORT_EVENTS,DATA_REPORT} from 'src/utils/dataReport'
function activityPage extends Comoponent{
    compontentDidMount(){
        //datareport 
        DATA_REPORT(DATA_REPORT_EVENTS.activityPageIndex)
    }
}

Copy the code

Environmental differentiation

Reporting requirements need to be differentiated between offline and online environments. Offline reporting may not be required or the reported content may be differentiated.

Datareport.js actual exposure method

import {isProd} from 'src/config/env' export const DATA_REPORT = (event,params) => { if (isProd) { return DATA_REPORT_ORI[event]? .(params) } else { return DATA_REPORT_ORI.default } };Copy the code

The attached data

Obviously, in our business, in addition to the current business information, some parameters are global and need to be reported specifically. Therefore, we will also take these parameters into consideration in the packaging design (such as ua, unique ID, network status, etc.).

dataReport.js

const ua = navigator.userAgent const withParams = { userId: SessionStorage. The getItem (' userId ') | | 'h5 users' + math.h random () * 1000, ua}Copy the code

Pass params enhancement

In comparison, we have weakened the input part. If there is demand for this part, it can be strengthened according to its real demand. Divergent thinking points are as follows:

The params provided by 1 are method parameters, which provide the event name with certain logic or algorithm

2. Provide event callers with some internal data of TalkingData, such as UA, user data and APP version, so as to facilitate function enhancement

3 Params is upgraded to an Options configuration object, which provides apis such as reporting frequency and reporting form

Reported high cohesion

The core reason for encapsulation is to achieve high cohesion in design principle. When we carry out some centralized processing related to reporting, we can update the configuration of a file completely globally, such as reporting frequency and reporting format. If you call tdApp. onEvent directly from a call location, it will make the parameters uncontrollable and difficult to maintain.

summary

The reason for considering encapsulation was:

  • All applications monitor 30+ events scattered on 12+ pages. 30+ specific scenarios are difficult to maintain
  • Some events are actually homogeneous events of a class of events (the parameters are exactly the same but the event names are different)
  • Different environments and different entrances have this distinction in the nature of the strategy

Instead of designing for design’s sake, when your scenarios are a little more complex, consider adding design ideas like encapsulation to make your code more elegant.

Language finches connections: www.yuque.com/robinson/fe…