HarmonyOS7 ReadonlyProductRating 教程：商品列表里的只读评分展示

前言

在商品列表、内容榜单、门店详情里，评分更多是展示信息而不是输入行为。indicator 模式就是为这种场景准备的。 这种例子表面上很基础，但只要你开始往业务里塞，就会发现很多细节不提前想清楚会很难收。 如果你正准备把它接到业务里，这个阅读顺序会比死记参数更省时间。

这篇我会重点从数据展示策略这个角度往下讲。不是为了把每个属性都讲一遍，而是帮你建立一个更接近真实开发的阅读顺序：先看页面目标，再看状态流，最后再看样式怎么收口。

先别急着写代码

这个案例并不复杂，但它很适合练习 ArkUI 里最常用的那条线：状态变化，界面跟着变。

“Rating 只读模式”这种能力，单独演示时很轻，落到项目里却往往要和表单、列表、卡片或者反馈区绑在一起，这也是这个案例值得细看的原因。

这一类写法常见在 商品评价、内容评分、门店口碑、榜单展示 这些页面里。你只要把示例里的交互换成自己的业务文案，再把静态数据换成真实数据源，骨架基本就够用了。

示例读不明白时，最好的办法不是多看几遍属性表，而是先把页面里的角色关系搞明白。

如果你后面要把示例改成线上页面，别急着先美化，先确认 状态字段和展示结果有没有保持同一份数据来源，避免页面看起来“能动”但结果不可信。

界面和数据是怎么配合的

页面最外层通常先用Column把主轴定下来，这一步看起来普通，但它决定了后面所有内容是顺着读，还是碎着看。

这个例子没有刻意把结构做复杂，反而更方便你看清主交互区和说明区是怎么分层的。

像Row这种并排容器，真正的价值不是“能横着排”，而是帮你把对比关系直接摆给用户看。数字、标签、刻度、按钮放在一起时，理解速度会快很多。

第 8 篇案例在布局上最值得学的地方，是它没有为了展示组件能力去强行堆内容，而是尽量让每一块区域都有明确职责。这样的代码后面更好拆组件。

完整代码

下面这份代码保留了案例本身的实现思路，但把示例编号替换成了更自然的英文命名。你直接拿去做实验、拆段运行，阅读成本会低很多。

/** * ReadonlyProductRating - Rating 只读模式 */import{PRESET_COLORS,generateListItems,PAGE_BG_COLOR,PANEL_BG_COLOR,ACCENT_COLOR,MUTED_TEXT_COLOR}from'./types'interfaceReadonlyProductRatingItem{name:stringrating:numbersales:number}@Entry@Componentstruct ReadonlyProductRating{@StateisShow:boolean=truebuild(){Column(){if(this.isShow){Column(){Text('Rating 只读模式').fontSize(16).fontWeight(FontWeight.Bold).margin({bottom:16})ForEach([{name:'商品 A',rating:4.5,sales:1234},{name:'商品 B',rating:3.8,sales:5678},{name:'商品 C',rating:5.0,sales:890},{name:'商品 D',rating:2.5,sales:3456},{name:'商品 E',rating:4.0,sales:12345}],(item:ReadonlyProductRatingItem,index:number)=>{Row(){Column(){Text(item.name).fontSize(14).fontWeight(FontWeight.Medium)Text(`销量:${item.sales}`).fontSize(11).fontColor(MUTED_TEXT_COLOR)}.alignItems(HorizontalAlign.Start).layoutWeight(1)Column(){Rating({rating:item.rating,indicator:true}).stars(5)Text(`${item.rating}星`).fontSize(12).fontColor(ACCENT_COLOR)}.alignItems(HorizontalAlign.End)}.width('100%').padding({top:10,bottom:10}).border({width:{bottom:index<4?0.5:0},color:'#F0F0F0'})})}.width('100%').padding(16).backgroundColor(PANEL_BG_COLOR).borderRadius(12)}Text('Rating 只读').fontSize(12).fontColor(MUTED_TEXT_COLOR).margin({top:12})}.width('100%').height('100%').backgroundColor(PAGE_BG_COLOR).padding(16)}}

关键代码单独讲

第一处关键代码

@State isShow: boolean = true

这一行先别急着略过，它通常就是页面状态的起点。后面很多显示内容，都会跟着它一起变化。 如果这是评分相关代码，我还会继续追一下它最终有没有同步到展示文案或结果区。

第二处关键代码

ForEach([

这行看着不像业务逻辑，但它其实决定了信息摆放顺序，也决定了阅读节奏。 如果这是评分相关代码，我还会继续追一下它最终有没有同步到展示文案或结果区。

第三处关键代码

Rating({ rating: item.rating, indicator: true }).stars(5)

它不是整段代码里最复杂的部分，却往往是最先影响使用体验的部分。 如果这是评分相关代码，我还会继续追一下它最终有没有同步到展示文案或结果区。

常见改造方向

很多人第一次读示例会从头到尾扫一遍，但更高效的做法，其实是先看下面这些触发点：

• ForEach([

对评分类页面来说，页面顺不顺手，往往取决于用户点完之后有没有马上看到数值和文案一起变。

这里最值得养成的习惯，是顺手确认结果值到底存在哪。状态一多，页面最容易出的问题不是不刷新，而是刷出来的不是同一个结果。

真准备继续往下改时，我会先把输入值、结果值和提示文案拆开存。这样后面无论是加校验还是加动画，都不容易把build()变成大杂烩。

再往前走一步

真要把这个案例拿去改业务页面，我会按下面这个顺序动手：

• 把演示用的静态数据替换成真实数据源，别等接口接进来以后再改页面结构。
• 把重复出现的卡片、标题栏、结果区提成小组件，后面加状态会轻松很多。
• 提前补上异常态，比如空值、失败态、禁用态、超范围输入，否则示例一进业务就会露怯。
• 如果是评分页，我会尽量把“用户可评分”和“只展示结果”拆开，不让一个组件同时承担两种语义。

这里最容易被忽略的一点，是 状态字段和展示结果有没有保持同一份数据来源，避免页面看起来“能动”但结果不可信。 这个问题。很多示例在静态数据下看不出毛病，一接真实状态就开始暴露问题，所以这一步最好趁早做。

容易被忽略的小地方

有些细节在第一眼看代码时很容易被跳过去，但它们往往决定了页面是不是耐改。

• @State不是装饰器样板，它决定了哪些数据变化后会重新驱动画面。
• 看到ForEach时，顺手检查一下列表项是不是结构稳定、职责单一，这会直接影响后续抽组件的成本。
• 对于 Rating 类页面，我会特别留意文案反馈是不是跟着用户动作一起变化，因为这直接影响页面有没有“会说话”的感觉。

这些东西单看都不复杂，组合在一起，才是一个案例真正的完成度。

写在最后

如果你后面准备把它接进真实项目，优先处理数据来源、异常状态和文案反馈，这三处改完，示例味道基本就没了。

别急着一上来抽组件，先把页面里的主路径走通，后面再拆会更稳。