Event System
Events are the interaction method between internally encapsulated logic and custom logic in page/component instances. When an event is triggered, the logic layer executes the corresponding handler function based on the response bound to the event.
In WeDa, Event Flow is a collection of actions chained together through various rules. Event Flow is divided into two types: inline event flow and independent event flow.
- Inline event flow: An event flow embedded within component or page events, triggered by bound events, not reusable, and without independent reference.
- Independent event flow: Independently defined event flows that are reusable. By default, they are referenced via instances like
$w.eventflow1and require manual triggering via$w.eventflow1.trigger().
The event Object
In the context of the handler function, the special event object is used to access information related to the current event. event.detail represents the data carried by the current event, which varies across different events.
event
| Property | Description |
|---|---|
| detail | Extra data carried by the event, determined when the event is triggered, and varies across different events |
Event Scheduling Logic
Event handling, besides binding a single handler function, can also implement simple workflow scheduling. For example, the following configuration:
{
"listeners": [
{
"id": "wgdu718n1n8",
"eventName": "tap",
"type": "platform",
"handler": {
"name": "showLoading",
"module": "platform",
"params": {}
}
},
{
"id": "wop5v6q51hg",
"eventName": "wgdu718n1n8.success",
"type": "platform",
"handler": {
"name": "navigateTo",
"module": "platform",
"params": {
"mode": "weDa",
"packageName": "",
"pageId": "u43or8cdj0g",
"params": {}
}
}
},
{
"id": "wecc06m9th8",
"eventName": "wop5v6q51hg.success",
"type": "rematch",
"handler": {
"name": "delay",
"module": "index",
"params": {}
}
},
{
"id": "wf23d9rgp7g",
"eventName": "wecc06m9th8.success",
"type": "platform",
"handler": {
"name": "showModal",
"module": "platform",
"params": {
"cancelColor": "#000000",
"cancelText": "Cancel",
"confirmColor": "#576B95",
"confirmText": "Confirm",
"content": "Please enter the pop-up content",
"showCancel": true,
"title": "Pop-up Title"
}
}
}
]
}
- Multiple different handler functions can be bound to the same event. These functions are invoked concurrently in sequence when the event is triggered, with multiple handlers for the same event not blocking each other.
- When an event (using the above tap event as an example) bound to a handler function (showLoading with id wgdu718n1n8) is triggered, it will fire either the
wgdu718n1n8.successorwgdu718n1n8.failevent based on whether the current function executes successfully. On success, theevent.detailcontains the return value of the handler function (showLoading); on failure, it contains an error object. Workflow scheduling is accomplished through this success/failure branching and chained serial invocation of events. - Since asynchronous methods may exist in the invocation chain, the page lifecycle state might change during execution (e.g., page navigation occurs). When the current page is no longer active, the invocation chain terminates after completing the current task. This means each event handler node verifies whether the page is active before execution. If inactive, processing halts immediately without triggering subsequent success/failure events.
Event Handling handler
In event handling nodes, processing methods can be defined. Custom processing methods (handler) are entirely defined by developers. Custom handler methods, after properly defining input parameters and return values, can also propagate event flows.
A typical handler function takes two parameters: event and data. Here, event.detail contains either the event data or the return value/exception from the previous processing node, while data.target represents the input parameters configured in the event panel. When the handler function returns content normally, the next node in the success branch is triggered. Conversely, when the handler function throws an exception, the next node in the failure branch is activated.
For example, assuming there are three action nodes of custom methods in the event flow: function1/successHandler/failHandler, with the invocation relationship being: execute successHandler when function succeeds, and execute failHandler when it fails. The code is as follows:
export default async function ({ event, data }) {
const result = await fetch("http://example.com/movies.json").then(
(response) => response.json()
);
if (result.code) {
// Throw an exception when the interface returns an error
throw new Error(result.message);
// return Promise.reject(result); // Promise.reject will also trigger the exception branch
} else {
// Returns normally
return result;
}
}
If successHandler has additional input parameters params bound, then event.detail represents the return value from the previous node function1, and data.target corresponds to the additional parameter params.
export async default function ({ event, data }) {
const result = event.detail; // event.detail points to the return value of the previous node
const params = data.target; // data.target points to the additional input parameters of the action node
console.log('done', result, params);
// ... Successful processing procedure
}
When function1 throws an exception, event.detail in failHandler contains the exception information from function1.
export async default function ({ event, data }) {
const error = event.detail; // event.detail points to the error information of the previous node
const params = data.target; // data.target points to the additional input parameters of the action node
console.log('fail', error, params);
// ... Failure handling procedure
}
Stop Event Bubbling
When the event is a bubbling event (e.g., click-tap), you can set to stop event bubbling at the location shown in the figure below.
