人工智能大模型代码智能体AI Agent桌面应用后端前端CLI【免费下载链接】ZCodeZCode 是 AI 编程工作台提供桌面应用、浏览器界面和终端 Agent。本仓库包含客户端、后端服务、共享 UI以及 Agent CLI 与运行时源码。项目地址https://gitcode.com/zai-org/ZCode点击查看免费下载导读在 ZCode 这样的大型 React/Next.js 工作台桌面应用、浏览器界面、终端 Agent 三端同构中表单提交、点击、拖拽等交互动作如果被错误建模成state effect会导致 effect 在无关状态变化时反复执行、副作用重复触发造成不必要的重渲染与重复请求。本篇指南以 ZCode 仓库内置的 Vercel React Best Practices 技能规则rerender-move-effect-to-event为骨架讲解由用户动作触发的副作用应直接写在事件处理器中这一 MEDIUM 级别重渲染优化规则并通过源码级分析说明其底层原理、判别方法与在 ZCode 中的实际落点。读完本文你将掌握一套可直接套用的代码审查与重构清单用于消灭由 effect 引发的重复副作用和无效渲染。一、规则档案rerender-move-effect-to-event该规则位于仓库的技能规则目录rules/rerender-move-effect-to-event.md元数据如下字段值titlePut Interaction Logic in Event HandlersimpactMEDIUMimpactDescriptionavoids effect re-runs and duplicate side effects避免 effect 重复执行与重复副作用tagsrerender, useEffect, events, side-effects, dependencies它属于 SKILL.md 中按优先级划分的 8 大规则类别之一的Re-render Optimization重渲染优化MEDIUM 优先级与rerender-memo、rerender-dependencies、rerender-derived-state-no-effect等 15 条规则并列。在汇总文档 AGENTS.md 的 5.8 节中同样收录了该规则的完整版本其 Impact 标注为MEDIUMavoids effect re-runs and duplicate side effects。规则核心一句话If a side effect is triggered by a specific user action (submit, click, drag), run it in that event handler. Do not model the action as state effect.即凡是由具体用户动作提交、点击、拖拽触发的副作用应该直接在该事件处理器里执行不要把动作建模成状态 effect。二、反模式把事件建模成状态 effect先看规则给出的反模式示例完整继承自原文档function Form() { const [submitted, setSubmitted] useState(false); const theme useContext(ThemeContext); useEffect(() { if (submitted) { post(/api/register); showToast(Registered, theme); } }, [submitted, theme]); return button onClick{() setSubmitted(true)}Submit/button; }这段代码表面上能工作但存在两个系统性缺陷effect 在无关变化下被反复触发依赖数组写的是[submitted, theme]。当theme例如主题上下文发生任何变化时React 都会重新执行 effect虽然if (submitted)门禁会拦住大部分重复但每一次theme变化都会触发 effect 的调度、比较与函数创建。如果后续在依赖数组中加入更多值用户信息、语言、其他 context这个 effect 的执行频率会进一步失控——这正是 rerender-dependencies缩小 effect 依赖规则试图解决的同类问题。副作用可能被重复执行在 React 严格模式StrictMode下开发环境中的 effect 会执行两次mount → unmount → remount 的模拟post(/api/register)会被调用两次造成重复提交注册请求。即使不在严格模式setSubmitted(true)触发的 re-render 与 effect 的异步调度之间也存在窗口期副作用执行时机与用户动作本身是解耦的很难保证恰好执行一次。执行时机不直观post与showToast的触发点从用户点击按钮的那一刻被推迟到了effect 运行的那一刻中间隔了至少一次渲染循环。这会让开发者对副作用何时发生失去直觉调试与代码审查的成本也随之上升。三、正模式把动作直接写进事件处理器规则给出的正确示例完整继承自原文档function Form() { const theme useContext(ThemeContext); function handleSubmit() { post(/api/register); showToast(Registered, theme); } return button onClick{handleSubmit}Submit/button; }两个关键变化删除了submitted状态动作不再需要状态记录 effect 监听两层建模副作用移到handleSubmit处理器中post与showToast在onClick触发的同一同步调用栈内执行恰好一次且时机与用户点击完全一致。由此消除了状态变量的额外一次渲染、依赖数组的维护负担、effect 对无关依赖如theme变化的响应以及严格模式下重复执行的隐患。同时theme的读取也从effect 依赖降级为处理器内即时读取语义更加清晰。四、底层原理effect 与事件处理器的本质差异从 React 渲染模型看事件处理器与 effect 的根本差异在于响应对象不同事件处理器响应的是用户动作它不属于渲染流程执行次数由用户操作次数决定天然是一次动作 一次执行effect 响应的是渲染结果变化只要依赖数组中的任何值在两次渲染间发生Object.is意义上的变化effect 就会被调度执行。任何被放进依赖数组的值都会扩大 effect 的执行面。因此把动作建模成状态本质上是在给 effect 制造一个额外的、人为的依赖submitted同时把动作本身强行塞进了 React 的渲染生命周期。这既增加了渲染次数状态变化必然引发一次 re-render又增加了 effect 的调度开销与重复执行风险。从仓库源码中可以看到 ZCode 大量组件已经遵循这一模式。以 GitActionMenu.tsx 为例其 Git 操作生成提交信息、包含未暂存变更、复制错误、提交等全部直接挂在onClick处理器上onClick{onGenerateMessage} onClick{() onIncludeUnstagedChange(!includeUnstaged)} onClick{handleCopyError} onClick{onSubmit}这些交互动作都没有被建模成pending状态 effect 监听而是作为回调直接执行正是本规则在真实大型项目中的标准落点。五、判别清单这段代码该放进事件处理器吗规则原文引用了 React 官方文档中 Removing Effect Dependencies 一节的判别标准原文为外链此处转述为可操作的自查清单。当你在 ZCode 或任何 React 项目中审查一个 effect 时逐条自问这段副作用是否由某个具体用户动作直接触发submit / click / drag / keydown……是 → 应移入对应的事件处理器副作用是否只在该动作发生时才有意义而不是响应某个状态/数据变化是 → 说明它被误建模为 effecteffect 依赖数组中是否出现了为了触发它而引入的布尔标志如submitted、saved、toggled是 → 这是事件伪装成状态的典型信号删除该 effect 后动作是否仍然能按原顺序完成是 → 可以安全移除。与官方文档一致的核心判据是Should this code move to an event handler?—— 如果代码与用户动作一一对应就应该在处理器里直接运行而不是等待 effect 的调度。与之呼应仓库中另一条规则 rerender-defer-reads 也强调如果动态状态如searchParams、localStorage只在回调内部被读取就不应该通过订阅/useState把它变成渲染依赖而是按需读取——两者是同一思想的两种表达把动作时需要的东西留给动作把渲染时需要的东西留给渲染。六、与相邻规则的协同一套完整的 effect 减负组合拳本规则不是孤立的。在 ZCode 的 Re-render Optimization 规则集中它与以下规则配合可以系统性减少 effect 的使用与重跑规则文件核心主张与本规则的关系rerender-move-effect-to-event.md交互副作用放进事件处理器从源头消除不必要 effectrerender-dependencies.md依赖用原始值user.id而非user派生布尔值计算在渲染外对确实需要保留的 effect压缩执行面rerender-derived-state-no-effect.md能由 props/state 推导的值在渲染期间推导不用 effect 同步 state消除为同步状态而生的 effectadvanced-effect-event-deps.mduseEffectEvent的结果不进 effect 依赖数组只依赖真实响应式值防止依赖数组因函数身份每渲染变化而反复重跑rerender-defer-reads.md仅在回调中使用的状态按需读取不订阅与事件处理器内即时读取互为补充例如当theme这类上下文值确实需要在副作用中使用时与其把theme放进依赖数组不如像本规则正例那样在处理器中直接读取若副作用必须由数据变化触发而非用户动作则应先用 rerender-dependencies 缩窄依赖用isMobile这类派生布尔值代替原始连续值如width避免 effect 在 767/766/765… 每一个中间值上都被触发。七、在 ZCode 中的实践建议ZCode 仓库中 UI 代码集中在 packages/ui/src核心交互组件表单、对话框、Git 操作菜单、会话任务列表等均适用本规则。在编写或审查代码时建议新增交互时先问这是动作还是状态变化动作 → 事件处理器数据/异步响应 → 才考虑 effect审查现有 effect 时检索布尔门禁 effectuseEffect(() { if (xxxFlag) {...} }, [xxxFlag, ...])的模式几乎都是本规则的改造对象结合 AGENTS.md 完整文档汇总文档 AGENTS.md 5.8 节提供了与本规则文件一致但带 Impact 注释的完整版本可作为团队内部代码评审的检查项来源在 AI 辅助开发流程中使用该技能设计上即面向编写、审查、重构 React/Next.js 代码的场景见 SKILL.md在生成新组件或重构旧代码时可直接把本规则作为约束注入提示词。结语rerender-move-effect-to-event是 React 重渲染优化中性价比极高的一条 MEDIUM 规则它不依赖memo、useCallback等额外开销仅通过重新放置副作用的位置就能同时消除多余渲染、重复副作用与依赖数组维护成本。判断标准始终只有一条——如果副作用由用户动作触发就让它活在事件处理器里而不是活在 effect 的生命周期里。配合依赖收窄、派生状态渲染期计算与useEffectEvent依赖纪律即可在 ZCode 这类大型工作台中保持渲染路径的干净与可预测。赞分享人工智能大模型代码智能体AI Agent桌面应用后端前端CLI【免费下载链接】ZCodeZCode 是 AI 编程工作台提供桌面应用、浏览器界面和终端 Agent。本仓库包含客户端、后端服务、共享 UI以及 Agent CLI 与运行时源码。项目地址https://gitcode.com/zai-org/ZCode点击查看免费下载相关推荐把交互逻辑放进事件处理器ZCode 中避免 useEffect 副作用重跑的 React 最佳实践把交互逻辑放进事件处理器ZCode 中避免 useEffect 副作用重跑的 React 最佳实践 导读 在 React 组件中当一个副作用如发起网络请求MediaGo 前端实践把交互逻辑放进事件处理器告别 useEffect 重复执行MediaGo 前端实践把交互逻辑放进事件处理器告别 useEffect 重复执行 导读 在 React 组件中把点击提交这类一次性用户动作建模成状音视频桌面应用后端React 重渲染优化把交互副作用从 useEffect 迁移到事件处理器——OpenMontage 中的 Vercel 最佳实践React 重渲染优化把交互副作用从 useEffect 迁移到事件处理器——OpenMontage 中的 Vercel 最佳实践 导读 在 React 组件人工智能AI Agent音视频媒体生成工作流自动化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ZCode 中的 React 重渲染优化：把交互逻辑放进事件处理器，而不是 useEffect
人工智能大模型代码智能体AI Agent桌面应用后端前端CLI【免费下载链接】ZCodeZCode 是 AI 编程工作台提供桌面应用、浏览器界面和终端 Agent。本仓库包含客户端、后端服务、共享 UI以及 Agent CLI 与运行时源码。项目地址https://gitcode.com/zai-org/ZCode点击查看免费下载导读在 ZCode 这样的大型 React/Next.js 工作台桌面应用、浏览器界面、终端 Agent 三端同构中表单提交、点击、拖拽等交互动作如果被错误建模成state effect会导致 effect 在无关状态变化时反复执行、副作用重复触发造成不必要的重渲染与重复请求。本篇指南以 ZCode 仓库内置的 Vercel React Best Practices 技能规则rerender-move-effect-to-event为骨架讲解由用户动作触发的副作用应直接写在事件处理器中这一 MEDIUM 级别重渲染优化规则并通过源码级分析说明其底层原理、判别方法与在 ZCode 中的实际落点。读完本文你将掌握一套可直接套用的代码审查与重构清单用于消灭由 effect 引发的重复副作用和无效渲染。一、规则档案rerender-move-effect-to-event该规则位于仓库的技能规则目录rules/rerender-move-effect-to-event.md元数据如下字段值titlePut Interaction Logic in Event HandlersimpactMEDIUMimpactDescriptionavoids effect re-runs and duplicate side effects避免 effect 重复执行与重复副作用tagsrerender, useEffect, events, side-effects, dependencies它属于 SKILL.md 中按优先级划分的 8 大规则类别之一的Re-render Optimization重渲染优化MEDIUM 优先级与rerender-memo、rerender-dependencies、rerender-derived-state-no-effect等 15 条规则并列。在汇总文档 AGENTS.md 的 5.8 节中同样收录了该规则的完整版本其 Impact 标注为MEDIUMavoids effect re-runs and duplicate side effects。规则核心一句话If a side effect is triggered by a specific user action (submit, click, drag), run it in that event handler. Do not model the action as state effect.即凡是由具体用户动作提交、点击、拖拽触发的副作用应该直接在该事件处理器里执行不要把动作建模成状态 effect。二、反模式把事件建模成状态 effect先看规则给出的反模式示例完整继承自原文档function Form() { const [submitted, setSubmitted] useState(false); const theme useContext(ThemeContext); useEffect(() { if (submitted) { post(/api/register); showToast(Registered, theme); } }, [submitted, theme]); return button onClick{() setSubmitted(true)}Submit/button; }这段代码表面上能工作但存在两个系统性缺陷effect 在无关变化下被反复触发依赖数组写的是[submitted, theme]。当theme例如主题上下文发生任何变化时React 都会重新执行 effect虽然if (submitted)门禁会拦住大部分重复但每一次theme变化都会触发 effect 的调度、比较与函数创建。如果后续在依赖数组中加入更多值用户信息、语言、其他 context这个 effect 的执行频率会进一步失控——这正是 rerender-dependencies缩小 effect 依赖规则试图解决的同类问题。副作用可能被重复执行在 React 严格模式StrictMode下开发环境中的 effect 会执行两次mount → unmount → remount 的模拟post(/api/register)会被调用两次造成重复提交注册请求。即使不在严格模式setSubmitted(true)触发的 re-render 与 effect 的异步调度之间也存在窗口期副作用执行时机与用户动作本身是解耦的很难保证恰好执行一次。执行时机不直观post与showToast的触发点从用户点击按钮的那一刻被推迟到了effect 运行的那一刻中间隔了至少一次渲染循环。这会让开发者对副作用何时发生失去直觉调试与代码审查的成本也随之上升。三、正模式把动作直接写进事件处理器规则给出的正确示例完整继承自原文档function Form() { const theme useContext(ThemeContext); function handleSubmit() { post(/api/register); showToast(Registered, theme); } return button onClick{handleSubmit}Submit/button; }两个关键变化删除了submitted状态动作不再需要状态记录 effect 监听两层建模副作用移到handleSubmit处理器中post与showToast在onClick触发的同一同步调用栈内执行恰好一次且时机与用户点击完全一致。由此消除了状态变量的额外一次渲染、依赖数组的维护负担、effect 对无关依赖如theme变化的响应以及严格模式下重复执行的隐患。同时theme的读取也从effect 依赖降级为处理器内即时读取语义更加清晰。四、底层原理effect 与事件处理器的本质差异从 React 渲染模型看事件处理器与 effect 的根本差异在于响应对象不同事件处理器响应的是用户动作它不属于渲染流程执行次数由用户操作次数决定天然是一次动作 一次执行effect 响应的是渲染结果变化只要依赖数组中的任何值在两次渲染间发生Object.is意义上的变化effect 就会被调度执行。任何被放进依赖数组的值都会扩大 effect 的执行面。因此把动作建模成状态本质上是在给 effect 制造一个额外的、人为的依赖submitted同时把动作本身强行塞进了 React 的渲染生命周期。这既增加了渲染次数状态变化必然引发一次 re-render又增加了 effect 的调度开销与重复执行风险。从仓库源码中可以看到 ZCode 大量组件已经遵循这一模式。以 GitActionMenu.tsx 为例其 Git 操作生成提交信息、包含未暂存变更、复制错误、提交等全部直接挂在onClick处理器上onClick{onGenerateMessage} onClick{() onIncludeUnstagedChange(!includeUnstaged)} onClick{handleCopyError} onClick{onSubmit}这些交互动作都没有被建模成pending状态 effect 监听而是作为回调直接执行正是本规则在真实大型项目中的标准落点。五、判别清单这段代码该放进事件处理器吗规则原文引用了 React 官方文档中 Removing Effect Dependencies 一节的判别标准原文为外链此处转述为可操作的自查清单。当你在 ZCode 或任何 React 项目中审查一个 effect 时逐条自问这段副作用是否由某个具体用户动作直接触发submit / click / drag / keydown……是 → 应移入对应的事件处理器副作用是否只在该动作发生时才有意义而不是响应某个状态/数据变化是 → 说明它被误建模为 effecteffect 依赖数组中是否出现了为了触发它而引入的布尔标志如submitted、saved、toggled是 → 这是事件伪装成状态的典型信号删除该 effect 后动作是否仍然能按原顺序完成是 → 可以安全移除。与官方文档一致的核心判据是Should this code move to an event handler?—— 如果代码与用户动作一一对应就应该在处理器里直接运行而不是等待 effect 的调度。与之呼应仓库中另一条规则 rerender-defer-reads 也强调如果动态状态如searchParams、localStorage只在回调内部被读取就不应该通过订阅/useState把它变成渲染依赖而是按需读取——两者是同一思想的两种表达把动作时需要的东西留给动作把渲染时需要的东西留给渲染。六、与相邻规则的协同一套完整的 effect 减负组合拳本规则不是孤立的。在 ZCode 的 Re-render Optimization 规则集中它与以下规则配合可以系统性减少 effect 的使用与重跑规则文件核心主张与本规则的关系rerender-move-effect-to-event.md交互副作用放进事件处理器从源头消除不必要 effectrerender-dependencies.md依赖用原始值user.id而非user派生布尔值计算在渲染外对确实需要保留的 effect压缩执行面rerender-derived-state-no-effect.md能由 props/state 推导的值在渲染期间推导不用 effect 同步 state消除为同步状态而生的 effectadvanced-effect-event-deps.mduseEffectEvent的结果不进 effect 依赖数组只依赖真实响应式值防止依赖数组因函数身份每渲染变化而反复重跑rerender-defer-reads.md仅在回调中使用的状态按需读取不订阅与事件处理器内即时读取互为补充例如当theme这类上下文值确实需要在副作用中使用时与其把theme放进依赖数组不如像本规则正例那样在处理器中直接读取若副作用必须由数据变化触发而非用户动作则应先用 rerender-dependencies 缩窄依赖用isMobile这类派生布尔值代替原始连续值如width避免 effect 在 767/766/765… 每一个中间值上都被触发。七、在 ZCode 中的实践建议ZCode 仓库中 UI 代码集中在 packages/ui/src核心交互组件表单、对话框、Git 操作菜单、会话任务列表等均适用本规则。在编写或审查代码时建议新增交互时先问这是动作还是状态变化动作 → 事件处理器数据/异步响应 → 才考虑 effect审查现有 effect 时检索布尔门禁 effectuseEffect(() { if (xxxFlag) {...} }, [xxxFlag, ...])的模式几乎都是本规则的改造对象结合 AGENTS.md 完整文档汇总文档 AGENTS.md 5.8 节提供了与本规则文件一致但带 Impact 注释的完整版本可作为团队内部代码评审的检查项来源在 AI 辅助开发流程中使用该技能设计上即面向编写、审查、重构 React/Next.js 代码的场景见 SKILL.md在生成新组件或重构旧代码时可直接把本规则作为约束注入提示词。结语rerender-move-effect-to-event是 React 重渲染优化中性价比极高的一条 MEDIUM 规则它不依赖memo、useCallback等额外开销仅通过重新放置副作用的位置就能同时消除多余渲染、重复副作用与依赖数组维护成本。判断标准始终只有一条——如果副作用由用户动作触发就让它活在事件处理器里而不是活在 effect 的生命周期里。配合依赖收窄、派生状态渲染期计算与useEffectEvent依赖纪律即可在 ZCode 这类大型工作台中保持渲染路径的干净与可预测。赞分享人工智能大模型代码智能体AI Agent桌面应用后端前端CLI【免费下载链接】ZCodeZCode 是 AI 编程工作台提供桌面应用、浏览器界面和终端 Agent。本仓库包含客户端、后端服务、共享 UI以及 Agent CLI 与运行时源码。项目地址https://gitcode.com/zai-org/ZCode点击查看免费下载相关推荐把交互逻辑放进事件处理器ZCode 中避免 useEffect 副作用重跑的 React 最佳实践把交互逻辑放进事件处理器ZCode 中避免 useEffect 副作用重跑的 React 最佳实践 导读 在 React 组件中当一个副作用如发起网络请求MediaGo 前端实践把交互逻辑放进事件处理器告别 useEffect 重复执行MediaGo 前端实践把交互逻辑放进事件处理器告别 useEffect 重复执行 导读 在 React 组件中把点击提交这类一次性用户动作建模成状音视频桌面应用后端React 重渲染优化把交互副作用从 useEffect 迁移到事件处理器——OpenMontage 中的 Vercel 最佳实践React 重渲染优化把交互副作用从 useEffect 迁移到事件处理器——OpenMontage 中的 Vercel 最佳实践 导读 在 React 组件人工智能AI Agent音视频媒体生成工作流自动化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
