background

Since its release, wechat mini programs have gone from being small and disposable to a mobile application with complex functions and complete business.

As a result, there will be more bugs that are difficult to locate and cannot be simply reproduced in production and operation. Especially, I am engaged in banking business development, which requires high stability. Otherwise, it is easy to cause customer complaints or even capital losses.

In addition, in order to do user research, we need to understand how users use our applet, such as routing timing, click streams, and so on.

All of these require complete and usable logs to find and locate production problems and track user behavior.

Log types

Check the API documentation. There are three ways for small programs to print logs, which are described as follows:

1. Console logging: The development test phase is used for debugging

2. Real-time log (Wx. getRealtimeLogManager) : It records user operations in real time and provides good filtering to locate specific logs accurately. The daily limit is 500W, but multiple prints will be merged into one report; Keep for up to 7 days. portal

3. Local log (wx.getLogManage) : local log of the client. Users can click “Feedback and Complaints” or click the feedback component on the page to synchronize the log to the management console. The biggest 5 MB. portal

Collective reporting and data desensitization

Different logs may be used to locate specific problems, or they may be combined to verify user behaviors.

Therefore, we need to report several kinds of logs at the same time, but some business-sensitive data may not be suitable to be reported to the external system (wechat server) or stored locally on the client side. We can desensitize the data in the encapsulated collection reporting function first.

The approach is simple, traversing log objects, encoding sensitive data through regular matches.

The real-time log after desensitization is as follows:

Refer to our wrapped logging plug-in @wXA /log

Non-trace buried point

Event capture

Generally speaking, front-end logs include at least: routing switching information, script error logs, interface request data, and user interaction information

In the small program, the first three can be captured and reported through the official listening interface and encapsulation function method.

Only user interaction information, because of the two-threaded architecture of the applet, does not directly capture user events in the Document object as h5 does. You can only listen for user behavior at the outermost layer of each WXML template by binding events.

But there is no way to catch non-bubbling events (such as catchtap) and component events (such as getUserInfo).

Furthermore, there is no way to capture all events; component events do not bubble up.

hijacking

In a different way, can you hijack all the event functions in a small program to achieve event capture? You can.

Both normal events and component events in wechat applet are bind event or Catch {event} or catchEvent or catch{event}. We can replace all the values of this form of key in the template with the hooks we define.

Events are captured and reported in hook functions, and then the original bound events are executed to implement event hook functions like beforeEevent and afterEvent.

Component identification

The event object does not have details of the component that triggered the event (xPath-like metadata), so if two components on the page are bound to the same event, how can we tell which component triggered the event that the user clicked on?

You can create an ID for a component by combining the component name, ID, and class information of the component.

eventName*tagName#id.class(data)
Copy the code

For example,

<button id=" BTN "class="confirm" bindtap="submit">Copy the code

After passing the hijacking event and adding the identity information, the actual output code is:

<button id="btn" class="confirm" bindtap="beforeTag" data-wxa-hijack="sumbit" </button> eleId="tap*button#btn.confirm ">Copy the code

The component id can then be retrieved from the event object via e.mark.eleid

Implementing interceptor functions

import BindHijackPlugin from "@wxa/plugin-bind-hijack/runtime"; wxa.use(BindHijackPlugin, { beforeTap: function(e){ $log('tap event', e); }, afterTap: function(e){ console.log('afterTap', e); }, before: function(e){console.log('before', e); }, after: function(e){ console.log('after', e); }});Copy the code

Automatic event

Note that some of the events in the widget are automatically executed. For example, swiper will automatically execute the change event at a specified interval after setting autoplay to true.

implementation

Based on the WXA framework, we implemented the interception of all events in the form of plug-ins.

The WXA applets framework references webPack’s compile-time plug-in system based on tapable event streams to easily extend its functionality. Combining wXA compiler completion hook and HTMLPrase library, tamper the event function of WXML file and generate element ID. You can check @wxa/plugin-bind-hijack directly

Wxa applets framework

Wxa small program framework focuses on native development of small programs. While retaining the characteristics of simple entry and rapid development of small programs, it provides a series of capabilities to solve the pain points of engineering and code reuse, improve development efficiency and improve development experience.

After three years of polishing, the framework supports the rapid iteration and stable operation of multiple businesses in the line.

You are welcome to join the WXA community, where you can exchange your questions, suggestions, applets and front-end knowledge.

If the WXA framework feels good, please give WXA a Star~ the WXA team needs your support and encouragement!

⭐️ ⭐ ⭐️ ⭐️ ⭐️

GitHub Gitee

Project address: GitHub Gitee