Angular UI 模式

为什么需要一套 UI 模式

Angular 17+ 的控制流（@if、@for、@defer）和 Signal 让状态表达更清晰，但团队仍容易在同一屏里同时出现骨架、旧数据和微调器，或在请求失败时静默吞错。这类问题不会靠「多写几个 *ngIf」解决，需要的是加载、错误、空态、按钮反馈之间的一致决策。

技能覆盖什么

本技能把日常交付拆成可执行的规则与模式：

• 加载状态：黄金法则是「仅当没有可展示数据时才显示加载」；并给出骨架屏 vs 微调器的对照（已知布局用骨架、按钮/模态操作用微调器）。
• 控制流：条件渲染、@for 配合 track、@defer 做渐进披露。
• 错误处理：分层处理，永不静默吞没错误；配合错误状态组件模式。
• 按钮与表单：异步期间始终禁用触发器，必要时在按钮上显示加载；表单需兼顾加载与校验反馈。
• 空状态：每个列表/集合必须有上下文相关的空态（含 @empty 块思路）。
• 反模式清单与UI 状态检查清单（错误、加载、空态、乐观更新回滚、可访问性等），便于 Code Review 或上线前自检。

与 angular、angular-state-management（Signal 存状态）、testing-patterns（覆盖各 UI 状态）可组合使用。

注意点

这是模式与检查清单，不是组件库：具体骨架、Toast、对话框仍要按项目设计系统实现。乐观更新必须在失败时显式回滚；@defer 解决的是按需加载，不能替代错误与空态设计。