An Overview of ArkTS: Origin, Evolution, Declarative UI Paradigm, and State Management

Preface: The previous article "HarmonyOS Learning Part 1 – Understanding DevEco Studio" introduced the DevEco Studio development tool. After mastering the tool, this article introduces the HarmonyOS development language ArkTS.

1. ArkTS Introduction

Origin: Mozilla created JavaScript (JS), Microsoft created TypeScript (TS), and Huawei further launched ArkTS (Ark: Ark).

1. Origin

JavaScript (JS) was created by Mozilla as the foundation of web development.

TypeScript (TS) was created by Microsoft to enhance JS with a type system and improve maintainability.

Front‑end frameworks such as React.js and Vue.js introduced declarative UI and reactive programming.

2. Evolution of TypeScript

TS introduced a type system and type checking, improving code maintainability and error detection.

Declaration files support interfaces and custom types, enhancing module collaboration.

TS provides editors, compilers, and IDE plugins that boost development efficiency.

TS is compatible with ECMAScript, allowing TS code to be compiled to pure JavaScript.

3. Evolution of ArkTS

Built on JS and TS, extending declarative UI development and state management for a more concise development experience.

Introduces an enhanced rendering engine with platform‑agnostic drawing, declarative UI backend design, and dynamic layout.

Optimizations include code pre‑compilation, efficient FFI, and engine minimization.

Provides cross‑OS infrastructure to support deployment on various devices.

4. Advantages and Innovations

Integrates the JS/TS ecosystem, allowing developers to use familiar languages and tools.

Declarative UI paradigm offers a simpler, more natural, and high‑performance development experience.

Rendering engine and runtime optimizations further improve performance across devices.

2. ArkTS Declarative Development Paradigm

The code example below (shown in the image) displays two text blocks and a button; clicking the button changes the text from "Hello World" to "Hello ArkUI".

The example consists of the following basic components:

Decorators : Used to annotate classes, structs, methods, and variables (e.g., @Entry, @Component, @State). @Component marks a custom component, @Entry marks the entry component, and @State marks a state variable whose changes trigger UI updates.

Custom Components : Reusable UI units that can compose other components, such as the struct Hello decorated with @Component.

UI Description : Declarative description of UI structure inside the build() method.

Built‑in Components : Default layout and UI components provided by the framework, e.g., Column, Text, Divider, Button.

Event Methods : Define response logic for component events, such as onClick() on a Button.

Property Methods : Configure component properties via chainable calls (e.g., fontSize() , width() , color() ).

3. State Management

1. Overview of State Management

In a declarative UI framework, the UI is the runtime result of the program state. When state parameters change, the UI re‑renders accordingly. In ArkUI, this mechanism is referred to as state management.

View (UI): Rendering performed in custom component build methods or methods decorated with @Builder .

State: Data decorated with state decorators. Changing state data triggers UI re‑rendering.

ArkUI Implementation

State variables: Decorated with @State; changes cause UI updates.

Regular variables: Used for auxiliary calculations; changes do not trigger UI refresh.

Data source / sync source: Original source of state variables, often passed from parent to child components.

Named‑parameter mechanism: Parents pass values to child components via named parameters (e.g., CompA: ({ aProp: this.aProp }) ).

Initialization from parent: Parent component can override default values of child component state variables.

@Component
struct MyComponent {
  @State count: number = 0;
  private increaseBy: number = 1;

  build() {
  }
}

@Component
struct Parent {
  build() {
    Column() {
      // From parent initialization, overriding local default values
      MyComponent({ count: 1, increaseBy: 2 })
    }
  }
}

2. Page‑Level Variable State Management

3. Application‑Level Variable State Management

AppStorage acts as a central "database" for the entire UI application state. The framework creates a singleton AppStorage object and provides decorators and APIs for usage.

@StorageLink : Establishes two‑way binding between a component property and AppStorage.

@StorageProp : One‑way sync from AppStorage to a component property.

AppStorage APIs allow adding, reading, modifying, and deleting state attributes, which automatically propagate to UI components.

PersistentStorage : Static methods for managing persistent data linked to AppStorage.

Environment : Singleton created at app launch, providing device‑level environment properties for AppStorage.

Reference Links:

"Analysis of ArkTS Origin and Evolution"

"Declarative UI Development Guide"

"State Management Overview"