Polar 项目响应式重渲染优化订阅派生状态Derived State而非连续值【免费下载链接】polarPolar — A billing platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/po/polar本篇技术指南以 Vercel React Best Practices 技能库中的rerender-derived-state规则rules/rerender-derived-state.md为核心讲解 React/Next.js 中订阅派生布尔状态而非连续值的优化手法并结合 Polar 仓库中 useIsMobileViewport 的真实实现与 Checkout 页面的实战调用说明如何在响应式场景下将重渲染频率降到最低。读完本文你将掌握matchMediauseSyncExternalStore的派生状态订阅模式以及判断该订阅什么的通用准则。规则速览这条规则讲的是什么在 Vercel React Best Practices 技能体系中SKILL.mdrerender-derived-state属于Re-render Optimization重渲染优化类别优先级为 MEDIUM影响描述是 reduces re-render frequency即降低重渲染频率。其完整表述为Subscribe to derived boolean state instead of continuous values to reduce re-render frequency.中文含义与其订阅会连续变化的原始数值如视口宽度width不如订阅由它推导出来的布尔状态如isMobile因为布尔值只有在跨越断点时才变化从而大幅减少组件的重渲染次数。该技能库共收录 45 条规则、按 8 个类别组织本规则是重渲染优化类别中与状态订阅直接相关的一条与之配套的还有rerender-defer-reads仅回调中使用的状态不要订阅、rerender-dependencieseffect 依赖收窄为原始值等。问题形态连续值订阅引发的每像素重渲染在桌面端与移动端需要不同布局的场景中最常见的错误写法是把视口宽度当作状态订阅再在组件内部手工推导布尔值function Sidebar() { const width useWindowWidth() // updates continuously const isMobile width 768 return nav className{isMobile ? mobile : desktop} }这里的隐患是useWindowWidth()通常会监听window.resize事件并把像素宽度写入 state。浏览器在拖拽窗口的过程中每变化 1 个像素都会触发一次 setState、一次组件重渲染——即使此时isMobile的值根本没有改变例如宽度从 1000 变到 999isMobile仍为false。这种为无用变化反复渲染的开销在低端设备上尤其明显因为布局重算、className 切换、子组件重渲染都会随之发生。原规则对此的定性非常明确这类订阅产生的重渲染是连续、高频且大多无意义的用户关心的其实只是是否跨越了某个断点这一个事实。正确形态订阅布尔派生状态规则的推荐写法是直接订阅媒体查询匹配结果让布尔值的变化天然只在断点跨越时发生function Sidebar() { const isMobile useMediaQuery((max-width: 767px)) return nav className{isMobile ? mobile : desktop} }对比两种写法维度useWindowWidth()useMediaQuery((max-width: 767px))状态粒度连续像素值如 1200、1199、1198…布尔值true / false触发时机每次 resize 事件仅当查询结果翻转跨越 767px时每次重渲染价值大部分无意义每次都有意义底层机制resize 监听 宽度计算matchMedia change 事件关键点在于(max-width: 767px)与(min-width: 768px)是互补的两个查询前者的true等价于后者的false边界上不会出现 767.5px 这类中间态——CSS 媒体查询天然处理了像素级细分把连续变化折叠成了离散的布尔翻转。源码纵深Polar 的 useIsMobileViewport 是如何实现的规则给出了抽象原则Polar 仓库则提供了一个可直接对照的工业级实现——useIsMobileViewport.ts它完全遵循订阅布尔派生状态的思路并且使用了 React 18 推荐的useSyncExternalStoreimport { useSyncExternalStore } from react const MD_BREAKPOINT_MEDIA_QUERY (min-width: 768px) const subscribe (onChange: () void) { const mediaQueryList window.matchMedia(MD_BREAKPOINT_MEDIA_QUERY) mediaQueryList.addEventListener(change, onChange) return () mediaQueryList.removeEventListener(change, onChange) } const getSnapshot () !window.matchMedia(MD_BREAKPOINT_MEDIA_QUERY).matches const getServerSnapshot () false export const useIsMobileViewport (): boolean useSyncExternalStore(subscribe, getSnapshot, getServerSnapshot)逐段拆解这个实现正好对应规则要求的三个层次断点常量MD_BREAKPOINT_MEDIA_QUERY (min-width: 768px)与规则示例中的767px是互补写法——min-width: 768px匹配为真即桌面端取反!...matches即为移动端。从源码结构看Polar 选择的是 Tailwind 风格的md断点768px。subscribe订阅通过mediaQueryList.addEventListener(change, onChange)订阅查询结果的翻转并返回清理函数移除监听。这正是只在布尔值翻转时通知的机制来源浏览器只在查询结果从匹配变为不匹配或反之时触发change事件而不会在窗口从 900px 拖到 800px 的过程中连续触发。getSnapshot / getServerSnapshot快照getSnapshot返回布尔派生值getServerSnapshot固定返回false保证服务端渲染SSR与首屏 hydration 期间拿到稳定值、避免 hydration mismatch。这也从侧面说明把宽度等连续值直接放进快照、而不做布尔折叠会破坏useSyncExternalStore依赖快照引用稳定的优化前提——连续值每次都会产生新快照导致组件反复重渲染与规则要避免的问题完全一致。实战调用Checkout 页面如何使用派生布尔状态useIsMobileViewport在仓库中已被实际接入结算流程。Checkout.tsx 中它的使用方式非常典型const isMobileViewport useIsMobileViewport() const collapsibleOrderSummary hasProductCheckout(checkout) isOrderSummaryCollapsible(checkout) const { isTreatment: collapsedOrderSummaryExperiment } useExperiment( checkout_collapsed_order_summary, { trackExposure: !embed isMobileViewport collapsibleOrderSummary }, )从这段代码可以读出两个信息派生布尔值被二次组合isMobileViewport与collapsibleOrderSummary一起推导出实验的曝光条件。由于isMobileViewport只在跨越 768px 断点时翻转这个组合条件不会在拖拽窗口时被反复重算useExperiment的trackExposure判断也保持稳定。订阅成本与收益的平衡useIsMobileViewport是组件级订阅每个调用它的组件都会在断点翻转时重渲染一次。因此合理的用法是在靠近布局决策点的位置订阅如 Checkout 外层组件而不是让每个子组件都去订阅一遍——这与技能库中订阅到使用点rerender-defer-reads的思路互为补充。从规则到工具箱自己封装 useMediaQuery 的要点若需要在 Polar 之外的组件中复现该模式可参照上述实现封装一个通用的useMediaQuery要点如下import { useSyncExternalStore } from react function useMediaQuery(query: string, serverValue false): boolean { const subscribe (onChange: () void) { const mql window.matchMedia(query) mql.addEventListener(change, onChange) return () mql.removeEventListener(change, onChange) } const getSnapshot () window.matchMedia(query).matches const getServerSnapshot () serverValue return useSyncExternalStore(subscribe, getSnapshot, getServerSnapshot) }使用与设计时的注意事项断点一致性查询字符串应集中管理如常量或配置文件并保证与 CSS/Tailwind 断点完全一致避免出现 CSS 用 768px、JS 用 767px 这类差一像素的边界 bug。Polar 将MD_BREAKPOINT_MEDIA_QUERY定义为模块级常量正是为此。SSR 快照必须稳定getServerSnapshot返回值在整个服务端渲染与 hydration 期间必须保持不变否则会触发 hydration 警告。移动端优先的产品可在服务端默认true桌面端优先默认false。不要嵌套订阅连续值若项目中已存在useWindowWidth类 hook不应在组件内width 768再推导——这正是规则开头指出的反模式应直接替换为useMediaQuery或 Polar 的useIsMobileViewport。适用范围与配套规则订阅派生布尔状态适用于所有由连续值决定离散 UI 形态的场景响应式布局侧边栏、抽屉、表格列折叠、prefers-color-scheme主题切换、prefers-reduced-motion动效降级、(hover: none)触屏判断等。凡是值本身不重要、只关心它是否跨越阈值的订阅都应折叠成布尔后再订阅。在重渲染优化类别中这条规则与其他几条形成组合拳详见 AGENTS.md 第 5 节rerender-dependencieseffect 的依赖也应使用派生布尔而非原始连续值例如width 768应该计算为isMobile后再进入依赖数组避免宽度在 767→768→769 之间震荡时 effect 被反复触发rerender-defer-reads如果某个状态只在事件回调里读取连订阅都不需要rerender-transitions对于滚动位置这类必须连续跟踪的数值用startTransition包裹 setState让更新不阻塞 UI。小结rerender-derived-state规则传达的核心理念可以用一句话概括让状态订阅的粒度匹配实际需求——UI 关心的往往是是否越过了断点这个离散事实而不是每一像素的宽度。Polar 仓库的 useIsMobileViewport 用useSyncExternalStorematchMedia给出了生产级示范并在 Checkout.tsx 中完成了从订阅布尔派生状态到组合推导业务条件的完整落地。对照这一模式重构现有代码即可在不改变任何视觉结果的前提下把响应式场景下的重渲染频率从每次 resize降为每次断点翻转。【免费下载链接】polarPolar — A billing platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/po/polar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Polar 项目响应式重渲染优化：订阅派生状态（Derived State）而非连续值
Polar 项目响应式重渲染优化订阅派生状态Derived State而非连续值【免费下载链接】polarPolar — A billing platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/po/polar本篇技术指南以 Vercel React Best Practices 技能库中的rerender-derived-state规则rules/rerender-derived-state.md为核心讲解 React/Next.js 中订阅派生布尔状态而非连续值的优化手法并结合 Polar 仓库中 useIsMobileViewport 的真实实现与 Checkout 页面的实战调用说明如何在响应式场景下将重渲染频率降到最低。读完本文你将掌握matchMediauseSyncExternalStore的派生状态订阅模式以及判断该订阅什么的通用准则。规则速览这条规则讲的是什么在 Vercel React Best Practices 技能体系中SKILL.mdrerender-derived-state属于Re-render Optimization重渲染优化类别优先级为 MEDIUM影响描述是 reduces re-render frequency即降低重渲染频率。其完整表述为Subscribe to derived boolean state instead of continuous values to reduce re-render frequency.中文含义与其订阅会连续变化的原始数值如视口宽度width不如订阅由它推导出来的布尔状态如isMobile因为布尔值只有在跨越断点时才变化从而大幅减少组件的重渲染次数。该技能库共收录 45 条规则、按 8 个类别组织本规则是重渲染优化类别中与状态订阅直接相关的一条与之配套的还有rerender-defer-reads仅回调中使用的状态不要订阅、rerender-dependencieseffect 依赖收窄为原始值等。问题形态连续值订阅引发的每像素重渲染在桌面端与移动端需要不同布局的场景中最常见的错误写法是把视口宽度当作状态订阅再在组件内部手工推导布尔值function Sidebar() { const width useWindowWidth() // updates continuously const isMobile width 768 return nav className{isMobile ? mobile : desktop} }这里的隐患是useWindowWidth()通常会监听window.resize事件并把像素宽度写入 state。浏览器在拖拽窗口的过程中每变化 1 个像素都会触发一次 setState、一次组件重渲染——即使此时isMobile的值根本没有改变例如宽度从 1000 变到 999isMobile仍为false。这种为无用变化反复渲染的开销在低端设备上尤其明显因为布局重算、className 切换、子组件重渲染都会随之发生。原规则对此的定性非常明确这类订阅产生的重渲染是连续、高频且大多无意义的用户关心的其实只是是否跨越了某个断点这一个事实。正确形态订阅布尔派生状态规则的推荐写法是直接订阅媒体查询匹配结果让布尔值的变化天然只在断点跨越时发生function Sidebar() { const isMobile useMediaQuery((max-width: 767px)) return nav className{isMobile ? mobile : desktop} }对比两种写法维度useWindowWidth()useMediaQuery((max-width: 767px))状态粒度连续像素值如 1200、1199、1198…布尔值true / false触发时机每次 resize 事件仅当查询结果翻转跨越 767px时每次重渲染价值大部分无意义每次都有意义底层机制resize 监听 宽度计算matchMedia change 事件关键点在于(max-width: 767px)与(min-width: 768px)是互补的两个查询前者的true等价于后者的false边界上不会出现 767.5px 这类中间态——CSS 媒体查询天然处理了像素级细分把连续变化折叠成了离散的布尔翻转。源码纵深Polar 的 useIsMobileViewport 是如何实现的规则给出了抽象原则Polar 仓库则提供了一个可直接对照的工业级实现——useIsMobileViewport.ts它完全遵循订阅布尔派生状态的思路并且使用了 React 18 推荐的useSyncExternalStoreimport { useSyncExternalStore } from react const MD_BREAKPOINT_MEDIA_QUERY (min-width: 768px) const subscribe (onChange: () void) { const mediaQueryList window.matchMedia(MD_BREAKPOINT_MEDIA_QUERY) mediaQueryList.addEventListener(change, onChange) return () mediaQueryList.removeEventListener(change, onChange) } const getSnapshot () !window.matchMedia(MD_BREAKPOINT_MEDIA_QUERY).matches const getServerSnapshot () false export const useIsMobileViewport (): boolean useSyncExternalStore(subscribe, getSnapshot, getServerSnapshot)逐段拆解这个实现正好对应规则要求的三个层次断点常量MD_BREAKPOINT_MEDIA_QUERY (min-width: 768px)与规则示例中的767px是互补写法——min-width: 768px匹配为真即桌面端取反!...matches即为移动端。从源码结构看Polar 选择的是 Tailwind 风格的md断点768px。subscribe订阅通过mediaQueryList.addEventListener(change, onChange)订阅查询结果的翻转并返回清理函数移除监听。这正是只在布尔值翻转时通知的机制来源浏览器只在查询结果从匹配变为不匹配或反之时触发change事件而不会在窗口从 900px 拖到 800px 的过程中连续触发。getSnapshot / getServerSnapshot快照getSnapshot返回布尔派生值getServerSnapshot固定返回false保证服务端渲染SSR与首屏 hydration 期间拿到稳定值、避免 hydration mismatch。这也从侧面说明把宽度等连续值直接放进快照、而不做布尔折叠会破坏useSyncExternalStore依赖快照引用稳定的优化前提——连续值每次都会产生新快照导致组件反复重渲染与规则要避免的问题完全一致。实战调用Checkout 页面如何使用派生布尔状态useIsMobileViewport在仓库中已被实际接入结算流程。Checkout.tsx 中它的使用方式非常典型const isMobileViewport useIsMobileViewport() const collapsibleOrderSummary hasProductCheckout(checkout) isOrderSummaryCollapsible(checkout) const { isTreatment: collapsedOrderSummaryExperiment } useExperiment( checkout_collapsed_order_summary, { trackExposure: !embed isMobileViewport collapsibleOrderSummary }, )从这段代码可以读出两个信息派生布尔值被二次组合isMobileViewport与collapsibleOrderSummary一起推导出实验的曝光条件。由于isMobileViewport只在跨越 768px 断点时翻转这个组合条件不会在拖拽窗口时被反复重算useExperiment的trackExposure判断也保持稳定。订阅成本与收益的平衡useIsMobileViewport是组件级订阅每个调用它的组件都会在断点翻转时重渲染一次。因此合理的用法是在靠近布局决策点的位置订阅如 Checkout 外层组件而不是让每个子组件都去订阅一遍——这与技能库中订阅到使用点rerender-defer-reads的思路互为补充。从规则到工具箱自己封装 useMediaQuery 的要点若需要在 Polar 之外的组件中复现该模式可参照上述实现封装一个通用的useMediaQuery要点如下import { useSyncExternalStore } from react function useMediaQuery(query: string, serverValue false): boolean { const subscribe (onChange: () void) { const mql window.matchMedia(query) mql.addEventListener(change, onChange) return () mql.removeEventListener(change, onChange) } const getSnapshot () window.matchMedia(query).matches const getServerSnapshot () serverValue return useSyncExternalStore(subscribe, getSnapshot, getServerSnapshot) }使用与设计时的注意事项断点一致性查询字符串应集中管理如常量或配置文件并保证与 CSS/Tailwind 断点完全一致避免出现 CSS 用 768px、JS 用 767px 这类差一像素的边界 bug。Polar 将MD_BREAKPOINT_MEDIA_QUERY定义为模块级常量正是为此。SSR 快照必须稳定getServerSnapshot返回值在整个服务端渲染与 hydration 期间必须保持不变否则会触发 hydration 警告。移动端优先的产品可在服务端默认true桌面端优先默认false。不要嵌套订阅连续值若项目中已存在useWindowWidth类 hook不应在组件内width 768再推导——这正是规则开头指出的反模式应直接替换为useMediaQuery或 Polar 的useIsMobileViewport。适用范围与配套规则订阅派生布尔状态适用于所有由连续值决定离散 UI 形态的场景响应式布局侧边栏、抽屉、表格列折叠、prefers-color-scheme主题切换、prefers-reduced-motion动效降级、(hover: none)触屏判断等。凡是值本身不重要、只关心它是否跨越阈值的订阅都应折叠成布尔后再订阅。在重渲染优化类别中这条规则与其他几条形成组合拳详见 AGENTS.md 第 5 节rerender-dependencieseffect 的依赖也应使用派生布尔而非原始连续值例如width 768应该计算为isMobile后再进入依赖数组避免宽度在 767→768→769 之间震荡时 effect 被反复触发rerender-defer-reads如果某个状态只在事件回调里读取连订阅都不需要rerender-transitions对于滚动位置这类必须连续跟踪的数值用startTransition包裹 setState让更新不阻塞 UI。小结rerender-derived-state规则传达的核心理念可以用一句话概括让状态订阅的粒度匹配实际需求——UI 关心的往往是是否越过了断点这个离散事实而不是每一像素的宽度。Polar 仓库的 useIsMobileViewport 用useSyncExternalStorematchMedia给出了生产级示范并在 Checkout.tsx 中完成了从订阅布尔派生状态到组合推导业务条件的完整落地。对照这一模式重构现有代码即可在不改变任何视觉结果的前提下把响应式场景下的重渲染频率从每次 resize降为每次断点翻转。【免费下载链接】polarPolar — A billing platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/po/polar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
