前端教程【免费下载链接】preguntas-entrevista-reactPreguntas típicas sobre React para entrevistas de trabajo ⚛️项目地址https://gitcode.com/gh_mirrors/pr/preguntas-entrevista-react点击查看免费下载导读在 React 组件中把多个相互独立、依赖各不相同的计算或副作用塞进同一个useMemo/useEffect会让组件在任意一个依赖变化时白白重跑无关逻辑造成不必要的重渲染计算开销。本文基于仓库内 Vercel React 最佳实践技能集.agents/skills/vercel-react-best-practices中编号 5.9 的规则rerender-split-combined-hooks系统讲解“拆分组合 Hook 计算”的原理、代码范式与适用边界并结合技能集中的关联规则说明何时不该盲目拆分。读完你就能在编写或重构 React 组件时准确判断哪些useMemo/useEffect该拆、怎么拆以及 React Compiler 开启后这些手工优化还有没有必要。规则出处Vercel React 最佳实践中的 Re-render 优化分类该规则位于仓库 .agents/skills/vercel-react-best-practices/rules/rerender-split-combined-hooks.md是 Vercel 工程团队沉淀的 69 条 React/Next.js 性能优化规则之一。技能集按影响级别把规则划分为 8 大类见 SKILL.md优先级分类影响级别文件前缀1消除瀑布流Eliminating WaterfallsCRITICALasync-2包体积优化Bundle Size OptimizationCRITICALbundle-3服务端性能Server-Side PerformanceHIGHserver-4客户端数据获取Client-Side Data FetchingMEDIUM-HIGHclient-5重渲染优化Re-render OptimizationMEDIUMrerender-6渲染性能Rendering PerformanceMEDIUMrendering-7JavaScript 性能JavaScript PerformanceLOW-MEDIUMjs-8高级模式Advanced PatternsLOWadvanced-本文讨论的规则归属第 5 类“重渲染优化”影响级别为MEDIUM其impactDescription是avoids recomputing independent steps避免重复计算相互独立的步骤。也就是说这条规则解决的不是“减少渲染次数”而是减少单次渲染中useMemo/useEffect内部不必要的重复工作。规则文件的 frontmatter 明确给出了它的定位--- title: Split Combined Hook Computations impact: MEDIUM impactDescription: avoids recomputing independent steps tags: rerender, useMemo, useEffect, dependencies, optimization ---每一条规则文件都遵循 rules/_template.md 的“错误示例 正确示例 影响说明”结构并最终汇总到编译产物 AGENTS.md 中。规则所属小节的定义见 rules/_sections.mdReducing unnecessary re-renders minimizes wasted computation and improves UI responsiveness——这正是本文拆分的核心目标。核心问题组合 Hook 的“计算放大”效应规则原文对问题的定义非常精确When a hook contains multiple independent tasks with different dependencies, split them into separate hooks. A combined hook reruns all tasks when any dependency changes, even if some tasks dont use the changed value.翻译成白话只要一个 Hook 里塞了多个相互独立的子任务且这些子任务的依赖各不相同就应该拆成多个 Hook。因为合并后的 Hook 只要任一依赖变化就会把所有子任务全部重跑一遍哪怕其中某些子任务根本用不到那个变化的值。以useMemo为例它的语义是仅当依赖数组deps中的某个值与上一次渲染不同时才重新执行工厂函数。依赖数组是一个粗粒度的整体——它无法表达“函数内部哪一段代码依赖哪个值”。因此依赖粒度越粗一个数组里塞的依赖越多函数被重执行的频率就越高函数内被重执行的工作量越大比如过滤 排序整张列表浪费的计算就越多对大数据量场景这种浪费会直接反映为掉帧、卡顿和主线程长时间占用。所以拆分的本质是让每个useMemo/useEffect的依赖数组恰好覆盖它真正用到的值把“重计算的范围”收窄到最小。实战范式一拆分useMemo中相互独立的计算链规则给出的典型场景是“先过滤、再排序”的商品列表。先看错误写法——过滤和排序共用一个useMemo// 错误改变 sortOrder 会连带重新执行过滤 const sortedProducts useMemo(() { const filtered products.filter((p) p.category category) const sorted filtered.toSorted((a, b) sortOrder asc ? a.price - b.price : b.price - a.price ) return sorted }, [products, category, sortOrder])这里products、category、sortOrder三个依赖共享同一个依赖数组。当用户只切换排序方向sortOrder变化时React 会判定依赖变化把整个工厂函数重跑一遍——其中products.filter(...)这步完全没用到sortOrder属于纯粹的浪费。如果products有上千条记录每次切换排序都要无谓地重新遍历整张列表做过滤。再来看正确写法——把过滤和排序拆成两个useMemo各自只依赖自己真正用到的值// 正确过滤只会在 products 或 category 变化时重算 const filteredProducts useMemo( () products.filter((p) p.category category), [products, category] ) const sortedProducts useMemo( () filteredProducts.toSorted((a, b) sortOrder asc ? a.price - b.price : b.price - a.price ), [filteredProducts, sortOrder] )拆分后的收益非常直观场景合并写法拆分写法products/category变化过滤 排序全部重跑过滤重跑 → 排序因filteredProducts引用变化而重跑逻辑正确无重复仅sortOrder变化过滤 排序全部重跑过滤白跑一次过滤不重跑只重跑排序两者都不变不重跑不重跑这里还有两个值得注意的实现细节toSorted()保证不可变性示例使用Array.prototype.toSorted()返回新数组而非原地排序这让filteredProducts的引用值能够作为第二个useMemo的正确依赖——只有过滤结果真正变化时排序才会重算。这一点与技能集第 7 类中的js-tosorted-immutable规则见 rules/js-tosorted-immutable.md相互印证。若使用原地sort()filteredProducts的引用不变第二个useMemo可能被错误地跳过依赖比较只做引用浅比较。依赖数组的“引用链”第二个useMemo的依赖是[filteredProducts, sortOrder]其中filteredProducts是第一个useMemo的输出。这种“派生值的依赖链”是 React 推荐的组合方式——中间结果本身就是可被缓存、可被依赖的稳定引用。实战范式二拆分useEffect中互不相关的副作用同样的原则适用于useEffect。规则指出This pattern also applies touseEffectwhen combining unrelated side effects。当两个副作用互不相关、却共享一个依赖数组时任何一个依赖变化都会把两个副作用全部重放。错误写法——页面埋点和标题更新挤在同一个 Effect 里// 错误pathname 或 pageTitle 任一变化两个副作用都会执行 useEffect(() { analytics.trackPageView(pathname) document.title ${pageTitle} | My App }, [pathname, pageTitle])比如用户只改了页面标题pageTitle变化而路径没变这里却会重复上报一次trackPageView造成重复埋点数据污染反过来路径变了而标题没变也会无谓地重设一遍document.title此时模板字符串里拼接的还是旧标题——如果依赖遗漏还会引发 stale closure 问题。正确写法——每个副作用独立成 Effect依赖精确到各自所需的值// 正确两个副作用互不干扰各自按需触发 useEffect(() { analytics.trackPageView(pathname) }, [pathname]) useEffect(() { document.title ${pageTitle} | My App }, [pageTitle])拆分的意义不仅是性能副作用side effect天然应该对应单一职责。埋点关注的是“路由变化”标题更新关注的是“标题变化”两者生命周期不同、触发时机不同硬绑在一起还会让后续维护者难以判断“这个 Effect 到底在做什么”。拆开后每个 Effect 的意图一目了然也更容易在卸载时正确清理比如埋点可能需要移除监听、标题更新可能需要还原默认值。这条规则与同分类下的rerender-dependenciesNarrow Effect Dependencies见 rules/rerender-dependencies.md形成互补横向拆分本文把多个副作用拆成多个 Effect各管各的依赖纵向窄化rerender-dependencies单个 Effect 的依赖从对象收窄到原始值例如useEffect(..., [user])改为useEffect(..., [user.id])避免user上任何字段变化都触发 Effect 重跑。两者结合使用能把 Effect 的触发频率压到最低。何时不拆React Compiler 与拆分的边界规则末尾给出了重要的边界说明Note:If your project has React Compiler enabled, it automatically optimizes dependency tracking and may handle some of these cases for you.如果项目开启了 React Compiler它会自动进行依赖跟踪优化上述手工拆分useMemo的部分场景会被编译器自动处理React Compiler 能够自动记忆化组件与 Hook 的返回值并在必要时自动拆分不必要的重计算。同分类的 rules/rerender-memo.md 也有相同提示编译器开启后手工memo()/useMemo()往往不再必要。但这不代表拆分规则失去价值以下几点仍需人工判断React Compiler 目前主要作用于渲染期记忆化memoization对useEffect的拆分没有魔法——Effect 是命令式副作用何时执行、执行多少次仍由依赖数组决定rerender-split-combined-hooks对 Effect 的指导独立副作用独立 Effect在任何项目里都成立拆分还带来可读性与职责清晰度收益即便在编译器项目里把无关逻辑拆开也更利于代码审查与维护不要走向另一个极端——每个 Hook 都拆。同分类下的 rules/rerender-simple-expression-in-memo.md 提醒简单表达式少量逻辑/算术运算符、返回 boolean/number/string 等原始类型不要包useMemo因为调用useMemo本身以及依赖比较的开销可能比表达式本身还大。拆分的对象应当是“计算量可观、依赖可独立”的任务而不是任何一行代码。相关规则协同一套完整的重渲染优化工具箱rerender-split-combined-hooks不是孤立的一条规则它处在技能集第 5 类“重渲染优化”的规则网络中。以下是与其直接相关的配套规则供读者组合使用rules/rerender-derived-state-no-effect.md能从 props/state 推导的值如fullName firstName lastName在渲染期计算不要存 state、不要在 Effect 里 setState——这能从源头消灭一批本就不该存在的 Effectrules/rerender-dependencies.mdEffect 依赖用原始值而非对象并把派生布尔值如isMobile width 768放到 Effect 外计算让 Effect 只在布尔切换时触发rules/rerender-memo.md把昂贵计算抽取到memo()包裹的子组件借助提前 return如 loading 骨架屏跳过整段计算rules/rerender-move-effect-to-event.md交互逻辑放到事件处理器里而非 Effect——能放进事件处理器的副作用就不该占用 Effect 的依赖数组。综合起来一个完整的分层策略是优先把逻辑移出 Hook事件处理器 / 渲染期推导→ 再按依赖独立拆分剩余 Hook → 最后收窄每个 Hook 的依赖粒度。本文的规则正是中间这一层把“不得不留在 Hook 里”的计算与副作用按依赖边界切分干净。总结rerender-split-combined-hooks是一条影响级别 MEDIUM 的重渲染优化规则核心可概括为三句话合并的 Hook 是计算放大器依赖数组是粗粒度整体任一依赖变化都会触发内部全部任务重跑按依赖边界拆分useMemo拆出独立计算链如过滤 → 排序各自独立useEffect拆出互不相关的副作用如埋点与标题更新各自独立让每次重算都只做真正必要的事注意边界React Compiler 项目可自动处理部分 memo 场景简单表达式不该包useMemo派生状态和事件逻辑应优先移出 Hook。在编写或审查 React 组件时凡是看到useMemo/useEffect里“多个任务共用依赖数组”的写法都应停下来问一句这些任务真的共享同一生命周期吗把这条规则落到代码里配合依赖窄化与渲染期推导就能在不改变组件行为的前提下显著减少列表过滤、排序、埋点上报等场景中的重复计算。赞分享前端教程【免费下载链接】preguntas-entrevista-reactPreguntas típicas sobre React para entrevistas de trabajo ⚛️项目地址https://gitcode.com/gh_mirrors/pr/preguntas-entrevista-react点击查看免费下载相关推荐OpenMetadata UI 性能实践拆分组合 Hook 计算Split Combined Hook Computations优化指南OpenMetadata UI 性能实践拆分组合 Hook 计算Split Combined Hook Computations优化指南 导读 本文讲解数据目录数据血缘数据治理后端MCP 服务Comp AI CRM 的 React 渲染优化拆分组合 Hook 计算告别多余重算Comp AI CRM 的 React 渲染优化拆分组合 Hook 计算告别多余重算 导读 本文基于 Comp AI CRM 仓库中 .agents/ski后端前端CRM人工智能AI AgentZCode React 性能优化拆分组合式 Hook 计算rerender-split-combined-hooks让 useMemo 与 useEffect 按独立依赖精确重算ZCode React 性能优化拆分组合式 Hook 计算rerender split combined hooks让 useMemo 与 useEff上一篇Pipy安全配置指南10个实战技巧保护你的边缘设备与云服务下一篇苹果平方字体 PingFangSC 完整打包6 种字重 TTF/WOFF2 双格式一份资源解决跨平台中文显示创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考