停止在 Angular 中绑定键盘事件 — 改用模型焦点
看起来您只提供了来源链接，而没有贴出需要翻译的正文内容。请把要翻译的文本（包括标题、段落、列表等）粘贴在这里，我就可以帮您把它翻译成简体中文，同时保持原有的 Markdown 格式和代码块不变。谢谢！
Source: …
Angular 中本地键盘处理的问题
如果你在 Angular 组件里使用 @HostListener 来绑定键盘事件，那么你的架构已经出现泄漏。
你正在把一个 全局 问题建模为 局部 逻辑。
这看起来可能很简洁：
@HostListener('keydown', ['$event'])
// …一些条件判断，调用 element.focus()这种做法在应用仅是简单表单时还能工作。
为什么随着应用增长会出问题
- 可复用布局 → 状态变得动态。
- 多个 UI 部分 需要协同。
- 焦点 开始表现不一致。
- 快捷键 出现重复。
- 边缘情况 成倍增加。
曾经看似简单的实现，悄然变成散落在各组件中的脆弱协同逻辑。
核心问题：焦点是全局状态
一次只能有一个元素获得焦点。导航依赖于 当前所在位置——这不是局部行为，而是 整个应用的状态。
“焦点在整个应用中共享，这意味着在局部建模它时，裂痕就会出现。”
当开发者尝试“改进”键盘处理时，通常仍抱有同样的错误假设：焦点可以局部建模，随后再进行协调。
后果
- 每个解决方案都 向上 工作。
- 大多数 Angular 应用采用相似的变体，只解决了局部问题，却从未解决整体。
- 没有统一的、全局的焦点模型 → 产生压力。
常见症状
-
组件级别的键盘处理
- 简单：监听
keydown，检查键值，移动焦点。 - 当导航跨越组件边界时会失效 → 逻辑重复、行为漂移、全局导航难以测试。
- 简单：监听
-
文档级别的处理（为减少重复）
- 起初感觉更整洁，但焦点上下文变得隐式，边界规则更难处理，隐藏的耦合出现。
- 集中事件 ≠ 集中状态。
-
Angular CDK
FocusKeyManager- 在单个组件内部表现出色。
- 并非用于在多个组件树、混合布局或全局快捷键范围内编排焦点。
-
UI 库的键盘行为
- 在使用单一工具包时可行。
- 当混合使用多个工具包或添加自定义组件时会变得支离破碎。
这些方法本身并非根本错误；它们只是 假设焦点可以局部管理。实际操作中，这一假设正是产生裂痕的根源。
重新思考焦点：从事件到状态
问题不在于缺少更好的事件处理器，而在于我们建模的对象错误。
- 键盘导航 通常被视为对按键的响应（一系列条件判断）。
- 焦点，然而，是 状态，而不是事件。
架构转变
不要问：
当在该组件内部按下 ArrowDown 时应该发生什么？
而是问：
当前焦点在哪儿——下一个有效的焦点目标是什么？
这种细微的改变把导航从一堆事件处理器转变为一个 状态转移系统，它可以：
- 被确定
- 受约束
- 可配置
- 可组合
组件不再自行管理焦点，而是 参与更广泛的模型。
示例：标签切换与焦点
- 用户切换标签页。
- 代码尝试将焦点设置到新激活面板内的某个字段。
通常这能正常工作——但有时会失效。
如果焦点调用在 元素尚未存在 时执行，焦点会丢失。此类失败不是 bug，而是模型假设了 即时性。
现代应用无法保证 element.focus() 能立即执行（例如，异步渲染、懒加载内容）。
意图 → 确认模式
- 表达意图 将焦点设到特定目标 → 成为一次显式的状态转移。
- 确认 当元素实际存在且已准备好时。
好处
- 能在异步渲染下生存。
- 处理懒加载内容。
- 防止竞争条件和焦点丢失。
- 跨组件边界工作。
它把焦点视作 状态，而非副作用。
介绍 Focusly
在反复实现该模型后，显而易见需要一个 缺失的层。
Focusly 是一个 Angular 库，具备以下特性：
- 显式建模焦点，作为共享的应用状态。
- 将导航视为 方向性的状态转换。
- 提供 基于配置的键处理（无需每个组件单独监听）。
- 让组件 声明它们在导航上下文中的位置。
焦点编排存在于它应在的地方：应用层。
不再需要手动监听器
// 使用 Focusly 时，通常不需要在每个组件中使用 @HostListener。如果这种对焦点的思考方式与你产生共鸣，欢迎探索该项目：
- Demo & Docs –
- GitHub Repository –
- Live Demo –
Focusly 帮助你从零散、事件中心的键盘处理，转向稳健、状态驱动的焦点架构。
我很想了解你在 Angular 应用中目前是如何处理键盘导航的，以及这种架构转变在你的场景中是否有帮助。