frontend-code-review

前端代码审查

何时使用此技能

当用户要求审查、分析或改进 src/frontend/ 目录下的前端代码（.tsx、.ts、.js 文件）时，使用此技能。支持以下审查模式：

1. 待提交更改审查 —— 检查准备提交的暂存文件或工作区文件，并在提交前指出违反检查清单的情况。
2. 指定文件审查 —— 审查用户指定的文件，并报告相关检查清单的发现。

以下情况请勿使用此技能：

• 请求涉及后端代码（src/backend/ 目录下的 .py 文件）。
• 用户没有要求审查、分析或改进前端代码。
• 范围不在 src/frontend/ 内（除非用户明确要求审查其他位置的前端相关更改）。

如何使用此技能

使用此技能时，请遵循以下步骤：

1. 根据用户的输入确定审查模式（待提交更改审查或指定文件审查）。严格控制范围：只审查用户提供或明确提及的内容。
2. 按照检查清单中的规则进行审查。如果没有适用的检查清单规则，则使用通用审查规则作为补充。
3. 严格按照要求的输出格式撰写最终结果。

使用此技能时的注意事项：

• 始终提供可执行的修复方案或建议（包括可能的代码片段）。
• 如果有文件路径和行号，请使用 File:Line 引用；否则，使用最具体的标识符。
• Langflow 前端使用 React 19、TypeScript 5.4、搭载 SWC 的 Vite 7、用于状态管理的 Zustand、用于服务端状态的 TanStack React Query、用于图形可视化的 @xyflow/react v12、Radix UI + shadcn-ui 组件、Tailwind CSS v3，以及用于代码检查和格式化的 Biome。

检查清单

• 代码质量：对所有审查的文件，按照 references/code-quality.md 检查样式规范、TypeScript 用法、Biome 合规性和组件模式。
• 性能：如果审查范围涉及 React 组件、Hooks、Zustand store、React Query 用法或 @xyflow/react 节点渲染，请按照 references/performance.md 检查重复渲染问题、记忆化和数据流模式。
• 业务逻辑：如果审查范围涉及自定义节点（GenericNode）、流程状态、API 调用、组件系统、全局变量或检查面板，请按照 references/business-logic.md 检查是否符合 Langflow 特定要求。
• 国际化：如果差异中新增或修改了面向用户的文本（标签、按钮、工具提示、模态框、Toast、错误消息、占位符、aria-label），请遵循 frontend-i18n skill：不得硬编码 UI 字符串——所有文本都必须通过 t(...) 处理——并且每个新增键都必须存在于所有语言环境文件（src/frontend/src/locales/*.json）中。

通用审查规则

1. 安全审查

检查以下问题：

• XSS 漏洞（dangerouslySetInnerHTML、未转义的用户输入）
• 客户端代码中的敏感数据泄露
• API 调用中的不安全直接对象引用
• 硬编码的密钥、令牌或 API 密钥

2. 无障碍审查

检查以下问题：

• 交互元素缺少 aria 标签
• 是否支持键盘导航
• 是否正确使用语义化 HTML 元素
• 自定义样式中的颜色对比度问题

3. 代码质量审查

检查以下方面：

• 代码重复（违反 DRY 原则——相同用法出现 3 次或以上时，应提取复用）
• 函数／组件承担过多职责（违反 SRP 原则——如果需要用“并且”来描述其职责，就应拆分）
• 嵌套过深或条件判断过于复杂（优先使用提前返回和守卫子句）
• 使用未命名常量的魔法数字／字符串
• 命名不佳：名称过于笼统（data、result、temp）、函数缺少动词前缀、布尔值缺少 is／has／can／should 前缀
• 缺少错误处理或错误边界
• TypeScript 类型覆盖不完整（不得使用 any，也不得使用 as any 类型断言）
• 注释解释了“是什么”而非“为什么”
• 被注释掉的代码（应使用版本控制）
• 使用布尔参数切换组件行为（应改用两个组件）
• 存在可用 const 或不可变替代方案却仍使用可变模式
• 生产文件超过约 500 行（达到 600 行以上属于警示信号）
• 生产代码中使用 console.log（Biome 会标记）

4. 测试影响审查

检查以下方面：

• 对 data-testid 属性的修改是否可能导致 E2E 测试失败
• 修改组件接口是否需要更新测试
• 新增的交互元素是否缺少 data-testid 属性

5. 提交前验证

审查待处理的更改时，验证：

• npm run format（Biome 格式化工具）——无差异
• npm run lint（Biome 代码检查工具）——无错误
• npm test（Jest）——无失败

必需的输出格式

调用此技能时，回复必须严格遵循以下两个模板之一：

模板 A（存在问题）

# Code Review

Found <N> urgent issues that need to be fixed:

## 1. <brief description of issue>

FilePath: <path> line <line>
<relevant code snippet or pointer>


### Suggested fix

<brief description of suggested fix with code example>

---

... (repeat for each urgent issue) ...

Found <M> suggestions for improvement:

## 1. <brief description of suggestion>

FilePath: <path> line <line>
<relevant code snippet or pointer>


### Suggested fix

<brief description of suggested fix with code example>

---

... (repeat for each suggestion) ...

• 如果没有紧急问题，则省略该部分。如果没有建议，则省略该部分。
• 如果问题数量超过 10 个，则概括为“10+ 个紧急问题”或“10+ 条建议”，并且只输出前 10 项。
• 不要压缩各部分之间的空行；应保留原样以便阅读。
• 如果使用模板 A（存在待修复问题），且至少有一个问题需要修改代码，则在结构化输出后追加一个简短的跟进问题，询问用户是否希望应用建议的修复。例如：“要我应用建议的修复来解决这些问题吗？”

模板 B（没有问题）

## Code Review

No issues found.