尧图网站建设 
React 重渲染优化把交互副作用从 useEffect 迁移到事件处理器——OpenMontage 中的 Vercel 最佳实践【免费下载链接】OpenMontageWorlds first open-source, agentic video production system. 12 production pipelines, 100 tools, 700 agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage导读在 React 组件中由用户动作点击、提交、拖拽触发的副作用应当直接写在事件处理器里而不是建模成状态 Effect。本文以 OpenMontage 仓库内置的 Vercel React Best Practices 技能规则规则名rerender-move-effect-to-event影响等级 MEDIUM为核心逐行拆解反模式与正确写法并给出可在日常开发中直接套用的判断准则。读完你将掌握如何识别被 Effect 误用的交互逻辑、为什么它会导致 Effect 在无关变更时重跑与副作用重复执行以及如何在事件处理器中干净地完成同样的操作。规则速览这条规则在讲什么该规则位于 OpenMontage 仓库 .claude/skills/vercel-react-best-practices 技能包的 Re-render Optimization重渲染优化分类下规则文件为 rules/rerender-move-effect-to-event.md其 frontmatter 元信息如下字段值含义titlePut Interaction Logic in Event Handlers规则标题把交互逻辑放进事件处理器impactMEDIUM影响等级中等性能提升impactDescriptionavoids effect re-runs and duplicate side effects收益避免 Effect 重跑与重复副作用tagsrerender, useEffect, events, side-effects, dependencies检索标签根据同目录 rules/_sections.md 的定义rerender-前缀属于第 5 节 Re-render Optimization影响等级为 MEDIUM目标是减少不必要的重渲染以降低浪费的计算并提升 UI 响应性。这份规则也被编译进了技能包的 AGENTS.md章节 5.8L1653-L1692供 Agent 和 LLM 在审查、重构 React 代码时直接引用。规则的核心主张只有一句话如果一个副作用是由某个具体用户动作提交、点击、拖拽触发的就把它写进那个事件处理器里不要建模成状态 Effect。为什么动作即状态 Effect是反模式把交互逻辑放进 Effect 会带来两类典型问题1. Effect 在无关变更时重跑。Effect 的依赖数组是声明式的重跑条件只要任一依赖引用变化Effect 就会重新执行。当交互逻辑被塞进 Effect 后它的执行时机不再由用户是否点了按钮决定而是由依赖是否变化决定。任何进入依赖数组的值——哪怕与本次提交毫无关系——都可能重新触发一遍副作用。2. 副作用可能被重复执行。同一个副作用既有依赖变化触发的重跑又有开发模式下 StrictMode 对 Effect 的双重调用React 在开发环境会故意挂载→卸载→再挂载以暴露副作用不幂等的问题还可能被多次 setState 驱动多次执行。用户期望点一次提交发一次请求但 Effect 版本可能发两次、三次甚至更多。从 React 的运行时语义看这两类问题几乎是结构性的useEffect的职责是与外部系统同步它运行在渲染提交之后是对组件状态到外部世界的声明式反应而事件处理器运行在用户动作发生的那一刻是命令式的、确定性的。把某次点击要做的事伪装成某份状态变化后要做的事既扭曲了 Effect 的语义也放弃了事件处理器天然具备的一次动作一次执行的确定性。反模式逐行拆解表单提交被建模成状态 Effect规则文件给出的反模式示例是一个注册表单提交动作被建模成了submitted状态 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 }逐行分析这段代码的问题状态被用于表达动作而非数据submitted本质是一次性事件标记不是组件需要持续维护的 UI 数据。它被 setState 后组件会多一次渲染但这次渲染本身没有产出任何新的 UI 内容。Effect 依赖了themetheme来自ThemeContext它只是被showToast用来渲染提示样式。但由于theme进入了依赖数组只要主题发生变化即使submitted早已为trueEffect 也会重跑再次调用post(/api/register)和showToast——用户可能已经提交成功却会被重复注册、重复弹提示。重跑时读到的状态可能滞后Effect 在渲染提交后运行它读到的是触发那次渲染时的快照而事件处理器读到的是动作发生瞬间的上下文语义更直接。无法表达恰好执行一次只要依赖数组中任一值变化Effect 就会重跑。要用 Effect 实现只提交一次你不得不再引入额外的标志位如submittedAt来手动防重复杂度向上蔓延。注意这里post(/api/register)和showToast(Registered, theme)都是不纯的副作用网络请求、全局 UI 提示它们共同构成了提交动作的完整语义。把这两个调用塞进 Effect等于把动作与渲染生命周期强行耦合。正确写法在事件处理器中完成交互规则给出的修正版本如下function Form() { const theme useContext(ThemeContext) function handleSubmit() { post(/api/register) showToast(Registered, theme) } return button onClick{handleSubmit}Submit/button }这个版本的关键改进副作用直接绑定在onClick上handleSubmit只在按钮被点击时执行执行次数与点击次数严格一一对应不存在依赖变化导致的重跑。不再有submitted状态移除了一个只为标记已提交而存在的布尔状态省掉了由此带来的额外渲染。theme不再是依赖它只是在处理器内部被读取的普通变量。用户点击时闭包捕获的theme就是当前上下文的最新值而主题变化也不会再触发任何重跑。事件处理器天然幂等可控即使开发模式或用户连点行为也符合直觉——点几次执行几次不会出现没点也执行的意外。从行为上看两个版本在首次点击提交这一时刻做的事情相同但事件处理器版本在任何其他时刻都不做任何事而 Effect 版本在theme变化时依然可能重复提交——这就是两种写法在正确性上的本质差异。判断准则什么时候该把代码移进事件处理器参考 React 官方文档在 Removing Effect Dependencies 一节提出的经典问题本规则的 Reference 即指向该节Should this code move to an event handler?可以从三个维度判断✅ 应该移进事件处理器的情况副作用由明确的用户动作触发submit、click、drag、keydown、change该副作用不需要等待渲染结果不依赖本次渲染产出的新状态代码只在用户动作发生时才有意义对状态变化本身没有反应性需求。❌ 应该保留在 Effect 里的情况与外部系统同步订阅 WebSocket/EventSource、注册全局监听器、操作非 React 管理的 DOM 节点初始化/清理配对逻辑Effect 返回 cleanup对状态变化而非用户动作的反应例如当数据到达时更新图表这类真正的响应式逻辑。一个实用的自检问句如果我把这段代码从 Effect 移到 onClick 里会不会丢失任何必要的行为如果答案是否定的那它从一开始就不该待在 Effect 里。仓库内的实践佐证Backlot UI 的事件驱动写法OpenMontage 的 backlot/ui 目录Backlot 项目看板的浏览器端 UI虽然使用原生 JS 而非 React但其事件处理方式恰好印证了同一条原则由用户动作触发的逻辑直接挂在事件监听器上而不是建模成状态流转。lib.js 的el()辅助函数L9-L22约定属性名以on开头的都直接转成addEventListener如onClick→click监听器把交互行为绑定作为创建 DOM 节点的一等公民board.js 中Esc 键关闭弹窗L566、点击弹窗遮罩关闭弹窗L567、点击视频切换播放/暂停L834等交互副作用全部直接写在对应的事件监听器回调里没有引入shouldClose 状态 Effect这类间接建模。这从侧面说明无论 React 还是原生 DOM把交互副作用放在事件处理器里都是更直接、更可控的组织方式。而在 OpenMontage 的 remotion-composer/srcRemotion 视频合成器基于 React 组件树渲染画面这类 React 代码中这条规则的价值在于每一帧渲染都昂贵任何被 Effect 放大的重复副作用都可能转化为额外的渲染与合成开销。与同族规则的配合使用这条规则不是孤立的它在技能包中与多份rerender-系列规则形成配套重构时常常一起应用rerender-dependencies.md收窄 Effect 依赖——依赖里用user.id而不是user对象派生布尔值如isMobile在渲染期计算而非订阅原始值。与本文规则配合先把该进事件处理器的移出去剩下的 Effect 再尽量收窄依赖rerender-derived-state-no-effect.md能在渲染期算出来的派生值如fullName不要在 Effect 里 setState与不要把动作建模成状态是同一思路的两个侧面advanced-use-latest.md当回调如防抖后的onSearch需要在 Effect 内读取最新值而又不能进依赖数组时用useEffectEvent或 ref 方案替代避免为了拿最新值把函数塞进依赖导致无限重跑的常见陷阱rerender-functional-setstate.md事件处理器里更新状态时使用函数式 setState让回调更稳定、可安全复用。一个典型的重构路径是先从组件中把所有由交互触发但被放进 Effect的副作用搬进事件处理器本文规则再审视剩余 Effect 的依赖是否过宽rerender-dependencies.md最后检查其中是否混入了本可在渲染期计算的派生值rerender-derived-state-no-effect.md。落地检查清单在代码评审或 Agent 自动重构时可用以下清单快速验收触发源检查这段副作用是否由 submit/click/drag/keydown 等用户动作触发若是应写在对应事件处理器中无状态建模是否存在只为触发一次副作用而存在的布尔/枚举状态如submitted、saved应删除并改为直接调用依赖数组警示Effect 依赖数组中是否有仅被内部副作用读取、与反应逻辑无关的值如示例中的theme这通常意味着副作用放错了位置重复执行验证在开发模式StrictMode 双调用与主题/上下文变化场景下副作用是否只按用户动作次数执行若否优先迁移到事件处理器保留 Effect 的合理性若代码确实属于外部系统同步、订阅或初始化清理则保留 Effect并配合收窄依赖、函数式 setState 等相邻规则继续优化。延伸阅读本规则原文rules/rerender-move-effect-to-event.md技能包入口含 65 条规则总览与优先级排序.claude/skills/vercel-react-best-practices/SKILL.md编译后的完整指南含全部 8 个分类与代码示例.claude/skills/vercel-react-best-practices/AGENTS.md分类元信息各分区影响等级与描述.claude/skills/vercel-react-best-practices/rules/_sections.md新规则模板规则文件的结构约定.claude/skills/vercel-react-best-practices/rules/_template.md仓库内事件驱动 UI 佐证backlot/ui/lib.js、backlot/ui/board.js【免费下载链接】OpenMontageWorlds first open-source, agentic video production system. 12 production pipelines, 100 tools, 700 agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 React 重渲染优化：把交互副作用从 useEffect 迁移到事件处理器——OpenMontage 中的 Vercel 最佳实践
React 重渲染优化把交互副作用从 useEffect 迁移到事件处理器——OpenMontage 中的 Vercel 最佳实践【免费下载链接】OpenMontageWorlds first open-source, agentic video production system. 12 production pipelines, 100 tools, 700 agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage导读在 React 组件中由用户动作点击、提交、拖拽触发的副作用应当直接写在事件处理器里而不是建模成状态 Effect。本文以 OpenMontage 仓库内置的 Vercel React Best Practices 技能规则规则名rerender-move-effect-to-event影响等级 MEDIUM为核心逐行拆解反模式与正确写法并给出可在日常开发中直接套用的判断准则。读完你将掌握如何识别被 Effect 误用的交互逻辑、为什么它会导致 Effect 在无关变更时重跑与副作用重复执行以及如何在事件处理器中干净地完成同样的操作。规则速览这条规则在讲什么该规则位于 OpenMontage 仓库 .claude/skills/vercel-react-best-practices 技能包的 Re-render Optimization重渲染优化分类下规则文件为 rules/rerender-move-effect-to-event.md其 frontmatter 元信息如下字段值含义titlePut Interaction Logic in Event Handlers规则标题把交互逻辑放进事件处理器impactMEDIUM影响等级中等性能提升impactDescriptionavoids effect re-runs and duplicate side effects收益避免 Effect 重跑与重复副作用tagsrerender, useEffect, events, side-effects, dependencies检索标签根据同目录 rules/_sections.md 的定义rerender-前缀属于第 5 节 Re-render Optimization影响等级为 MEDIUM目标是减少不必要的重渲染以降低浪费的计算并提升 UI 响应性。这份规则也被编译进了技能包的 AGENTS.md章节 5.8L1653-L1692供 Agent 和 LLM 在审查、重构 React 代码时直接引用。规则的核心主张只有一句话如果一个副作用是由某个具体用户动作提交、点击、拖拽触发的就把它写进那个事件处理器里不要建模成状态 Effect。为什么动作即状态 Effect是反模式把交互逻辑放进 Effect 会带来两类典型问题1. Effect 在无关变更时重跑。Effect 的依赖数组是声明式的重跑条件只要任一依赖引用变化Effect 就会重新执行。当交互逻辑被塞进 Effect 后它的执行时机不再由用户是否点了按钮决定而是由依赖是否变化决定。任何进入依赖数组的值——哪怕与本次提交毫无关系——都可能重新触发一遍副作用。2. 副作用可能被重复执行。同一个副作用既有依赖变化触发的重跑又有开发模式下 StrictMode 对 Effect 的双重调用React 在开发环境会故意挂载→卸载→再挂载以暴露副作用不幂等的问题还可能被多次 setState 驱动多次执行。用户期望点一次提交发一次请求但 Effect 版本可能发两次、三次甚至更多。从 React 的运行时语义看这两类问题几乎是结构性的useEffect的职责是与外部系统同步它运行在渲染提交之后是对组件状态到外部世界的声明式反应而事件处理器运行在用户动作发生的那一刻是命令式的、确定性的。把某次点击要做的事伪装成某份状态变化后要做的事既扭曲了 Effect 的语义也放弃了事件处理器天然具备的一次动作一次执行的确定性。反模式逐行拆解表单提交被建模成状态 Effect规则文件给出的反模式示例是一个注册表单提交动作被建模成了submitted状态 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 }逐行分析这段代码的问题状态被用于表达动作而非数据submitted本质是一次性事件标记不是组件需要持续维护的 UI 数据。它被 setState 后组件会多一次渲染但这次渲染本身没有产出任何新的 UI 内容。Effect 依赖了themetheme来自ThemeContext它只是被showToast用来渲染提示样式。但由于theme进入了依赖数组只要主题发生变化即使submitted早已为trueEffect 也会重跑再次调用post(/api/register)和showToast——用户可能已经提交成功却会被重复注册、重复弹提示。重跑时读到的状态可能滞后Effect 在渲染提交后运行它读到的是触发那次渲染时的快照而事件处理器读到的是动作发生瞬间的上下文语义更直接。无法表达恰好执行一次只要依赖数组中任一值变化Effect 就会重跑。要用 Effect 实现只提交一次你不得不再引入额外的标志位如submittedAt来手动防重复杂度向上蔓延。注意这里post(/api/register)和showToast(Registered, theme)都是不纯的副作用网络请求、全局 UI 提示它们共同构成了提交动作的完整语义。把这两个调用塞进 Effect等于把动作与渲染生命周期强行耦合。正确写法在事件处理器中完成交互规则给出的修正版本如下function Form() { const theme useContext(ThemeContext) function handleSubmit() { post(/api/register) showToast(Registered, theme) } return button onClick{handleSubmit}Submit/button }这个版本的关键改进副作用直接绑定在onClick上handleSubmit只在按钮被点击时执行执行次数与点击次数严格一一对应不存在依赖变化导致的重跑。不再有submitted状态移除了一个只为标记已提交而存在的布尔状态省掉了由此带来的额外渲染。theme不再是依赖它只是在处理器内部被读取的普通变量。用户点击时闭包捕获的theme就是当前上下文的最新值而主题变化也不会再触发任何重跑。事件处理器天然幂等可控即使开发模式或用户连点行为也符合直觉——点几次执行几次不会出现没点也执行的意外。从行为上看两个版本在首次点击提交这一时刻做的事情相同但事件处理器版本在任何其他时刻都不做任何事而 Effect 版本在theme变化时依然可能重复提交——这就是两种写法在正确性上的本质差异。判断准则什么时候该把代码移进事件处理器参考 React 官方文档在 Removing Effect Dependencies 一节提出的经典问题本规则的 Reference 即指向该节Should this code move to an event handler?可以从三个维度判断✅ 应该移进事件处理器的情况副作用由明确的用户动作触发submit、click、drag、keydown、change该副作用不需要等待渲染结果不依赖本次渲染产出的新状态代码只在用户动作发生时才有意义对状态变化本身没有反应性需求。❌ 应该保留在 Effect 里的情况与外部系统同步订阅 WebSocket/EventSource、注册全局监听器、操作非 React 管理的 DOM 节点初始化/清理配对逻辑Effect 返回 cleanup对状态变化而非用户动作的反应例如当数据到达时更新图表这类真正的响应式逻辑。一个实用的自检问句如果我把这段代码从 Effect 移到 onClick 里会不会丢失任何必要的行为如果答案是否定的那它从一开始就不该待在 Effect 里。仓库内的实践佐证Backlot UI 的事件驱动写法OpenMontage 的 backlot/ui 目录Backlot 项目看板的浏览器端 UI虽然使用原生 JS 而非 React但其事件处理方式恰好印证了同一条原则由用户动作触发的逻辑直接挂在事件监听器上而不是建模成状态流转。lib.js 的el()辅助函数L9-L22约定属性名以on开头的都直接转成addEventListener如onClick→click监听器把交互行为绑定作为创建 DOM 节点的一等公民board.js 中Esc 键关闭弹窗L566、点击弹窗遮罩关闭弹窗L567、点击视频切换播放/暂停L834等交互副作用全部直接写在对应的事件监听器回调里没有引入shouldClose 状态 Effect这类间接建模。这从侧面说明无论 React 还是原生 DOM把交互副作用放在事件处理器里都是更直接、更可控的组织方式。而在 OpenMontage 的 remotion-composer/srcRemotion 视频合成器基于 React 组件树渲染画面这类 React 代码中这条规则的价值在于每一帧渲染都昂贵任何被 Effect 放大的重复副作用都可能转化为额外的渲染与合成开销。与同族规则的配合使用这条规则不是孤立的它在技能包中与多份rerender-系列规则形成配套重构时常常一起应用rerender-dependencies.md收窄 Effect 依赖——依赖里用user.id而不是user对象派生布尔值如isMobile在渲染期计算而非订阅原始值。与本文规则配合先把该进事件处理器的移出去剩下的 Effect 再尽量收窄依赖rerender-derived-state-no-effect.md能在渲染期算出来的派生值如fullName不要在 Effect 里 setState与不要把动作建模成状态是同一思路的两个侧面advanced-use-latest.md当回调如防抖后的onSearch需要在 Effect 内读取最新值而又不能进依赖数组时用useEffectEvent或 ref 方案替代避免为了拿最新值把函数塞进依赖导致无限重跑的常见陷阱rerender-functional-setstate.md事件处理器里更新状态时使用函数式 setState让回调更稳定、可安全复用。一个典型的重构路径是先从组件中把所有由交互触发但被放进 Effect的副作用搬进事件处理器本文规则再审视剩余 Effect 的依赖是否过宽rerender-dependencies.md最后检查其中是否混入了本可在渲染期计算的派生值rerender-derived-state-no-effect.md。落地检查清单在代码评审或 Agent 自动重构时可用以下清单快速验收触发源检查这段副作用是否由 submit/click/drag/keydown 等用户动作触发若是应写在对应事件处理器中无状态建模是否存在只为触发一次副作用而存在的布尔/枚举状态如submitted、saved应删除并改为直接调用依赖数组警示Effect 依赖数组中是否有仅被内部副作用读取、与反应逻辑无关的值如示例中的theme这通常意味着副作用放错了位置重复执行验证在开发模式StrictMode 双调用与主题/上下文变化场景下副作用是否只按用户动作次数执行若否优先迁移到事件处理器保留 Effect 的合理性若代码确实属于外部系统同步、订阅或初始化清理则保留 Effect并配合收窄依赖、函数式 setState 等相邻规则继续优化。延伸阅读本规则原文rules/rerender-move-effect-to-event.md技能包入口含 65 条规则总览与优先级排序.claude/skills/vercel-react-best-practices/SKILL.md编译后的完整指南含全部 8 个分类与代码示例.claude/skills/vercel-react-best-practices/AGENTS.md分类元信息各分区影响等级与描述.claude/skills/vercel-react-best-practices/rules/_sections.md新规则模板规则文件的结构约定.claude/skills/vercel-react-best-practices/rules/_template.md仓库内事件驱动 UI 佐证backlot/ui/lib.js、backlot/ui/board.js【免费下载链接】OpenMontageWorlds first open-source, agentic video production system. 12 production pipelines, 100 tools, 700 agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考