DEV Community: xiaoyao-yao

After obtaining the NEXT-Data data from the AppStore, the HarmonyOS NEXT-Data data is found to be the same data

xiaoyao-yao — Fri, 27 Jun 2025 05:23:11 +0000

I'm using

dataTime.indexOf(Time)
to find the same data in the Date[] array,
I found that even though I know exactly that there is a value of the Data property in the dataTiem that is the same as the Time,
However, it gets -1 and the comparison is false.

Analyze the cause of the error:

Reference Comparison Mechanism Date is a complex data type (object) that compares the memory address of the object rather than the actual value when compared directly in JavaScript/ArkTS using === or indexOf. For example, even if the Timestamp of the Date object obtained from AppStorage is the same as that of the original object, it may be a different instance, resulting in indexOf returning -1. In the vernacular, it is a complex data type of Date[], when comparing, it will compare whether their addresses are the same, but will not compare their values, which is essentially caused by the difference between object reference comparison and value comparison, so how do we achieve it? Compare their values to get the results we expect.

The sample code is as follows:

Method 1: Use JSON

@Entry
@Component
struct Index {
@State dataTime: Array = []
@State Time: Date = new Date()
aboutToAppear(): void {
this.dataTime.forEach((item)=>{
console.log(''+Boolean(JSON.stringify(item)===JSON.stringify(this.Time)))
})
}
build() {

}
}

Use JSON.stringify() to compare Date objects, i.e. serialized strings

Method 2: Use the original method to compare, that is, use getTime() to compare timestamps

@Entry
@Component
struct Index {
@State dataTime: Array = []
@State Time: Date = new Date()
aboutToAppear(): void {
this.dataTime.forEach((item)=>{
console.log(Boolean(item.getTime()=== this.Time.getTime())+'')
})
}
build() {

}
}

Compare timestamps (numeric types) directly to avoid referencing issues. Efficient performance without the need to convert data types.

Method 3: Storage optimization

When persisting the Date type, the timestamp (number) is stored instead of the Date object.

Save to AppStorage
AppStorage.setOrCreate('lastLogin', new Date().getTime());

Read and convert to Date
const timestamp = AppStorage.get('lastLogin');
const lastLogin = new Date(timestamp);

Note that this only applies to simple Date objects, and may not be valid if the object contains other attributes. Performance is low, and frequent operations may affect rendering.

You can choose the right way according to your needs.

HarmonyOS NEXT-HMRouter, the problem cannot be jumped after using router

xiaoyao-yao — Fri, 27 Jun 2025 05:22:30 +0000

The author uses a third-party library @HMRouter to build a three-layer architecture (basic feature layer, product customization layer, and public capability layer) of HarmonyOS to complete the App, and when the cross-package jump is made, a strange bug is encountered when the login page enters the home page, after we use router.push() to jump, and then use HMRouter to jump to the page suddenly, so what should we do? , and now share the solution to the bug.

The sample error code looks like this:

import { router } from '@kit.ArkUI';

@Entry
@ComponentV2
struct LoginPage {
@State message: string = 'Hello World';
aboutToAppear(): void {
console.log('LifeCircle creation')
}
onDidBuild(): void {
console.log('The LifeCircle component is built')
}
onPageShow(): void {
console.log('PageShow')
}
onPageHide(): void {
console.log('Page - Page hidden')
}
build() {
Column(){
/The login page code is omitted/
}
.onVisibleAreaChange([1.0],()=>{
/Omit the login verification process*/
router.replaceUrl({url:'pages/Index'})
})
}
}

For the sake of convenience, when the author has logged in, he directly logged in to onVisibleAreaChange and jumped to the home page, and found that he couldn't jump to other pages using HMRouter, and there was no response when he clicked the jump button.

Analyze the cause of the error:

onVisibleAreaChange is a high-frequency triggered callback, if you jump directly here, the route status may be abnormal because the page is not fully initialized. (Page Lifecycle Conflict)

Solution:

Avoid jumping directly in onVisibleAreaChange and instead use explicit triggers (such as button clicks) or page lifecycle callbacks

For example, the following example code shows:

import { router } from '@kit.ArkUI';

@Entry
@Component
struct LoginPage{
@State message: string = 'Hello World';
aboutToAppear(): void {
router.replaceUrl({url:'pages/Index'})
console.log('LifeCircle creation')
}
onDidBuild(): void {
console.log('The LifeCircle component is built')
}
onPageShow(): void {
console.log('PageShow')
}
onPageHide(): void {
console.log('Page - Page hidden')
}
build() {
Column(){
}
}
}

In aboutToAppear, just redirect to our page.

Actual result: After jumping to the homepage in the page lifecycle callback, HMRouter can jump to the page normally. The bug was successfully fixed.

Harmony NEXT-Difference between State Management V1 and State Management V2

xiaoyao-yao — Fri, 27 Jun 2025 05:16:18 +0000

In V2, there is no @link to bind parent and child components in both directions. Therefore, we need to @Event the events of the parent component in the child component to implement the decoration callback (in the vernacular: the child component calls the function of the @Event decoration, passes in the parameters, and modifies the parameters in the parent component). In the parent component, pass in the function to the child component, note that we need to use the arrow function to wrap the function we write to the event, to ensure that the this of the event we pass in is not empty. @Event can only be used in components that @ComponentV2 decoration Sample code:

@Entry
@ComponentV2
struct Index {
@local title: string = "To be modified";

build() {
Column() {
Child({
changeFactory: () => {
this.title="Revised"
}
})
}
}
}

@ComponentV2
struct Child {
@Event changeFactory: () => void = () => {};
build() {
Column() {
Button("Change the title")
.onClick(() => {
this.changeFactory();
})
}
}
}

The @State in V1 has been transformed into @local @State decorator is not aware of initialization from the outside The name has changed, but the writing is still the same, but @local cannot be mixed with the @Observed decorated class instance object. Everything else is the same: For example, when decorating simple type arrays and value types, you can observe changes in the array as a whole or in the array items and changes in the value type.

3.@Watch is @Monitor in V2
In V1@Watch you can only listen to the changes in the first layer of attributes, while in V2, you can @Monitor and modify, and use @trace in the corresponding deep variables.
Simple implementation of the sample code:

@Entry
@ComponentV2
struct monitorExample {
@local apple: number = 0;
@Monitor('apple')
onFruitChange(monitor: IMonitor) {
console.log(apple changed from ${monitor.value()?.before} to ${monitor.value()?.now});
}

build() {
Column(){
Text(apple count: ${this.apple})
Button("add apple")
.onClick(()=> {
this.apple++;
})
}
}
}

Extend:

V1: Relies on decorator chains (such as @State @ObjectLink) to implement one-way data flow, and only supports the observation of the first-layer properties of objects. Nested objects need to encapsulate components layer by layer, and the code is redundant.

V2: Implements deep attribute monitoring through @ObservedV2 @trace, and supports attribute change detection (such as obj.a.b.c) of nested objects at any level, without the need for additional component encapsulation