做 HarmonyOS 7 页面时最容易把人绕进去的往往不是布局而是“这个值到底该放哪儿”。页面计数、加载状态与条件渲染 看起来只是几行代码真接进项目后经常会遇到 UI 不刷新、返回页面数据变旧、弹窗取消后值却被改掉或者一个请求失败把整个页面状态搅成一团。这篇不背概念。我就按项目里最常见的写法把State、普通变量与 UI 刷新的边界拆开讲。目标很简单代码能跑状态变化能解释出了问题知道先查哪儿。本文环境按 HarmonyOS 7 ArkTS DevEco Studio 的工程习惯组织。不同 API 版本如果有细节差异以你当前 SDK 的类型提示为准。1. 先说问题为什么这个状态值得单独管很多页面刚开始都很简单。一个变量一个按钮一个接口。于是我们很自然地把值全塞进组件里。功能一多问题就来了。比如 页面计数、加载状态与条件渲染。用户点一次你改一个变量接口回来再改一个变量页面切走回来又要恢复一次。只要其中某一步没有明确“谁负责修改、谁负责展示”状态就开始互相污染。我判断一个值要不要进入 UI 状态通常先问三个问题它变了以后界面要不要立刻跟着变它是不是只属于当前组件页面销毁后还需不需要保留这三个问题基本能过滤掉大多数乱用状态装饰器的情况。这里有个很实用的习惯业务数据和界面过程状态分开命名。数据是 data、list、detail过程状态是 loading、submitting、dialogVisible、error。别把一个布尔值既当“有没有数据”又当“是不是请求完成”后面一定难维护。2. 先写一个最小版本下面这段我故意写得短一点先把核心跑通EntryComponentstruct StateDemo{Statecount:number0Stateloading:booleanfalsebuild(){Column({space:16}){Text(当前数量${this.count})Button(加 1).onClick((){this.count})if(this.loading){LoadingProgress()}}.padding(20)}}这段代码最重要的不是语法而是状态变化路径。用户操作发生后只修改真正需要变化的状态UI 根据状态重新计算展示结果。这样调试时你可以沿着“事件 → 状态 → UI”往下找而不是在十几个回调里猜。实际项目里建议先把最小版本跑通再加接口、弹窗和缓存。很多人一上来就把所有逻辑堆进去最后报错时根本分不清是状态问题还是网络问题。3. 真正容易踩坑的是状态边界第一类坑是“能不用状态的值也做成状态”。例如一个只在点击事件内部使用的临时变量它不参与 UI 渲染就没必要为了保险全部声明成响应式状态。状态越多阅读成本越高也更容易出现无意义刷新。第二类坑是“同一个事实存两份”。比如列表长度本来可以从list.length得到又额外维护一个count。新增数据时改了 list忘了改 count页面马上出现两个答案。能计算出来的值尽量计算不要重复存。第三类坑是异步回来以后不管页面当前处境直接赋值。请求发出去时用户可能已经切换筛选条件旧请求后返回就可能覆盖新结果。真实业务里要么给请求带查询条件并在返回时校验要么统一做请求取消/序列控制。privaterequestSeq:number0asyncrefresh(){constseqthis.requestSeqthis.loadingtruetry{constresultawaitloadData()if(seq!this.requestSeq)returnthis.dataresult}finally{if(seqthis.requestSeq)this.loadingfalse}}这个小技巧很朴素但对搜索、筛选、分页这种连续请求特别有用。旧请求即使晚回来也没有资格覆盖最新状态。4. 把页面状态画出来代码会清楚很多如果一个页面已经出现五六个布尔值我建议先别继续写。拿纸画一下状态。比如请求页面通常就四种初始、加载中、成功、失败。弹窗则是关闭、编辑中、确认完成。布尔值最大的问题是可以组合出很多“不应该存在”的情况loadingtrue同时errortrue到底展示谁所以复杂页面可以直接用联合类型或枚举表达互斥状态。typeViewStateloading|content|empty|errorStateviewState:ViewStateloading渲染时只认这一份状态页面就不会同时冒出 Loading 和错误提示。这个思路比不停加条件判断好维护得多。5. 我在项目里会怎么拆我一般把页面分成三层。第一层是页面容器负责请求、路由和页面级状态第二层是业务组件只接收自己需要的数据第三层是纯展示组件尽量不碰网络和持久化。这么拆的好处不是为了“架构漂亮”而是改需求时少牵连。比如产品只改空状态样式你不应该碰请求代码接口字段调整也不应该顺手改弹窗显示逻辑。Componentstruct ContentPanel{Proptitle:stringPropdisabled:booleanfalsebuild(){Row(){Text(this.title)Blank()Text(this.disabled?不可操作:可操作)}.width(100%).padding(16)}}子组件只拿它需要的东西。不要图省事把整个巨大对象传进去再让组件内部到处读字段。字段依赖越隐蔽后面越难判断哪个变化会引起哪个组件更新。6. 调试时别只盯着 UI状态类问题有个特点界面表现是结果真正的原因往往发生在前面。所以我会在关键状态入口打日志而不是每一行都打。建议至少记录操作名、请求序号、旧值和新值。functionstateLog(name:string,before:object,after:object){console.info([state]${name}before${JSON.stringify(before)}after${JSON.stringify(after)})}如果第二次点击没有反应就先确认点击事件有没有进进了以后状态条件是不是把逻辑提前 return再看异步请求有没有真正发出。这个顺序比一上来清缓存、重装模拟器靠谱得多。7. 再补一个完整一点的处理方式真实页面里我更喜欢把一次操作包成一个完整方法入口校验、切换过程状态、执行业务、处理异常、最后恢复。这样按钮事件本身很薄。asynconQueryClick(){if(this.loading)returnthis.loadingtruethis.errorTexttry{constresultawaitthis.queryService()this.applyResult(result)}catch(err){this.errorText操作失败请稍后重试}finally{this.loadingfalse}}finally很关键。成功、失败、提前抛异常最终都要把 loading 收回来。项目里那种“第一次能点第二次永远没反应”的问题经常就是某条异常路径没有恢复状态。另外不建议为了让 UI 立即变化到处加延时。setTimeout能暂时把问题藏起来但它没有解决状态归属和执行顺序。除非业务真的需要延时否则先查数据流。8. 再往真实项目推进一步页面状态不是孤立的。真正的项目还会碰到返回页面是否重新请求、多个组件是否共享同一份筛选条件、缓存和网络谁先展示、快速重复点击如何防抖等问题。处理这些问题时不要先问“该用哪个装饰器”先问数据生命周期谁创建、谁修改、谁消费、什么时候失效。如果一份数据只服务一个局部组件就尽量留在局部如果父组件需要控制子组件就让依赖方向清晰如果需要跨页面长期保存再考虑持久化或更高层的数据模型。把生命周期想明白以后API 反而是最简单的一步。9. 这一篇记住什么回头看State、普通变量与 UI 刷新的边界核心其实就几句话需要驱动 UI 的值才进入响应式状态同一个事实尽量只有一个数据源异步结果要防止旧请求覆盖新状态复杂页面用明确的状态枚举替代一堆互相打架的布尔值组件只接收自己真正需要的数据。你可以拿手上的一个 HarmonyOS 7 页面做个小练习把所有State列出来逐个问“它变化后真的需要刷新 UI 吗”“这个值能不能从别的状态算出来”“页面离开以后还要不要它”。通常扫一遍就能删掉一批没必要的状态。下一篇继续往真实项目里走不讲虚的直接处理下一层状态协作问题。
做 HarmonyOS 7 页面时最容易把人绕进去的往往不是布局而是“这个值到底该放哪儿”。页面计数、加载状态与条件渲染 看起来只是几行代码真接进项目后经常会遇到 UI 不刷新、返回页面数据变旧、弹窗取消后值却被改掉或者一个请求失败把整个页面状态搅成一团。这篇不背概念。我就按项目里最常见的写法把State、普通变量与 UI 刷新的边界拆开讲。目标很简单代码能跑状态变化能解释出了问题知道先查哪儿。本文环境按 HarmonyOS 7 ArkTS DevEco Studio 的工程习惯组织。不同 API 版本如果有细节差异以你当前 SDK 的类型提示为准。1. 先说问题为什么这个状态值得单独管很多页面刚开始都很简单。一个变量一个按钮一个接口。于是我们很自然地把值全塞进组件里。功能一多问题就来了。比如 页面计数、加载状态与条件渲染。用户点一次你改一个变量接口回来再改一个变量页面切走回来又要恢复一次。只要其中某一步没有明确“谁负责修改、谁负责展示”状态就开始互相污染。我判断一个值要不要进入 UI 状态通常先问三个问题它变了以后界面要不要立刻跟着变它是不是只属于当前组件页面销毁后还需不需要保留这三个问题基本能过滤掉大多数乱用状态装饰器的情况。这里有个很实用的习惯业务数据和界面过程状态分开命名。数据是 data、list、detail过程状态是 loading、submitting、dialogVisible、error。别把一个布尔值既当“有没有数据”又当“是不是请求完成”后面一定难维护。2. 先写一个最小版本下面这段我故意写得短一点先把核心跑通EntryComponentstruct StateDemo{Statecount:number0Stateloading:booleanfalsebuild(){Column({space:16}){Text(当前数量${this.count})Button(加 1).onClick((){this.count})if(this.loading){LoadingProgress()}}.padding(20)}}这段代码最重要的不是语法而是状态变化路径。用户操作发生后只修改真正需要变化的状态UI 根据状态重新计算展示结果。这样调试时你可以沿着“事件 → 状态 → UI”往下找而不是在十几个回调里猜。实际项目里建议先把最小版本跑通再加接口、弹窗和缓存。很多人一上来就把所有逻辑堆进去最后报错时根本分不清是状态问题还是网络问题。3. 真正容易踩坑的是状态边界第一类坑是“能不用状态的值也做成状态”。例如一个只在点击事件内部使用的临时变量它不参与 UI 渲染就没必要为了保险全部声明成响应式状态。状态越多阅读成本越高也更容易出现无意义刷新。第二类坑是“同一个事实存两份”。比如列表长度本来可以从list.length得到又额外维护一个count。新增数据时改了 list忘了改 count页面马上出现两个答案。能计算出来的值尽量计算不要重复存。第三类坑是异步回来以后不管页面当前处境直接赋值。请求发出去时用户可能已经切换筛选条件旧请求后返回就可能覆盖新结果。真实业务里要么给请求带查询条件并在返回时校验要么统一做请求取消/序列控制。privaterequestSeq:number0asyncrefresh(){constseqthis.requestSeqthis.loadingtruetry{constresultawaitloadData()if(seq!this.requestSeq)returnthis.dataresult}finally{if(seqthis.requestSeq)this.loadingfalse}}这个小技巧很朴素但对搜索、筛选、分页这种连续请求特别有用。旧请求即使晚回来也没有资格覆盖最新状态。4. 把页面状态画出来代码会清楚很多如果一个页面已经出现五六个布尔值我建议先别继续写。拿纸画一下状态。比如请求页面通常就四种初始、加载中、成功、失败。弹窗则是关闭、编辑中、确认完成。布尔值最大的问题是可以组合出很多“不应该存在”的情况loadingtrue同时errortrue到底展示谁所以复杂页面可以直接用联合类型或枚举表达互斥状态。typeViewStateloading|content|empty|errorStateviewState:ViewStateloading渲染时只认这一份状态页面就不会同时冒出 Loading 和错误提示。这个思路比不停加条件判断好维护得多。5. 我在项目里会怎么拆我一般把页面分成三层。第一层是页面容器负责请求、路由和页面级状态第二层是业务组件只接收自己需要的数据第三层是纯展示组件尽量不碰网络和持久化。这么拆的好处不是为了“架构漂亮”而是改需求时少牵连。比如产品只改空状态样式你不应该碰请求代码接口字段调整也不应该顺手改弹窗显示逻辑。Componentstruct ContentPanel{Proptitle:stringPropdisabled:booleanfalsebuild(){Row(){Text(this.title)Blank()Text(this.disabled?不可操作:可操作)}.width(100%).padding(16)}}子组件只拿它需要的东西。不要图省事把整个巨大对象传进去再让组件内部到处读字段。字段依赖越隐蔽后面越难判断哪个变化会引起哪个组件更新。6. 调试时别只盯着 UI状态类问题有个特点界面表现是结果真正的原因往往发生在前面。所以我会在关键状态入口打日志而不是每一行都打。建议至少记录操作名、请求序号、旧值和新值。functionstateLog(name:string,before:object,after:object){console.info([state]${name}before${JSON.stringify(before)}after${JSON.stringify(after)})}如果第二次点击没有反应就先确认点击事件有没有进进了以后状态条件是不是把逻辑提前 return再看异步请求有没有真正发出。这个顺序比一上来清缓存、重装模拟器靠谱得多。7. 再补一个完整一点的处理方式真实页面里我更喜欢把一次操作包成一个完整方法入口校验、切换过程状态、执行业务、处理异常、最后恢复。这样按钮事件本身很薄。asynconQueryClick(){if(this.loading)returnthis.loadingtruethis.errorTexttry{constresultawaitthis.queryService()this.applyResult(result)}catch(err){this.errorText操作失败请稍后重试}finally{this.loadingfalse}}finally很关键。成功、失败、提前抛异常最终都要把 loading 收回来。项目里那种“第一次能点第二次永远没反应”的问题经常就是某条异常路径没有恢复状态。另外不建议为了让 UI 立即变化到处加延时。setTimeout能暂时把问题藏起来但它没有解决状态归属和执行顺序。除非业务真的需要延时否则先查数据流。8. 再往真实项目推进一步页面状态不是孤立的。真正的项目还会碰到返回页面是否重新请求、多个组件是否共享同一份筛选条件、缓存和网络谁先展示、快速重复点击如何防抖等问题。处理这些问题时不要先问“该用哪个装饰器”先问数据生命周期谁创建、谁修改、谁消费、什么时候失效。如果一份数据只服务一个局部组件就尽量留在局部如果父组件需要控制子组件就让依赖方向清晰如果需要跨页面长期保存再考虑持久化或更高层的数据模型。把生命周期想明白以后API 反而是最简单的一步。9. 这一篇记住什么回头看State、普通变量与 UI 刷新的边界核心其实就几句话需要驱动 UI 的值才进入响应式状态同一个事实尽量只有一个数据源异步结果要防止旧请求覆盖新状态复杂页面用明确的状态枚举替代一堆互相打架的布尔值组件只接收自己真正需要的数据。你可以拿手上的一个 HarmonyOS 7 页面做个小练习把所有State列出来逐个问“它变化后真的需要刷新 UI 吗”“这个值能不能从别的状态算出来”“页面离开以后还要不要它”。通常扫一遍就能删掉一批没必要的状态。下一篇继续往真实项目里走不讲虚的直接处理下一层状态协作问题。
