test

[wumail]

The new idea of Zero Code: LogicFlow-based Page Logic Organization
Introduction
In DiDi's customer service business, the zero-code approach to configuring pages has led to a rich landing experience, significantly enhancing service efficiency and quality for users. However, traditional zero-code logic configuration for pages has limitations in terms of flexibility and expandability.

Therefore, DiDi's customer service technical team has embarked on a novel approach that arranges page logic using a process-oriented methodology, aiming to overcome the challenges of inflexible zero-code expansion. This article delves into the complexities of configuring intricate interactions, presents solution concepts and strategies, and elaborates on leveraging the LogicFlow flowchart editing framework – an open-source tool developed by the customer service technical team. It explains how LogicFlow facilitates the realization of scheduling, execution, and debugging stages in the research and development lifecycle.
Contexts
The customer service business acts as a bridge connecting users and various business divisions within the company. To swiftly adapt to evolving business needs and continuously enhance user service experiences, the technical team needs to empower customer service operations by configuring a suite of systems that ensure efficient and high-quality services.

To facilitate allocation for operational staff, the zero-code platform's drag-and-drop interaction proves highly suitable. Through WYSIWYG (What You See Is What You Get) design, numerous scenarios for customer service have been facilitated. Several systems now enable operations teams to alter logic online via configuration releases, providing users with intelligent customer service or allowing human agents to follow predefined processes to address and record user issues.

Over the span of four years, DiDi's Customer Service has configured over 12,900 PC pages and 7,900 H5 pages across the service chain.

Dilemma: Limitations of Zero-Code Approach
Despite the significant utilization of zero-code configuration in DiDi's customer service platform, its inadequacies have become apparent with business growth. Consider a scenario where a form modification operation necessitates clicking a column within the form to initiate a user rights verification request. Based on the permissions returned, a corresponding editing popup window is displayed. The following table outlines this modification process:

When faced with this scenario, utilizing the conventional zero-code solution would require embedding requests and popup-related logic within the form component's properties panel. This iterative way of adding functionality in the component properties panel will only lead to bloated configuration content, increased configuration difficulty, and higher development costs, and in the end, it is not as convenient as writing code.

As zero-code configuration pages are widely used within customer service, the customer service technical team also expects to find a better way to solve the problem of zero-code not flexibly controlling the page logic and complex interactions. This pursuit aims to enable even non-programmers to handle complex page interactions.

Idea: Logical Page Organization
For the aforementioned table editing requirements, traditional JS coding involves event listening -> data collection -> requests -> result interpretation -> component modification.
. Can we abstract this coding process into a simplified logic and implement it using a process-based approach?

Using this idea, the previous requirements will be split into: "Form triggers edit event," "Request permission," "Display standard administrator edit popup," and "Display advanced administrator popup." These stages are then visualized in a flowchart, as depicted below:

The image above showcases our internal zero-code configuration page for basic form system configuration. The left side employs drag-and-drop mechanisms, akin to most zero-code platforms. The right side, however, is configured through a flow-based approach to enable complex logic sequencing within the page.
By using the flow to organize the page logic in this way, we achieve flexible configuration by seamlessly combining nodes. For example, when the request interface responds sluggishly, a "Form loading" node could be inserted prior to the request node.

Furthermore, this methodology can be extended to facilitate component visibility toggles. For instance, if "Radio box A" selects "a1," "Component B" is displayed while "Component C" is hidden; and if "Radio box A" selects "a2," the reverse occurs. This can be divided into five nodes: "Radio box value change event", "Show Component B", "Show Component C", "Hide Component B" and "Hide Component C" with conditional connections.

As you can see from the above introduction, the problem of difficult scaling in zero code can be better solved by abstracting the changes of each component in complex interactions into a unit logic and then reflecting it with node choreography in the flowchart. Next, we will introduce you to the core capabilities of page logic orchestration and demonstrate how to develop, run, and debug page logic orchestration.
Program: Three Core Competencies for Logical Page Layout
To transform process orchestration into a code-free alternative, we've implemented three core components: organizer, executor, and debugger. These components cater to development, runtime execution, and debugging stages respectively.

Since the whole process is realized around the flowchart, there are many special requirements for the flowchart function. As our team has a lot of precipitation in flowchart editing, and open source flowchart editing framework LogicFlow, we can quickly achieve a variety of core capabilities in the page logic arrangement with LogicFlow's powerful customization capabilities.
The overall architecture of LogicFlow is as follows, the core package @logicflow/core provides the basic capabilities of the flowchart editor, and @logicflow/extension on the right is a plug-in developed based on the extensibility of @logicflow/core.

Organizer
In the traditional development mode, the product of development is JS code, but now the process organization is used as the visualization development, the product of development becomes JSON data describing the flowchart. Since the flowchart is mainly composed of nodes and lines, the orchestrator also customizes the nodes and edges to achieve the page logic organization function.
Custom Nodes
The flowchart of the organizer supports the configuration of many types of nodes, including event nodes, data nodes, behavior nodes, jump nodes, and so on. Each node represents a most basic page logic unit, for example:
Event nodes: Analogous to JS event listeners.
Data nodes: Simulate AJAX requests.
Behavior nodes: Modify page component properties.
Jump nodes: Represent browser navigation.

LogicFlow's custom HTML nodes can be used to achieve diverse functional nodes. In the organizer, features like highlighting, hover buttons, and tooltips enhance the "development" experience and can be perfectly supported by LogicFlow's custom HTML nodes.

When customizing the HTML node, you can override the setHtml method of the HTML node to customize the HTML content by mounting a vue or react component. The code example is as follows:

The specific content of the node is written in Vue, and the writing method is unchanged, you can also use the UI component library directly, the sample code is as follows:

Custom Connectivity
In the organizer, connections dictate the sequence of node execution. By default, the connection indicates that the execution of the previous node completes and continues to the next node. You can interrupt the execution of a process by configuring conditions on the threads, which is similar to the logic judgment function in JS code.

How can we implement the display of small conditional icons on the connecting line?
Using LogicFlow to implement linking in the orchestrator is a bit more complicated, as the linking does not need to display text, but an icon with a popover instead. So we need to use LogicFlow's custom linking mechanism to override the default text logic and replace the text with an icon.

Usually, LogicFlow's text is the SVG element, so when we need to provide more HTML content on top of it, we can use LogicFlow's customization mechanism based on inheritance overriding to reimplement the text. The above code example overrides the getText method and inserts a foreignObject into the SVG to nest the HTML content inside the SVG.

Executor
Page logic organization relies on flowchart-based configuration, to let the flowchart run in accordance with the logic of the organization, the most common method is to use the flow engine. While many process engines operate server-side (e.g., Activiti, Flowable, Turbo), they are unsuitable for browser-based logic execution. Hence, we developed the LogicFlow Engine to operate within JavaScript environments, and then implement an executor based on this process engine.
Capability 1: Support for multiple types of nodes
The executor encompasses various node types, such as event nodes, behavior nodes, data nodes, transformation nodes, and page jump nodes—each serving a distinct purpose.

Although LogicFlow Engine has only a built-in start node and task node, we can inherit these nodes to implement customized business logic. For example, if we implement the Executor Request Data node, we can rewrite the action method of the Task node and implement the logic of requesting data in the method content.

Capability II: Support for concurrent execution
When organizing logic, it is a frequent case that multiple things have to be done at the same time after a single event. For example, when a button is clicked, a request is made to update the data, but also to update some text on the page. It is more "intuitive" for most people to use a branching configuration, and the executor needs to support this "concurrent" execution.

This feature requires gateways to be parallel gateways by default, when one node execution is completed, it will execute all the following nodes in a non-blocking way, for example, the execution order of the above figure is search click->request data and update text->update data.

The above code is the LogicFlow Engine's internal logic that supports parallel gateway by default. If you want to realize an exclusive gateway, you can rewrite the getOutgoing method of the node.
Capability 3: Support for multiple start nodes
In most cases, a page will have multiple components that can bind events. So when logic is organized, there will also be multiple event nodes on a flowchart. In an executor, the event node is the starting point for the process to begin execution, which requires LogicFlow Engine to support the existence of multiple start nodes on a flowchart.

LogicFlow Engine not only supports multiple start nodes for a flow but also supports specifying the start of execution from any node in the flow and re-execution from an already executed node. For example, in the executor, when a component of a page triggers an event, the executor will find the corresponding node of this component and start execution from this node.

Competency 4: Process Duplication
Inside the form, we will often encounter the need to select different contents and display different components. For example, when selecting a1 for checkbox A, set component B to show and component C to hide; when selecting a2 for checkbox A, set component C to show and component B to hide.

In order to satisfy the user's incessant switching of radio box options, the process engine needs to be able to execute it repeatedly.

LogicFlow Engine supports multiple executions of the same process instance.

Debugger:
The use of organizers and executors enables the visual organizing and execution of page logic. However, even though visual "development" reduces the difficulty of "code", we will inevitably encounter errors. Therefore, we also provide a debugger that allows us to run and check the page logic directly without modifying the code.
Functionality Overview:

1. Running Records: Triggering an event node generates a runtime record, visually displaying process nodes invoked by each operation.
   
2. Element Details: Clicking on an executed runtime node displays runtime content details, including element data and error causes.
   
3. Page Data: Global data includes dynamic data generated by the current page, assisting troubleshooters in resolving page errors.

In Conclusion:
The approach outlined above to achieve the page logic arrangement and execution, effectively addresses the challenges of traditional zero-code expansion limitations, and we can encapsulate a simpler scheduler based on this architectural design to ensure scalability and reduce the maintenance costs of the system itself.

It’s certain that there are many other challenges in the field of zero-code that need to be solved, such as data sources, complex algorithms, data conversion, etc. There is a lot of good practice in our team, and still polish and refine based on the actual use. We are working hard to open-source the entire zero-code platform, but still striving and waiting for the right time, so we will not continue to be introduced here.

In addition, we have open-sourced LogicFlow Engine as a module of LogicFlow to the official code repository, so you can try to use it to realize your own page logic arrangement and execution. If you have any questions, please send us your feedback via issue. LogicFlow Engine can be used in many different scenarios not just page logic execution.
You are welcome to send us issues and PRs through the official LogicFlow code repository:
LogicFlow GitHub address: https://github.com/didi/LogicFlow
LogicFlow Official Website: https://site.logic-flow.cn/
Turbo GitHub address: https://github.com/didi/Turbo

You can also add LogicFlow's official WeChat account: logic-flow, which will invite you into the WeChat user group. Or scan the QR code below to enter LogicFlow's QQ user group.