文章目录
- 前言
- 这个页面适合放进什么场景
- 先看界面层次
- 完整代码
- 代码里最该先看的部分
- 第一处关键代码
- 第二处关键代码
- 第三处关键代码
- 从案例走到业务页面
- 再往前走一步
- 容易被忽略的小地方
- 写在最后
前言
很多页面并不需要用户去点星星，而是需要把已有评分展示得更顺眼。这个案例适合从展示视角理解 Rating 的价值。 真正上手时，难点往往不在组件本身，而在你要不要把它写得像个真实页面。 我不会按属性表的顺序平铺，而是直接挑最影响使用体验的部分来讲。
这篇我会重点从组件封装角度这个角度往下讲。不是为了把每个属性都讲一遍，而是帮你建立一个更接近真实开发的阅读顺序：先看页面目标，再看状态流，最后再看样式怎么收口。
这个页面适合放进什么场景
这类示例最怕读成“API 列表”，所以我会直接从页面行为往回拆。
如果把“Rating 样式自定义”只当成一个组件示例来看，它其实很快就会读完；但一旦把它放回真实页面，你会立刻发现它还连着状态切换和结果反馈。
这一类写法常见在 商品评价、内容评分、门店口碑、榜单展示 这些页面里。你只要把示例里的交互换成自己的业务文案，再把静态数据换成真实数据源，骨架基本就够用了。
如果一段代码看起来平平无奇，我会先找它到底在响应谁的动作，而不是急着去记它的 API。
真准备往业务里接时，我最先会盯的不是颜色和间距，而是 状态字段和展示结果有没有保持同一份数据来源，避免页面看起来“能动”但结果不可信。
先看界面层次
页面最外层通常先用Column把主轴定下来，这一步看起来普通，但它决定了后面所有内容是顺着读，还是碎着看。
这个例子没有刻意把结构做复杂，反而更方便你看清主交互区和说明区是怎么分层的。
像Row这种并排容器，真正的价值不是“能横着排”，而是帮你把对比关系直接摆给用户看。数字、标签、刻度、按钮放在一起时，理解速度会快很多。
第 6 篇案例在布局上最值得学的地方，是它没有为了展示组件能力去强行堆内容，而是尽量让每一块区域都有明确职责。这样的代码后面更好拆组件。
完整代码
下面这份代码保留了案例本身的实现思路，但把示例编号替换成了更自然的英文命名。你直接拿去做实验、拆段运行，阅读成本会低很多。
/** * RatingDisplayStyle - Rating 样式自定义 */import{ColorConfig,PRESET_COLORS,generateListItems,PAGE_BG_COLOR,PANEL_BG_COLOR,ACCENT_COLOR,MUTED_TEXT_COLOR}from'./types'@Entry@Componentstruct RatingDisplayStyle{@StateisShow:boolean=truebuild(){Column(){if(this.isShow){Column(){Text('Rating 样式自定义').fontSize(16).fontWeight(FontWeight.Bold).margin({bottom:16})ForEach(PRESET_COLORS.filter((_:ColorConfig,i:number)=>i<7)asColorConfig[],(color:ColorConfig,index:number)=>{Row(){Text(color.name).fontSize(13).width(40)Rating({rating:(index+1)*0.7,indicator:true}).stars(5)}.margin({bottom:10})})Text('使用不同颜色星标展示').fontSize(11).fontColor(MUTED_TEXT_COLOR).margin({top:8})}.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(PRESET_COLORS.filter((_: ColorConfig, i: number) => i < 7) as ColorConfig[], (color: ColorConfig, index: number) => {
这行看着不像业务逻辑，但它其实决定了信息摆放顺序，也决定了阅读节奏。 如果这是评分相关代码，我还会继续追一下它最终有没有同步到展示文案或结果区。
第三处关键代码
Rating({ rating: (index + 1) * 0.7, indicator: true })
它不是整段代码里最复杂的部分，却往往是最先影响使用体验的部分。 如果这是评分相关代码，我还会继续追一下它最终有没有同步到展示文案或结果区。
从案例走到业务页面
如果你只想先抓主逻辑，我会先盯住下面几行：
ForEach(PRESET_COLORS.filter((_: ColorConfig, i: number) => i < 7) as ColorConfig[], (color: ColorConfig, index: number) => {
对评分类页面来说，页面顺不顺手，往往取决于用户点完之后有没有马上看到数值和文案一起变。
读到交互段时，不妨多问一句：这个结果有没有唯一数据源？很多页面后面难维护，就是从这里埋下的。
一个很实用的改法，是尽早把状态分层：谁负责输入，谁负责展示，谁负责兜底。只要这一步做清楚，后面页面再长，build()也不至于越来越乱。
再往前走一步
真要把这个案例拿去改业务页面，我会按下面这个顺序动手：
- 把演示用的静态数据替换成真实数据源，别等接口接进来以后再改页面结构。
- 把重复出现的卡片、标题栏、结果区提成小组件，后面加状态会轻松很多。
- 提前补上异常态，比如空值、失败态、禁用态、超范围输入，否则示例一进业务就会露怯。
- 如果是评分页，我会尽量把“用户可评分”和“只展示结果”拆开，不让一个组件同时承担两种语义。
这里最容易被忽略的一点，是 状态字段和展示结果有没有保持同一份数据来源，避免页面看起来“能动”但结果不可信。 这个问题。很多示例在静态数据下看不出毛病，一接真实状态就开始暴露问题，所以这一步最好趁早做。
容易被忽略的小地方
有些细节在第一眼看代码时很容易被跳过去，但它们往往决定了页面是不是耐改。
@State不是装饰器样板，它决定了哪些数据变化后会重新驱动画面。- 看到
ForEach时，顺手检查一下列表项是不是结构稳定、职责单一，这会直接影响后续抽组件的成本。 - 对于 Rating 类页面，我会特别留意文案反馈是不是跟着用户动作一起变化，因为这直接影响页面有没有“会说话”的感觉。
这些东西单看都不复杂，组合在一起，才是一个案例真正的完成度。
写在最后
这类页面往往不是功能难，而是容易写得太像示例。只要你把状态、反馈和视觉层次这三件事捏紧，页面质感就会立刻上来。
先把数据从哪来、结果往哪去想清楚，再去调样式，返工会少很多。
