返回全栈开发
PATH 02/LESSON 08/16 分钟

界面首先表达状态

把加载、成功、空数据、失败与恢复设计成明确状态。

课程全目录 · 选择章节

本课学习目标

  • • 空闲 — 等待用户动作
  • • 加载 — 说明正在发生什么
  • • 成功 — 展示结果与下一步
  • • 失败 — 解释并提供恢复

完成路径

阅读概念与案例 → 完成动手任务 → 勾选实践检查 → 回答检查点 → 保存完成记录。练习由你自行检查,不会假装成自动代码评分。

01 / 核心概念

组件不是静态画面,而是状态到界面的映射。先列出状态,再设计每种状态下用户能看到和能做什么。

状态越明确,异步请求、错误恢复和可访问反馈就越容易保持一致。

02 / 心智模型

01

空闲

等待用户动作

02

加载

说明正在发生什么

03

成功

展示结果与下一步

04

失败

解释并提供恢复

03 / 代码骨架

TYPESCRIPT / CONCEPT
type ViewState<T> =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: T }
  | { status: "error"; message: string };

这是解释结构的代码骨架,外部函数与数据需要在实际项目中实现。

04 / 贯穿案例

放进真实情境里看

任务台第一次打开时没有任务;提交后网络很慢;再次提交时服务器报错。若页面只画“有任务”的理想状态,访客会看见空白、误以为按钮没反应,甚至重复创建。

  1. 01

    列出所有可见状态

    至少包括初始、加载、空结果、有数据、提交中和失败。把空结果当成成功的一种,而不是错误。

  2. 02

    为每个状态安排动作

    加载时说明正在等待并禁用重复提交;空结果引导创建;失败时保留输入并允许重试。

  3. 03

    用状态图检查遗漏

    从加载到成功、空结果、错误都应该有边;错误恢复也必须能回到某个有效状态。

05 / 动手做

用自己的产物检验理解

为“创建任务”按钮写出至少六个状态和各状态显示的文字、按钮是否可用,以及下一步动作。

完成时检查

  • 提交中无法重复提交
  • 失败后输入内容仍在
  • 空列表有明确的创建入口

自动保存在当前浏览器,不会同步到账户。

继续到代码练习

06 / 检查点

请求失败后,界面最少应该提供什么?

延伸阅读 · 原始资料