把界面当成状态机

先理解这个概念

每个有数据或操作的界面都存在状态。状态之间的转移需要原因和反馈。空数据、无搜索结果、没有权限与加载失败看起来都可能“什么也没有”，但用户下一步完全不同。

状态不是给页面多画几张图，而是限定什么情况下允许什么动作。多个布尔值容易组合出不合理界面，例如同时成功、失败且加载中。将互斥状态写清，再为每次事件指定转移和数据保存规则，界面就更容易与真实业务一致。

记住这三个原则

1. 01

   为每个状态写出可见内容和可执行动作。

2. 02

   区分初次加载与已有数据的后台刷新。

3. 03

   失败时明确是保留旧数据、重试还是重新开始。

实际设计时，分三步做

1. STEP 01

   列出空闲、编辑、提交中、成功和失败等互斥状态，另外区分数据是否存在、权限是否足够等独立条件。

2. STEP 02

   为每个状态列可用动作、可见反馈和保留数据，说明点击后进入哪里以及什么事件结束等待。

3. STEP 03

   检查重复提交、晚到响应和切换对象，确保旧请求不能覆盖用户刚打开的新对象。

一个容易理解的例子

反馈帮助用户判断系统是否可靠以及接下来怎么做。

type ViewState =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: Item[] }
  | { status: "error"; message: string };

适用边界与取舍

状态越多不一定越清楚。不要把每个视觉细节都变成顶层状态，应区分业务状态与局部呈现，避免组合爆炸。