Designing a Cross‑Language Event System for Taro on HarmonyOS

Based on the Taro framework, the JD Harmony app has entered public testing with Harmony Next, and this third article in the series dives into the technical details of designing a universal event system for multi‑language scenarios.

Although native Harmony applications are typically written in ArkTS, developers discovered that using C++ can significantly boost the performance of both the framework and business logic. As Harmony evolves, collaboration across different language environments (C++, ArkTS, JavaScript) has become essential.

Taro integrates with Harmony by accessing the C-API , moving component rendering and layout logic down to the C++ layer, which greatly improves page rendering speed.

Consequently, a robust event system that enables efficient communication between C++, ArkTS and other languages is a critical requirement for Taro.

In the Harmony adaptation, the event system serves a dual role: it drives the lifecycle of applications, pages and components, and acts as a bridge that allows JavaScript to invoke native ArkTS capabilities.

Designing a cross‑language event‑driven architecture requires careful handling of the constraints and runtime differences of ArkTS, JavaScript and C++. The goal is to ensure ordered, high‑performance event propagation across these environments.

By implementing the core event logic in C++ and exposing it through the C-API , Taro can dispatch events to the appropriate language runtime, maintaining order and efficiency.

The event system has evolved from a simple implementation in early ArkTS versions to a more sophisticated design, addressing performance bottlenecks such as slow event bubbling and main‑thread blocking.

Moving event handling to the C++ layer and executing it on background threads improves execution efficiency and prevents UI stalls.

When building the multi‑language event system, Taro must manage various event types—including common component events, gestures and custom events—through an eventCenter that queues and asynchronously distributes events.

The eventCenter runs on a background thread, registers system and lifecycle events, and provides robust error handling to help developers locate and resolve callback issues.

Developers can create listeners in C++ or ArkTS, add callbacks to the event queue, and rely on automatic parameter conversion so that each language runtime receives data in the correct format.

Note that events registered in the ArkTS environment must return to the main thread, and Symbol‑type events are not supported on Harmony.

Node‑level events follow the standard DOM propagation model: events travel from the root to the target node and then bubble back up, and Taro mirrors this behavior to give front‑end developers a familiar experience.

Three main node event categories exist—Harmony events, Harmony gesture events and custom events—each listened on TaroElement via a Receiver , with RenderNode handling the first two.

During propagation, each node can stop bubbling, allowing fine‑grained control over business logic.

Event callbacks attach standard properties such as target , stopPropagation and value to the event object, ensuring consistent behavior across language boundaries.

In summary, ensuring consistent cross‑language event transmission enhances maintainability and performance; the current solution improves response speed and module collaboration, while future work may involve TurboModule integration and deeper multi‑language coordination.