Polar 前端优化实践如何通过收窄 useEffect 依赖避免多余重渲染【免费下载链接】polarPolar — A billing platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/po/polar导读本篇文章围绕 Polar 前端工程中沉淀的一条 React 性能规则展开Narrow Effect Dependencies收窄 Effect 依赖。这条规则来自clients/apps/web/.agents/skills/vercel-react-best-practices技能库中的rerenderRe-render Optimization重渲染优化分类其核心思想是用原始类型primitive依赖替代对象依赖让useEffect只在真正关心的值变化时才重新执行。读完本文你将掌握三类实战手法对象依赖收窄为属性依赖、把派生布尔值提取到渲染期计算以消除中间态抖动、以及把交互副作用从 Effect 中移回事件处理器并结合 Polar 仓库中的真实组件代码如 BenefitListSidebar.tsx看到这些模式在真实业务中的应用。1. 规则定位它是 Vercel React 最佳实践的一部分这条规则并非孤立存在它属于 Polar 前端仓库中内置的一套 Agent 技能库。技能库的 README.md 说明其来源于 Vercel Engineering专门用于在编写、审查或重构 React/Next.js 代码时给出性能模式指导。整套指南共 64 条规则、8 大分类按预期收益排序优先级分类影响级别文件名前缀1Eliminating Waterfalls消除请求瀑布CRITICALasync-2Bundle Size Optimization包体积优化CRITICALbundle-3Server-Side Performance服务端性能HIGHserver-4Client-Side Data Fetching客户端数据请求MEDIUM-HIGHclient-5Re-render Optimization重渲染优化MEDIUMrerender-6Rendering Performance渲染性能MEDIUMrendering-7JavaScript PerformanceJS 微优化LOW-MEDIUMjs-8Advanced Patterns进阶模式LOWadvanced-分类信息定义在 _sections.md 中。其中第 5 类Re-render Optimization的目标是减少不必要的重渲染从而最小化浪费的计算并提升 UI 响应性。rerender-dependencies.md正是这一类下的核心规则之一其 frontmatter 元数据为titleNarrow Effect DependenciesimpactLOWimpactDescriptionminimizes effect re-runs最小化 Effect 的重复执行关于 impact 级别README.md 给出了从CRITICAL到LOW的完整分级LOW表示增量改进——这类优化单独看收益不大但和rerender-系列其他规则如rerender-memo、rerender-derived-state-no-effect、rerender-move-effect-to-event组合使用时能系统性消除组件树中的无效副作用。2. 核心反模式把整个对象放进依赖数组React 的useEffect依赖比较使用的是Object.is级别的引用比较。只要依赖数组中的任何一个值在两次渲染之间发生了引用变化Effect 就会重新执行。对象类型对象、数组、函数、Map 等每次渲染都会产生新引用即使内容完全相同。因此规则首先指出的反模式是把整个对象当作依赖会让 Effect 在对象任意字段变化时都重新运行// 错误示范user 对象任何字段name、email、avatar...变化都会触发 useEffect(() { console.log(user.id) }, [user])user是对象只要上层组件以任何方式更新了user哪怕是改了一个与本次 Effect 无关的字段就会产生一个新引用Effect 就会无意义地重跑一次。如果这个 Effect 内部还发起了网络请求或写入了存储这就是实打实的重复副作用。正确的做法是只依赖 Effect 真正读取的值——一个原始类型// 正确示范仅在 user.id 变化时触发 useEffect(() { console.log(user.id) }, [user.id])user.id是字符串/数字这样的原始类型只有它的值真正变化时依赖比较才会判定为不相等Effect 才会重新执行。这条规则的精髓可以总结为一句话Effect 里读什么依赖数组里就放什么的原始形态。配套建议rerender-分类中的另一条规则 rerender-split-combined-hooks.md拆分依赖相互独立的 Hook与本规则高度互补——当一个 Effect 同时依赖多个不同生命周期、变化频率差异很大的值可以按关注点拆成多个 Effect每个 Effect 只订阅它真正需要的最小依赖集合。3. 派生状态布尔转换要在渲染期完成而不是塞进依赖数组规则的第二个场景针对派生状态derived state。很多开发者习惯把由多个输入计算出的中间结果作为 Effect 的输入但这类中间值往往高频抖动会把 Effect 拖进一个不断触发-再计算-再触发的循环。规则的原始示例非常典型——响应式布局判断// 错误示范宽度 767、766、765... 每变化 1px 都会触发 Effect useEffect(() { if (width 768) { enableMobileMode() } }, [width])width是连续的像素值。用户在拖动窗口、滚动条出现、甚至只是浏览器缩放时width会在短时间内连续产生大量中间值768、767、766...每一个值都让依赖比较判定变化了Effect 因此被高频触发即便enableMobileMode()需要执行的逻辑在 767 和 766 时完全相同。正确示范把布尔判断提升到渲染期计算让 Effect 只订阅布尔转换// 正确示范Effect 仅在 isMobile 从 false 翻转为 true 时执行一次 const isMobile width 768 useEffect(() { if (isMobile) { enableMobileMode() } }, [isMobile])isMobile是一个布尔值它只在跨越 768px 阈值的那一瞬间发生翻转。因此 Effect 只会在进入移动端模式或退出移动端模式时执行而不是在每一像素变化时都执行。这在以支付、订阅管理为业务核心的 Polar 前端中尤其重要——任何需要与后端交互、发送埋点或切换渲染模式的副作用都应该只在模式发生转换时运行一次而不是在滚动/缩放期间重复执行。仓库印证Polar 中响应式判断的落地方式Polar 前端把这种布尔化订阅进一步封装成了 Hook。useIsMobileViewport.ts 借助window.matchMedia把连续的视口宽度转换为离散的布尔状态并通过useSyncExternalStore订阅媒体查询的变更事件const mediaQueryList window.matchMedia(MD_BREAKPOINT_MEDIA_QUERY) const getSnapshot () !window.matchMedia(MD_BREAKPOINT_MEDIA_QUERY).matches消费方在组件里直接拿到布尔值const isMobile useIsMobile()该 Hook 被多个业务组件复用例如 SalesPage.tsx/dashboard/[organization]/(header)/sales/[id]/SalesPage.tsx)、OrderDownloadActions.tsx 都通过const isMobile useIsMobile()来驱动与桌面/移动端不同的渲染分支。另外 MasterDetailIndex.tsx 也采用了同款思路const isDesktop isBrowser !window.matchMedia(MOBILE_MEDIA_QUERY).matches。这些组件的实践与规则描述的订阅派生布尔值而不是订阅原始连续值完全一致——从源码结构看这正是rerender-dependencies.md和同分类的 rerender-derived-state.md订阅派生布尔而非原始值在真实代码库中的落地形态。4. 姊妹规则能派生就别存 state能进事件就别进 Effect收窄依赖只是减少 Effect 重跑的一部分。围绕同一个主题rerender-分类还有两条高频配合的规则理解它们能让你一眼识别出这个 Effect 根本不该存在的场景。4.1 派生值在渲染期计算而不是用 Effect 同步rerender-derived-state-no-effectrules/rerender-derived-state-no-effect.md 的标题就是Calculate Derived State During Rendering渲染期计算派生状态。它的反例是冗余的 state effect组合// 错误示范fullName 完全可由已有 state 推出却多存了一份 用 Effect 同步 function Form() { const [firstName, setFirstName] useState(First) const [lastName, setLastName] useState(Last) const [fullName, setFullName] useState() useEffect(() { setFullName(firstName lastName) }, [firstName, lastName]) return p{fullName}/p }这段代码的问题不止是多一次渲染Effect 在渲染后异步执行setFullName会产生一次额外的重渲染一旦某次更新被跳过或顺序错乱fullName还会与firstName/lastName出现状态漂移state drift。正确写法是在渲染期直接计算// 正确示范渲染期派生零额外渲染、零状态漂移 function Form() { const [firstName, setFirstName] useState(First) const [lastName, setLastName] useState(Last) const fullName firstName lastName return p{fullName}/p }这也正是 React 官方文档《You Might Not Need an Effect》的核心主张能用当前 props/state 算出来的值就不要存进 state更不要在 Effect 里 setState。如需在 props 变化时重置内部状态优先用 key 重置或派生值而不是写一个同步型 Effect。4.2 交互副作用放进事件处理器而不是 state Effectrerender-move-effect-to-eventrules/rerender-move-effect-to-event.md 针对的是把一次用户操作建模成 state再用 Effect 响应的反模式// 错误示范一次点击被建模成 submitted state 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 依赖了theme任何与提交无关的主题切换都会让 Effect 重跑而 StrictMode 下的 Effect 双执行或重复挂载还可能让post(/api/register)重复提交。正确做法是把副作用直接放进点击处理器// 正确示范副作用发生在事件处理器中一次点击一次执行 function Form() { const theme useContext(ThemeContext) function handleSubmit() { post(/api/register) showToast(Registered, theme) } return button onClick{handleSubmit}Submit/button }判断依据非常朴素这个副作用是由特定用户操作点击、提交、拖拽触发的吗是就放进事件处理器。只有当副作用需要与外部系统同步订阅、轮询、监听全局事件、或在渲染后必须执行时才值得使用 Effect。5. 仓库实战Polar 中符合规范的 Effect 依赖写法收窄依赖的规范在 Polar 前端代码中得到了大量实践。以 BenefitListSidebar.tsx权益列表侧边栏组件为例它的两个 Effect 都严格使用原始类型/单一职责依赖useEffect(() { if (inViewport hasNextPage !isFetchingNextPage) { fetchNextPage() } }, [inViewport, hasNextPage, isFetchingNextPage, fetchNextPage])这是一个无限滚动加载更多的典型场景依赖数组里全部是布尔值inViewport、hasNextPage、isFetchingNextPage和稳定的回调引用fetchNextPage通常来自useCallback每个依赖都是 Effect 内部真实读取的最小粒度值。inViewport来自useInViewportHook底层是 IntersectionObserver本身就是离散的布尔转换不会因滚动像素抖动而触发加载从而避免重复请求分页数据。第二个 Effect 同样遵守Effect 里读什么就依赖什么的原则useEffect(() { if (createBenefitQuerystring) { showCreateBenefitModal() setCreateBenefitQuerystring(null) } // oxlint-disable-next-line react-hooks/exhaustive-deps }, [createBenefitQuerystring])这里 Effect 通过createBenefitQuerystring一个可空字符串来驱动打开创建权益弹窗的副作用并在执行后清空该值形成一次性触发语义。需要说明的是该处用oxlint-disable-next-line react-hooks/exhaustive-deps显式声明了依赖数组与 Effect 内部引用的差异——在确实需要只响应某一信号变化的场景而不是响应其内部引用的所有对象时规则允许通过显式注释来收窄依赖。这正好呼应本规则的核心精神依赖数组表达的是我想在什么变化时重跑而不是代码里所有符号的集合。同分类其他规则的仓库落点渲染期派生selectedBenefitId通过useMemo(() {...}, [pathname])从路由pathname派生BenefitListSidebar.tsx而不是存入 state 再同步——即rerender-derived-state-no-effect的实践。稳定回调handleSelectBenefit使用useCallback包裹同文件 L106 起确保依赖它的子组件与 Effect 不会因回调引用变化而重跑。事件处理器承载副作用打开弹窗的副作用发生在点击/查询字符串事件路径上而非把打开建模为布尔 state Effect。这些模式贯穿整个clients/apps/web/src目录——对该目录的搜索显示useEffect在 Polar 前端的数百处使用中绝大多数依赖数组都遵循原始类型优先的写法。6. 自查清单写 Effect 前的三个问题把本规则及两条姊妹规则浓缩成一份可直接用于代码审查的自查清单依赖是否已收窄到原始类型Effect 里读取了user.id依赖数组就写[user.id]而不是[user]。若依赖对象中只有个别字段被读取就只依赖这些字段。派生值是否在渲染期计算能从现有 props/state 算出的值布尔、拼接串、过滤结果直接在渲染期计算或useMemo不要放进 state、更不要用 Effect 同步。连续值如视口宽度应先转成布尔如width 768再订阅。副作用是否属于用户交互由点击、提交、拖拽触发的副作用直接放进事件处理器。只有当副作用必须与外部系统持续同步时才使用 Effect并且仍然要遵守第 1 条的最小依赖原则。在评审中还可以对照技能库 SKILL.md 中列出的同分类规则进行系统性排查rerender-memo把昂贵工作提取为 memo 化组件、rerender-lazy-state-init昂贵初始值用函数式useState、rerender-functional-setstate用函数式 setState 保证回调稳定、rerender-use-ref-transient-values高频瞬时值用 ref 而非 state等。7. 小结rerender-dependencies.md这条规则的技术要点可以归结为三条依赖收窄用[user.id]替代[user]用Object.is引用比较的机制避免对象任一字段变化都重跑 Effect。布尔化订阅把width 768这类连续值派生为isMobile布尔Effect 只响应布尔翻转不响应像素抖动。职责归位能派生就不存 statererender-derived-state-no-effect能进事件就不进 Effectrerender-move-effect-to-event。在 Polar 的 React 前端clients/apps/web中useIsMobileViewport、BenefitListSidebar等组件已经把这些模式落到了真实业务里响应式判断全部布尔化、分页加载依赖最小化、派生 ID 用渲染期计算、副作用按事件归位。虽然单条规则的 impact 评级为 LOW增量改进但把它与rerender-分类中的 memo、lazy init、functional setState、ref 瞬时值等规则组合运用就能系统性压低整个组件树的无用重渲染与重复副作用——这正是 Vercel React Best Practices 技能库所倡导的按 impact 优先级持续优化的工程方法。【免费下载链接】polarPolar — A billing platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/po/polar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Polar 前端优化实践：如何通过收窄 useEffect 依赖避免多余重渲染
Polar 前端优化实践如何通过收窄 useEffect 依赖避免多余重渲染【免费下载链接】polarPolar — A billing platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/po/polar导读本篇文章围绕 Polar 前端工程中沉淀的一条 React 性能规则展开Narrow Effect Dependencies收窄 Effect 依赖。这条规则来自clients/apps/web/.agents/skills/vercel-react-best-practices技能库中的rerenderRe-render Optimization重渲染优化分类其核心思想是用原始类型primitive依赖替代对象依赖让useEffect只在真正关心的值变化时才重新执行。读完本文你将掌握三类实战手法对象依赖收窄为属性依赖、把派生布尔值提取到渲染期计算以消除中间态抖动、以及把交互副作用从 Effect 中移回事件处理器并结合 Polar 仓库中的真实组件代码如 BenefitListSidebar.tsx看到这些模式在真实业务中的应用。1. 规则定位它是 Vercel React 最佳实践的一部分这条规则并非孤立存在它属于 Polar 前端仓库中内置的一套 Agent 技能库。技能库的 README.md 说明其来源于 Vercel Engineering专门用于在编写、审查或重构 React/Next.js 代码时给出性能模式指导。整套指南共 64 条规则、8 大分类按预期收益排序优先级分类影响级别文件名前缀1Eliminating Waterfalls消除请求瀑布CRITICALasync-2Bundle Size Optimization包体积优化CRITICALbundle-3Server-Side Performance服务端性能HIGHserver-4Client-Side Data Fetching客户端数据请求MEDIUM-HIGHclient-5Re-render Optimization重渲染优化MEDIUMrerender-6Rendering Performance渲染性能MEDIUMrendering-7JavaScript PerformanceJS 微优化LOW-MEDIUMjs-8Advanced Patterns进阶模式LOWadvanced-分类信息定义在 _sections.md 中。其中第 5 类Re-render Optimization的目标是减少不必要的重渲染从而最小化浪费的计算并提升 UI 响应性。rerender-dependencies.md正是这一类下的核心规则之一其 frontmatter 元数据为titleNarrow Effect DependenciesimpactLOWimpactDescriptionminimizes effect re-runs最小化 Effect 的重复执行关于 impact 级别README.md 给出了从CRITICAL到LOW的完整分级LOW表示增量改进——这类优化单独看收益不大但和rerender-系列其他规则如rerender-memo、rerender-derived-state-no-effect、rerender-move-effect-to-event组合使用时能系统性消除组件树中的无效副作用。2. 核心反模式把整个对象放进依赖数组React 的useEffect依赖比较使用的是Object.is级别的引用比较。只要依赖数组中的任何一个值在两次渲染之间发生了引用变化Effect 就会重新执行。对象类型对象、数组、函数、Map 等每次渲染都会产生新引用即使内容完全相同。因此规则首先指出的反模式是把整个对象当作依赖会让 Effect 在对象任意字段变化时都重新运行// 错误示范user 对象任何字段name、email、avatar...变化都会触发 useEffect(() { console.log(user.id) }, [user])user是对象只要上层组件以任何方式更新了user哪怕是改了一个与本次 Effect 无关的字段就会产生一个新引用Effect 就会无意义地重跑一次。如果这个 Effect 内部还发起了网络请求或写入了存储这就是实打实的重复副作用。正确的做法是只依赖 Effect 真正读取的值——一个原始类型// 正确示范仅在 user.id 变化时触发 useEffect(() { console.log(user.id) }, [user.id])user.id是字符串/数字这样的原始类型只有它的值真正变化时依赖比较才会判定为不相等Effect 才会重新执行。这条规则的精髓可以总结为一句话Effect 里读什么依赖数组里就放什么的原始形态。配套建议rerender-分类中的另一条规则 rerender-split-combined-hooks.md拆分依赖相互独立的 Hook与本规则高度互补——当一个 Effect 同时依赖多个不同生命周期、变化频率差异很大的值可以按关注点拆成多个 Effect每个 Effect 只订阅它真正需要的最小依赖集合。3. 派生状态布尔转换要在渲染期完成而不是塞进依赖数组规则的第二个场景针对派生状态derived state。很多开发者习惯把由多个输入计算出的中间结果作为 Effect 的输入但这类中间值往往高频抖动会把 Effect 拖进一个不断触发-再计算-再触发的循环。规则的原始示例非常典型——响应式布局判断// 错误示范宽度 767、766、765... 每变化 1px 都会触发 Effect useEffect(() { if (width 768) { enableMobileMode() } }, [width])width是连续的像素值。用户在拖动窗口、滚动条出现、甚至只是浏览器缩放时width会在短时间内连续产生大量中间值768、767、766...每一个值都让依赖比较判定变化了Effect 因此被高频触发即便enableMobileMode()需要执行的逻辑在 767 和 766 时完全相同。正确示范把布尔判断提升到渲染期计算让 Effect 只订阅布尔转换// 正确示范Effect 仅在 isMobile 从 false 翻转为 true 时执行一次 const isMobile width 768 useEffect(() { if (isMobile) { enableMobileMode() } }, [isMobile])isMobile是一个布尔值它只在跨越 768px 阈值的那一瞬间发生翻转。因此 Effect 只会在进入移动端模式或退出移动端模式时执行而不是在每一像素变化时都执行。这在以支付、订阅管理为业务核心的 Polar 前端中尤其重要——任何需要与后端交互、发送埋点或切换渲染模式的副作用都应该只在模式发生转换时运行一次而不是在滚动/缩放期间重复执行。仓库印证Polar 中响应式判断的落地方式Polar 前端把这种布尔化订阅进一步封装成了 Hook。useIsMobileViewport.ts 借助window.matchMedia把连续的视口宽度转换为离散的布尔状态并通过useSyncExternalStore订阅媒体查询的变更事件const mediaQueryList window.matchMedia(MD_BREAKPOINT_MEDIA_QUERY) const getSnapshot () !window.matchMedia(MD_BREAKPOINT_MEDIA_QUERY).matches消费方在组件里直接拿到布尔值const isMobile useIsMobile()该 Hook 被多个业务组件复用例如 SalesPage.tsx/dashboard/[organization]/(header)/sales/[id]/SalesPage.tsx)、OrderDownloadActions.tsx 都通过const isMobile useIsMobile()来驱动与桌面/移动端不同的渲染分支。另外 MasterDetailIndex.tsx 也采用了同款思路const isDesktop isBrowser !window.matchMedia(MOBILE_MEDIA_QUERY).matches。这些组件的实践与规则描述的订阅派生布尔值而不是订阅原始连续值完全一致——从源码结构看这正是rerender-dependencies.md和同分类的 rerender-derived-state.md订阅派生布尔而非原始值在真实代码库中的落地形态。4. 姊妹规则能派生就别存 state能进事件就别进 Effect收窄依赖只是减少 Effect 重跑的一部分。围绕同一个主题rerender-分类还有两条高频配合的规则理解它们能让你一眼识别出这个 Effect 根本不该存在的场景。4.1 派生值在渲染期计算而不是用 Effect 同步rerender-derived-state-no-effectrules/rerender-derived-state-no-effect.md 的标题就是Calculate Derived State During Rendering渲染期计算派生状态。它的反例是冗余的 state effect组合// 错误示范fullName 完全可由已有 state 推出却多存了一份 用 Effect 同步 function Form() { const [firstName, setFirstName] useState(First) const [lastName, setLastName] useState(Last) const [fullName, setFullName] useState() useEffect(() { setFullName(firstName lastName) }, [firstName, lastName]) return p{fullName}/p }这段代码的问题不止是多一次渲染Effect 在渲染后异步执行setFullName会产生一次额外的重渲染一旦某次更新被跳过或顺序错乱fullName还会与firstName/lastName出现状态漂移state drift。正确写法是在渲染期直接计算// 正确示范渲染期派生零额外渲染、零状态漂移 function Form() { const [firstName, setFirstName] useState(First) const [lastName, setLastName] useState(Last) const fullName firstName lastName return p{fullName}/p }这也正是 React 官方文档《You Might Not Need an Effect》的核心主张能用当前 props/state 算出来的值就不要存进 state更不要在 Effect 里 setState。如需在 props 变化时重置内部状态优先用 key 重置或派生值而不是写一个同步型 Effect。4.2 交互副作用放进事件处理器而不是 state Effectrerender-move-effect-to-eventrules/rerender-move-effect-to-event.md 针对的是把一次用户操作建模成 state再用 Effect 响应的反模式// 错误示范一次点击被建模成 submitted state 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 依赖了theme任何与提交无关的主题切换都会让 Effect 重跑而 StrictMode 下的 Effect 双执行或重复挂载还可能让post(/api/register)重复提交。正确做法是把副作用直接放进点击处理器// 正确示范副作用发生在事件处理器中一次点击一次执行 function Form() { const theme useContext(ThemeContext) function handleSubmit() { post(/api/register) showToast(Registered, theme) } return button onClick{handleSubmit}Submit/button }判断依据非常朴素这个副作用是由特定用户操作点击、提交、拖拽触发的吗是就放进事件处理器。只有当副作用需要与外部系统同步订阅、轮询、监听全局事件、或在渲染后必须执行时才值得使用 Effect。5. 仓库实战Polar 中符合规范的 Effect 依赖写法收窄依赖的规范在 Polar 前端代码中得到了大量实践。以 BenefitListSidebar.tsx权益列表侧边栏组件为例它的两个 Effect 都严格使用原始类型/单一职责依赖useEffect(() { if (inViewport hasNextPage !isFetchingNextPage) { fetchNextPage() } }, [inViewport, hasNextPage, isFetchingNextPage, fetchNextPage])这是一个无限滚动加载更多的典型场景依赖数组里全部是布尔值inViewport、hasNextPage、isFetchingNextPage和稳定的回调引用fetchNextPage通常来自useCallback每个依赖都是 Effect 内部真实读取的最小粒度值。inViewport来自useInViewportHook底层是 IntersectionObserver本身就是离散的布尔转换不会因滚动像素抖动而触发加载从而避免重复请求分页数据。第二个 Effect 同样遵守Effect 里读什么就依赖什么的原则useEffect(() { if (createBenefitQuerystring) { showCreateBenefitModal() setCreateBenefitQuerystring(null) } // oxlint-disable-next-line react-hooks/exhaustive-deps }, [createBenefitQuerystring])这里 Effect 通过createBenefitQuerystring一个可空字符串来驱动打开创建权益弹窗的副作用并在执行后清空该值形成一次性触发语义。需要说明的是该处用oxlint-disable-next-line react-hooks/exhaustive-deps显式声明了依赖数组与 Effect 内部引用的差异——在确实需要只响应某一信号变化的场景而不是响应其内部引用的所有对象时规则允许通过显式注释来收窄依赖。这正好呼应本规则的核心精神依赖数组表达的是我想在什么变化时重跑而不是代码里所有符号的集合。同分类其他规则的仓库落点渲染期派生selectedBenefitId通过useMemo(() {...}, [pathname])从路由pathname派生BenefitListSidebar.tsx而不是存入 state 再同步——即rerender-derived-state-no-effect的实践。稳定回调handleSelectBenefit使用useCallback包裹同文件 L106 起确保依赖它的子组件与 Effect 不会因回调引用变化而重跑。事件处理器承载副作用打开弹窗的副作用发生在点击/查询字符串事件路径上而非把打开建模为布尔 state Effect。这些模式贯穿整个clients/apps/web/src目录——对该目录的搜索显示useEffect在 Polar 前端的数百处使用中绝大多数依赖数组都遵循原始类型优先的写法。6. 自查清单写 Effect 前的三个问题把本规则及两条姊妹规则浓缩成一份可直接用于代码审查的自查清单依赖是否已收窄到原始类型Effect 里读取了user.id依赖数组就写[user.id]而不是[user]。若依赖对象中只有个别字段被读取就只依赖这些字段。派生值是否在渲染期计算能从现有 props/state 算出的值布尔、拼接串、过滤结果直接在渲染期计算或useMemo不要放进 state、更不要用 Effect 同步。连续值如视口宽度应先转成布尔如width 768再订阅。副作用是否属于用户交互由点击、提交、拖拽触发的副作用直接放进事件处理器。只有当副作用必须与外部系统持续同步时才使用 Effect并且仍然要遵守第 1 条的最小依赖原则。在评审中还可以对照技能库 SKILL.md 中列出的同分类规则进行系统性排查rerender-memo把昂贵工作提取为 memo 化组件、rerender-lazy-state-init昂贵初始值用函数式useState、rerender-functional-setstate用函数式 setState 保证回调稳定、rerender-use-ref-transient-values高频瞬时值用 ref 而非 state等。7. 小结rerender-dependencies.md这条规则的技术要点可以归结为三条依赖收窄用[user.id]替代[user]用Object.is引用比较的机制避免对象任一字段变化都重跑 Effect。布尔化订阅把width 768这类连续值派生为isMobile布尔Effect 只响应布尔翻转不响应像素抖动。职责归位能派生就不存 statererender-derived-state-no-effect能进事件就不进 Effectrerender-move-effect-to-event。在 Polar 的 React 前端clients/apps/web中useIsMobileViewport、BenefitListSidebar等组件已经把这些模式落到了真实业务里响应式判断全部布尔化、分页加载依赖最小化、派生 ID 用渲染期计算、副作用按事件归位。虽然单条规则的 impact 评级为 LOW增量改进但把它与rerender-分类中的 memo、lazy init、functional setState、ref 瞬时值等规则组合运用就能系统性压低整个组件树的无用重渲染与重复副作用——这正是 Vercel React Best Practices 技能库所倡导的按 impact 优先级持续优化的工程方法。【免费下载链接】polarPolar — A billing platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/po/polar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考