User Pain Point：业务逻辑塞进 build导致难以维护

ts build { Column { if { Text.fontColor } else if { Text.fontColor } else { Text.fontColor } } }

This works but quickly becomes unreadable as page grows.

A more maintainable approach is to move presentation logic into computed helpers:

@Component
struct ScoreBadge {
@Prop score: number
private getLabel: string {
if return '优秀'
if return '通过'
return '待提高'
}
private getColor: string {
if return '#0A7F38'
if return '#B7791F'
return '#C53030'
}
build {
Text)
.fontSize
.fontColor)
.padding
.borderRadius
.backgroundColor
}
}


The order of chainable setters usually does not affect final result,but a consistent order improves readability and makes code reviews smoor.




从Sizing来看。width,height,constraintSize 

Padd ing & margin : padding,margin 

L ayout : layoutWeight,alignSelf,justifyContent,alignItems 

T ext :  fontSize,fontWeight,fontColor,maxLines 

A ppearance : backgroundColor,borderRadius,border,shadow 

I nteraction : enabled,onClick,onChange 


An example following this convention:
 Button
.width
.height
.margin
.fontSize
.fontWeight
.backgroundColor
.borderRadius
.onClick =>{ this.submit} )


The biggest advantage of declarative UI appears when state changes. Below is a simple counter page:
 @Entry @Component struct CounterPage {
@State count:number=0
build{
Column{
Text
.fontSize
.fontWeight
Row{
Button
.onClick=>{
if{ this.count-- }
})
Button
.margin
.onClick=>{ this.count++ })
}
.margin
}
.width
.height
.justifyContent
.alignItems } }

The @State field belongs to component’s internal state. When /count changes,any UI that references it automatically refreshes—no manual find‑and‑update needed.












You can bind events via .onClick,.onChange,etc. Keep handler itself tiny;push complex logic into a dedicated method.
ts
Button
.onClick=>{ this.saveProfile })
private saveProfile: void{
const name=this.name.trim
if{
this.message='请输入昵称'
return
}
this.message='保存成功'
}

This separation gives two benefits:







ts
@Entry @Component struct LoginPage {
@State account:string=''
@State password:string=''
@State message:string=''
@State loading:boolean=false
private canSubmit:boolean{
return this.account.trim.length>0 && this.password.length>=6 &&!this.loading
}
private submit:void{
if){
this.message='请填写账号，并输入至少6位密码'
return
}
this.loading=true
this.message='正在登录...'
setTimeout=>{
this.loading=false
this.message='登录成功'
}。1500)
}
build{
Column{
Text
.fontSize
.fontWeight
.width
 TextInput
.width
.height
.margin
.onChange=>{ this.account=v })
TextInput
.type
.width
.height
.margin
.onChange=>{ this.password=v })
Button
.width
.height
.margin
.enabled)
// optional visual hint when disabled
.opacity?1:0.5)
.onClick=>{ this.submit })
if{
Text
.fontSize
.fontColor
.margin
.width
}


}
.width
.height
.padding
.justifyContent
.
backgroundColor
}
}



@State to keep page data.

.onChange.












ts
build{
Column{
if{
LoadingProgress
.
width
.height
}else if{
Text.fontColor
}else{
Text.fontColor
}
}.width.height.justifyContent.alignItems
}


User Pain Point： Repeatedly checking same flag across many branches leads to tangled logic. Abstract page states into a clear enum to keep branches orthogonal.





Pain Point： All‑in‑one pages become “god functions” once y exceed a few hundred lines;maintenance time explodes.











Example – extracting a primary button:

ts
@Component
struct PrimaryButton{
@Prop text:string
@Prop disabled:boolean=false
从onTap来看。=>void==>{}

build{
Button
.
width
.
height
.
enabled
.
opacity
.
backgroundColor
.
borderRadius
.
onClick=>{ this.onTap })
}
}


Usage in login page:

ts
PrimaryButton({
从text来看，this.loading?'提交中...':'登录',disabled:!this.canSubmit,onTap:=>{ this.submit}
})






在 build 中修改状态"

Pain Point： Modifying @State inside  creates an infinite render loop because every render re‑executes modification.

ts
// ❌ Bad – will cause endless re‑rendering
build{
Column{ Text }
// illegal state change inside build:
this.count++
}


Solve it: Only change state inside events。lifecycle callbacks or async responses.

把样式和业务判断混在一起"

ts
// ❌ Overly complex one‑liner:
Text
.
fontColor


Simplify: Extract display logic into getters.

ts
private displayName:string{
return this.userInfo?.name，?'未登录'，}
private nameColor:string{
return >5?'#B7791F' : '#666666';}
...
Text).fontColor)


过早抽象通用组件"

Pain Point：Creating “mega‑components” before you actually need m leads to bloated APIs and steep learning curves for teammates.

A pragmatic approach: First finish page,spot repetition。n extract a component with a minimal interface.





entry/src/main/ets/
├── pages/
│   └── LoginPage.ets
├── components/
│   ├── PrimaryButton.ets
│   ├── FormField.ets
│   └── StateTips.ets
├── models/
│   └── UserProfile.ets
└── services/
└── AuthService.ets



Pages handle composition & high‑level state.Components focus on presentation & local interaction.Services encapsulate business flow & external API calls.






The core of learning ArkUI isn’t memorizing every component property—it’s mastering a clean page organization workflow:


The page is a tree of components.build only describes what UI looks like under current state.@State changes automatically trigger UI refresh.Event handlers stay short;business logic lives in well‑scoped methods.Component extraction serves reuse & readability—not premature abstraction.

If you internalize se fundamentals first,moving on to lists,animations。cross‑page state management or complex architectures will feel like building on solid ground rar than stacking endless components.