Author: QP

XXX project was officially put into trial on November 30, 2020. During the use period, there were all kinds of user feedback every day. There were problems that could be seen at a glance, problems with style, old data problems, compatibility problems, script errors, and so on.

First, for the WEB end

1, better to solve the problem, let the user directly provide account password, on your own computer can location problem, the problem of the APP, so, the same can be through the way of the login account, seen in the local operating logs, then positioning, together with the back-end can quickly pinpoint the reasons, rapid processing.

Two, for wechat small program

A. However, the small program is an exception. It is through the wechat authorized login system. We can not get the user’s wechat signal for login operation. B. During this period, I located some problems of small program, mainly previous experience, and understanding of small program, business understanding, positioning problems. C. However, this method of locating problems will cost a lot of trial and error, especially for some key business processes, the farmers need to deal with them immediately, otherwise the breeding business cannot continue. In addition, if another person is not familiar with the business logic, the positioning may not be so easy. D. Therefore, it is particularly important for the service interface at the C end to report data errors. So I started the design of this work

Micro channel small program in the management background, also provides the function of viewing logs, but this kind of logs, can only view the user due to script, API call error

Those less familiar with business logic may not be as easy to locate

Also availableDevelopers.weixin.qq.com/miniprogram…Interface to customize service data error reporting

But this way is not flexible enough, and there are more back-end developers, each person is responsible for different modules, every time to log in the small program management background to locate problems, is also very inconvenient operation. So do it yourself.

Thoughts before design: 1. Data cannot be uploaded all the time, otherwise it will cause data explosion. Solve by switch



2, the switch can not be too obvious, otherwise it will cause trouble to the user. Hidden button, it is necessary to know when the user opens the problem, the need to remotely guide the user, according to the specific problem, trigger the switch



3. After the data upload switch is enabled, it needs to be automatically disabled; otherwise, invalid data will be uploaded. After the specified time is exceeded, the system automatically shuts down.

  1. Button page: when the page comes in, the local cache initializes the button state
onShow() {
   const switchStatus = storage.getStorage('switchStatus') | |false
   this.setData({
     isOpen: switchStatus
   })
 },
Copy the code

2) Click the switch to change the state of the button, and record the current time for calculating the time difference

 switch() {
 const { isOpen } = this.data
 this.setData({
   isOpen: !isOpen
 })
 storage.setStorage('switchStatus', !isOpen)
 if(! isOpen){ storage.setStorage('switchStatusCreateTime', dayjs().format('YYYY-MM-DD HH:mm'))}else {
   storage.removeStorage('switchStatusCreateTime')}}Copy the code

3) Calculate the interval when the upload operation is triggered

 // Get the current time
const currentTime = dayjs()
// Get the time of the local storage
const switchStatusCreateTime = storage.getStorage('switchStatusCreateTime')
// Get the switch status
const switchStatus = storage.getStorage('switchStatus')
// Compare two times to see if it has been more than 12 hours
const outTimeNumber = currentTime.diff(dayjs(switchStatusCreateTime), 'hour')
try {
 if (outTimeNumber > outTime) { // Proactively clear the upload switch cache record time when the time exceeds
   storage.removeStorage('switchStatusCreateTime')
   storage.removeStorage('switchStatus')}else if (outTimeNumber < outTime && switchStatus) { // Within the switch validity period
   const systemInfoObj = getSystemInfo() // Device information
   const userInfo = getUserInfo()
   const payLoad = {
     interfaceUrl,
     traceId,
     accountId: userInfo.accountId,
     userName: userInfo.userName,
     phone: "".otherData: {... systemInfoObj, ... userInfo } } postRequestData(baseUrl, payLoad) }else { // Reset all configurations
   storage.removeStorage('switchStatusCreateTime')
   storage.removeStorage('switchStatus')}}catch (error) {
 console.log("error",error);
}
Copy the code

4. Where is the data uploaded? The backend can be viewed, save to the business database is very simple, the backend directly provide interface processing.

The backend provides a log interface to upload the information to be uploaded in accordance with the format specified by the backend, such as user information, device information, and key traceId and interfaceUrl. For example, I sorted out a lot of information to upload



5. The trigger time should be immediate, regardless of the success or failure of the business interface.

Instant trigger, must be when the user uses, immediately triggered, in the network request location is the most appropriate however, I put the user initiated a request success or failure location, do an upload

The above summary is not limited to small programs, all H5 ideas are similar, small programs benefit from rich API, access to user information, device information is easier.