Adapting the Taro Framework to Huawei HarmonyOS ArkTS: Runtime Adaptation Strategy and Implementation

The article begins by introducing Huawei's upcoming HarmonyOS (Harmony Next) and the need for Taro, a popular front‑end framework, to support the new ArkTS language framework.

Overall Approach : Similar to mini‑program adaptation, Taro adopts a runtime‑centric strategy, mapping its virtual DOM tree to corresponding ArkTS UI components at runtime, thereby avoiding extensive compile‑time transformations.

Reasons for Choosing Runtime Adaptation :

Significant paradigm differences between React/Vue DSLs and ArkTS UI paradigms make compile‑time conversion error‑prone.

The runtime approach can reuse parts of the existing mini‑program runtime and compile logic, accelerating HarmonyOS support.

Design of the Runtime Strategy : Simulate a browser environment (BOM and DOM) within HarmonyOS so that React, Vue, and other web libraries can run unchanged. This involves creating classes such as class TaroElement extends TaroNode { ... } to represent virtual DOM nodes.

Integration via Reconciler : A custom host config separates framework‑side node operations from platform‑side logic, allowing React’s reconciler to manipulate the simulated BOM/DOM.

Bridge to ArkTS : After the virtual DOM tree is built, it is passed to the HarmonyOS page entry, where ArkTS recursively renders native components based on the node tree. Example entry code: @Entry @Component struct Index { @State node: TaroElement = new TaroElement("Block"); build() { createNode(this.node); } }

Page Update Mechanism : Event handlers (e.g., .onClick((e) => eventHandler(e, 'click', this.node)) ) propagate user interactions back to the virtual DOM, triggering state updates and re‑rendering through observed decorators.

Data Structure Conversion Flow : The process consists of three stages – (1) framework code produces a Fiber tree, (2) the reconciler converts it to Taro’s virtual DOM, (3) ArkTS’s createNode recursively creates native UI components.

Component and API Implementation : Each React host component maps to a TaroElement and an ArkTS component; APIs are re‑implemented using HarmonyOS native APIs and exposed on Taro’s global object.

HarmonyOS Platform Plugin : Taro introduces @tarojs/plugin-platform-harmony to handle compile‑time configuration, lifecycle adjustments, and injection of compiled components and APIs.

Build Process : Taro uses Vite to bundle the project, performing half‑compilation for JSX, TypeScript/JavaScript transpilation, CSS‑to‑style‑attribute conversion, and generation of entry .ets files based on app.config.js . Glue code links React components with ArkTS pages.

Limitations : Current limitations include style parsing restrictions (no CSS cascade, only class selectors, no cross‑file styles) and missing implementations for certain mini‑program APIs and components on HarmonyOS.

Usage Example : A simple React‑based HarmonyOS demo shows how to write Taro components, enable half‑compilation mode, and handle events. Performance testing indicates a ~300 ms overhead compared to native, with future optimizations targeting 100‑200 ms.

Conclusion and Outlook : The runtime‑centric adaptation successfully enables Taro to run on HarmonyOS, with plans for dynamic module loading, native‑hybrid compilation, and continued community‑driven improvements.