chungguo

In the article "Three Questions in the Career of a Front-end Engineer", the importance of "tools" was mentioned. Today, I will use a browser extension developed last year as an example to briefly explain the specific practices in this area.

1. Background#

In the work environment, reports are a common form of business. Managers need reports to understand the company's operating status, finance needs reports to grasp the details of income and expenses, and product operations need reports to understand user data. From an abstract level, all reports are the combination of data and presentation.

In other words:

$Report = Dynamic Data (Backend) + Various Chart Presentations (Frontend)$

As shown in the figure below:

From the implementation perspective, the client formats the filtering conditions set by the user on the interface into specific query statements, which are then processed by the backend. After the data is returned to the client, the client formats the structured data according to the display requirements and presents it to the user.

It can be seen that the technical model on the client side is not complicated. The complexity faced by the client comes from:

• How to abstract the common business process model
• The variety of reports leads to a large number of pages
• The data transmitted between the front and back ends is diverse in format and the data processing process is personalized

Once the number of reports increases, for example, there are more than a hundred reports, and with the passage of time and personnel changes, the current maintainers often do not know the details of the front-end and back-end data exchange protocols and formatting rules. This can be said to be a sudden increase in the maintenance cost of the front-end pages. A lot of manpower is spent on troubleshooting errors caused by parameter passing or value types. Therefore, if there is a tool that can quickly see the data sent by the front end to the back end and the values obtained when rendering the page, it can reduce the cost of problem troubleshooting to some extent.

2. Goal#

After clarifying the current problems, the next step is to determine a specific goal. For the small problem described above, the goal is very clear: to provide a tool or platform to help developers quickly view the specific request parameters and rendering values of the current report.

3. Solution#

The first thing that comes to mind is to intrusively add specific identifiers or name according to certain conventions to the page components, and then read the corresponding information externally. However, this approach is too intrusive and is undoubtedly adding insult to injury for business pages that already have frequent bugs and fragile developers. Therefore, codeless intrusion has become the primary premise of the solution.

Those who use React must be familiar with React Devtools. In the Component panel, we can clearly see the component hierarchy of the page and the props corresponding to each component. This is the inspiration. I thought that there must be some connection between the DOM and React Component to achieve the mapping from DOM to Component and from Component to DOM. If we can get the Component, we can also get all the information about the component. And it is codeless intrusion.

Then, in the source code of React, I saw the operation of generating key using random strings. Opening the console, sure enough, we found this mapping relationship.

As shown in the figure above, each React DOM element contains an attribute starting with __react (which varies depending on the version of ReactDOM), which stores the VirtualDOM or FiberNode information of the current DOM. According to the definition of FiberNode, the memoizedProps stores the props used to render the current element.

With this mapping relationship, we don't need to care about the business and the processing process of React on the outer layer, only the final generated DOM result, because the correctness of the result is what we care about the most. Then, the remaining task is to handle specific business scenarios, which becomes easier.

For example:

• The final implementation is still achieved through a browser extension, but the browser extension and the page are not in the same execution environment, so it is unable to read DOM properties. At this time, we choose to inject a JS script into the page through the extension and pass data through an event mechanism.
• Different versions of React have slight differences in handling.
• When obtaining the table header, the header is nested, so the nested header needs to be handled.
• Timing issues, the React Component instance needs to be reacquired whenever the data changes to obtain the latest values. In the page, the data changes are caused by requests, so in the extension, network requests are monitored to achieve data synchronization.

The final effect is as follows:

Here, only the specific ideas are explained. With these ideas and specific practices, this approach is also being used in the current leading automated testing. I will explain them one by one when I have time.