front-react-code-style

name	front-React-code-style
description	当用户要生成、补全、修改或评审 React 前端代码、组件、hooks、signals、样式或交互逻辑时触发。它按现有项目风格产出最小改动的 React 代码；不用于 React/Next/Vue、后端、运维或不涉及 React 的普通前端任务。常见触发语：React 组件、改 React 页面、补 hook、修 React 交互、review React 代码。

React Code Style

按下面规则生成 React 代码，并优先兼容用户当前项目已有风格；如果项目现有写法与本 skill 不冲突，保持一致。

项目风格优先

• 先确认项目使用 JavaScript 还是 TypeScript、CSS 方案、路由方案、状态管理和包管理器，再做修改。
• 新增文件放到现有同类目录中，命名、导出方式、路径别名和组件拆分粒度保持一致。
• 不主动引入新框架、新 UI 库、新状态库或 React 兼容依赖；确实需要依赖时先说明原因。
• 只修改当前需求相关文件，不顺手调整无关格式、目录结构、依赖版本或视觉风格。
• 默认所有UI要兼容桌面端(chrome浏览器)和移动端(iphone14 plus), 要完美适配移动端效果

组件与 JSX

• 优先使用函数组件，组件名使用 PascalCase，普通函数和变量使用 camelCase。
• hooks 从 React/hooks 引入；只有项目已经使用 signals 时，才从 @React/signals 或既有封装中继续沿用。
• 不使用 React 专属 API；需要兼容第三方 React 组件时，先确认项目已有 React/compat 配置。
• props、事件和状态命名要表达业务含义，不使用空泛缩写。
• 组件内部逻辑保持直接清晰；没有复用价值的代码不要抽成单独 hook 或工具函数。
• 多处重复且业务含义稳定的逻辑可以抽成同文件私有函数、hook 或项目已有工具模块。
• 每个页面的路由应该是不一样的 比如登陆页对应login

状态与副作用

• 组件本地状态优先使用 useState；跨组件状态沿用项目已有 store、context 或 signals。
• useEffect 只处理副作用，补齐依赖数组，并在订阅、定时器、请求竞态等场景中做好清理或失效保护。
• 能通过 props、state 或 signal 派生的值，优先直接派生；计算成本明显时再使用 useMemo。
• useCallback 只在能减少真实重复渲染、稳定依赖或满足子组件引用要求时使用。
• 表单优先使用清晰的受控或非受控模式，不混用导致状态来源不明。

样式与交互

• 沿用项目已有样式方案，例如 CSS Modules、Tailwind、vanilla CSS、Sass 或组件库样式 API。
• 新增交互要覆盖 loading、disabled、empty、error 和可取消状态中与需求直接相关的部分。
• 保持移动端和桌面端都可用；固定格式元素使用稳定尺寸约束，避免 hover、图标、文案变化造成布局跳动。
• 文案放在已有国际化或常量体系中；项目没有对应体系时，直接写最小必要文案。
• 无用户要求时不做装饰性重设计，不新增与功能无关的动画、渐变或大面积配色变化。
• 单击选定输入框, 并且要有输入ui提示
• “查询中/操作中...”等接口请求状态使用模态浮层：明显遮罩、加载动画，并利用浏览器模态对话框在接口返回前阻止鼠标、触摸和键盘操作。
• 单一条件时, 无需再使用查询按钮, 而是用户完成查询条件后, 自动查询
• 日期 点击后, 要跳出日期选择的插件

类型与数据

• TypeScript 项目中为 props、请求结果和关键状态补充明确类型；避免为方便绕过问题而使用 any。
• API 数据进入组件前要处理空值、默认值和字段缺失；不要让模板中堆积复杂兜底表达式。
• 事件处理函数先取出有业务含义的中间变量，再调用核心逻辑，避免把复杂表达式直接塞进参数。

测试与验证

• 不自动生成测试用例。如果用户要求写测试，保持测试逻辑简单，优先覆盖主流程、关键分支和明显边界。
• 修改完成后优先运行项目已有的类型检查、lint；找不到脚本时说明未验证原因。
• 新增依赖, 自动安装前端依赖
• 默认禁止自动构建校验和自动测试。

变更边界

• 生成的代码必须可直接落地，不写 TODO、伪代码或“示意实现”。
• 已存在的文件、代码和注释，除非与当前需求直接相关，禁止删除或重写。
• 与本次修改无关的文件/代码/注释, 禁止删除
• 禁止修改与用户当前需求无关的代码、配置占位符、注释、格式、命名、依赖、接口 URL、调度表达式等内容。即使发现现有代码看起来不够优雅、不够一致、可能有更好的写法，也只能在回复中提示，不得顺手修改。
• 新增代码时优先做最小必要改动，不顺手扩展范围，不主动重构整条链路
• 直接修改相关代码即可

逻辑

• 后端接口禁止使用各类 proxy 转发, 直接使用完整后端地址
• 使用框架内已有的日志工具，在关键节点 加入 日志打印

• 参考行业内类似场景和功能的优秀方案和标准
• 在满足 .gitignore 的前提下, 每次代码增删改，必须使用 git add .、git add -A自动添加生成后的代码文件