HarmonyOS7 RatingFeedbackPanel 教程：评分变化后如何即时反馈用户

文章目录前言为什么这个例子值得单独看页面是怎么跑起来的完整代码拆开三段关键实现第一处关键代码第二处关键代码第三处关键代码改成业务代码时要补什么再往前走一步容易被忽略的小地方写在最后前言好的评分交互不止是改一个数字还要及时告诉用户他的选择意味着什么。这个案例正好把反馈层做出来了。 我更关心的不是它能不能跑而是它跑起来之后用户会不会觉得顺手。 你可以把这篇当成一次真实页面拆解而不是一份孤立的组件笔记。这篇我会重点从可读性优化这个角度往下讲。不是为了把每个属性都讲一遍而是帮你建立一个更接近真实开发的阅读顺序先看页面目标再看状态流最后再看样式怎么收口。为什么这个例子值得单独看如果你是第一次接触这个控件别急着把每个属性都背下来先看它解决了什么交互问题。这类页面最值得看的从来不是控件本身而是它怎样嵌进完整业务流程里。围绕“Rating onChange 回调”前后通常都会挂着别的状态和文案。这一类写法常见在 商品评价、内容评分、门店口碑、榜单展示 这些页面里。你只要把示例里的交互换成自己的业务文案再把静态数据换成真实数据源骨架基本就够用了。先把用户操作路径走一遍再回头看参数名很多配置为什么存在会一下子清楚很多。这一类页面最后最容易出问题的通常不是你肉眼第一眼看到的布局而是 状态字段和展示结果有没有保持同一份数据来源避免页面看起来“能动”但结果不可信。页面是怎么跑起来的页面最外层通常先用Column把主轴定下来这一步看起来普通但它决定了后面所有内容是顺着读还是碎着看。这个例子没有刻意把结构做复杂反而更方便你看清主交互区和说明区是怎么分层的。这一页更多是纵向阅读逻辑说明作者希望用户按顺序完成操作而不是在多个区域来回跳。第 7 篇案例在布局上最值得学的地方是它没有为了展示组件能力去强行堆内容而是尽量让每一块区域都有明确职责。这样的代码后面更好拆组件。完整代码下面这份代码保留了案例本身的实现思路但把示例编号替换成了更自然的英文命名。你直接拿去做实验、拆段运行阅读成本会低很多。/** * RatingFeedbackPanel - Rating onChange 回调 */import{PRESET_COLORS,generateListItems,PAGE_BG_COLOR,PANEL_BG_COLOR,ACCENT_COLOR,MUTED_TEXT_COLOR}from./typesEntryComponentstruct RatingFeedbackPanel{StateisShow:booleantrueStaterating:number0Statefeedback:string请点击星星评分build(){Column(){if(this.isShow){Column(){Text(Rating onChange 回调).fontSize(16).fontWeight(FontWeight.Bold).margin({bottom:12})Text(this.feedback).fontSize(14).fontWeight(FontWeight.Medium).fontColor(this.rating4?PRESET_COLORS[3].value:this.rating2?ACCENT_COLOR:MUTED_TEXT_COLOR).width(100%).padding(10).textAlign(TextAlign.Center).backgroundColor(this.rating4?PRESET_COLORS[3].value10:this.rating2?ACCENT_COLOR10:#F5F5F5).borderRadius(8).margin({bottom:16})Rating({rating:this.rating,indicator:false}).stars(5).stepSize(0.5).onChange((value:number){this.ratingvalueif(value0)this.feedback请点击星星评分elseif(value1)this.feedback非常不满意 elseif(value2)this.feedback不满意 elseif(value3)this.feedback一般 elseif(value4)this.feedback满意 elsethis.feedback非常满意 })Text(评分:${this.rating}).fontSize(16).fontWeight(FontWeight.Bold).fontColor(ACCENT_COLOR).margin({top:12})}.width(100%).padding(16).backgroundColor(PANEL_BG_COLOR).borderRadius(12).alignItems(HorizontalAlign.Center)}Text(Rating onChange).fontSize(12).fontColor(MUTED_TEXT_COLOR).margin({top:12})}.width(100%).height(100%).backgroundColor(PAGE_BG_COLOR).padding(16)}}拆开三段关键实现第一处关键代码State isShow: boolean true这一行先别急着略过它通常就是页面状态的起点。后面很多显示内容都会跟着它一起变化。 如果这是评分相关代码我还会继续追一下它最终有没有同步到展示文案或结果区。第二处关键代码State rating: number 0看起来只是一个字段定义但页面后面能不能“动起来”很多时候就靠它。 如果这是评分相关代码我还会继续追一下它最终有没有同步到展示文案或结果区。第三处关键代码State feedback: string 请点击星星评分这种状态声明的价值不在写法本身而在于它决定了谁来保存结果、谁来触发刷新。 如果这是评分相关代码我还会继续追一下它最终有没有同步到展示文案或结果区。改成业务代码时要补什么页面为什么会“有反应”关键基本都落在这几个位置上.onChange((value: number) {对评分类页面来说页面顺不顺手往往取决于用户点完之后有没有马上看到数值和文案一起变。我更建议你读这一段时把注意力放在“状态有没有只存一份”。一旦同一个结果要靠两三个变量拼出来后面很容易出现显示和真实值不同步的问题。如果你后面要继续扩展这个页面一个很稳的做法是先把核心状态梳理成几类输入值、展示值、辅助文案、边界状态。分类清楚了代码会比一股脑往build()里塞判断干净很多。再往前走一步真要把这个案例拿去改业务页面我会按下面这个顺序动手把演示用的静态数据替换成真实数据源别等接口接进来以后再改页面结构。把重复出现的卡片、标题栏、结果区提成小组件后面加状态会轻松很多。提前补上异常态比如空值、失败态、禁用态、超范围输入否则示例一进业务就会露怯。如果是评分页我会尽量把“用户可评分”和“只展示结果”拆开不让一个组件同时承担两种语义。这里最容易被忽略的一点是 状态字段和展示结果有没有保持同一份数据来源避免页面看起来“能动”但结果不可信。 这个问题。很多示例在静态数据下看不出毛病一接真实状态就开始暴露问题所以这一步最好趁早做。容易被忽略的小地方有些细节在第一眼看代码时很容易被跳过去但它们往往决定了页面是不是耐改。State不是装饰器样板它决定了哪些数据变化后会重新驱动画面。对于 Rating 类页面我会特别留意文案反馈是不是跟着用户动作一起变化因为这直接影响页面有没有“会说话”的感觉。这些东西单看都不复杂组合在一起才是一个案例真正的完成度。写在最后真正有用的不是把例子抄下来而是知道下一次写相似页面时自己应该先搭哪一层。这个案例刚好提供了一个很稳的起点。如果你只打算先改一处我建议先改状态流因为它决定后面所有交互是不是顺手。