前端教程【免费下载链接】preguntas-entrevista-reactPreguntas típicas sobre React para entrevistas de trabajo ⚛️项目地址https://gitcode.com/gh_mirrors/pr/preguntas-entrevista-react点击查看免费下载本文聚焦 Vercel React 最佳实践中「订阅派生状态Subscribe to Derived State」这一条重渲染优化规则结合本仓库的面试题库que-es-el-estado-derivado-y-por-que-conviene-calcularlo-en-el-render.json、que-provoca-un-re-render-en-un-componente-de-react.json与 React 源码级知识讲清楚为什么「订阅连续的原始值」比「订阅派生的布尔值」性能更差以及如何在真实组件里落地useMediaQuery这类模式。读完你将掌握如何判断某个订阅值是否应该派生、如何用布尔阈值截断无意义的连续重渲染、以及派生状态与useEffect的正确分工。一、规则是什么一句话抓住核心在 .agents/skills/vercel-react-best-practices/rules/rerender-derived-state.md 中Vercel 定义了一条影响等级为MEDIUMimpact: MEDIUM、作用是降低重渲染频率reduces re-render frequency的规则订阅派生的布尔状态而不是订阅连续的原始值。这条规则挂靠在rerender-前缀的「Re-render Optimization重渲染优化」分类下。从 .agents/skills/vercel-react-best-practices/rules/_sections.md 可以看到该分类的定位影响等级MEDIUM描述减少不必要的重渲染能最小化浪费的计算并提升 UI 响应性。在整套 Vercel React 最佳实践中SKILL.md 记录了共 69 条规则、8 个分类重渲染优化处于优先级第 5 位。它不像「消除瀑布流」CRITICAL那样能带来数量级的收益但对高频交互的组件尤其是响应式布局、拖拽、滚动场景而言是性价比极高的一档优化。二、为什么订阅「连续值」会引发重渲染风暴先看本规则给出的反面示例原样保留自规则文档// ❌ 错误每次像素变化都会重渲染 function Sidebar() { const width useWindowWidth() // 持续更新 const isMobile width 768 return nav className{isMobile ? mobile : desktop} / }问题出在useWindowWidth()这个自定义 Hook 上如果它内部监听的是resize事件并把原始像素宽度直接存入useState那么用户每拖动窗口一像素React 都会安排一次新的状态更新和组件重渲染。为什么这是浪费对照本仓库的面试题 que-provoca-un-re-render-en-un-componente-de-react.json 中总结的重渲染触发条件可以看得非常清楚组件的状态发生变化useState/useReducer父组件传入的props发生变化组件消费的 context 值发生变化useContext父组件重渲染并重新创建了子元素除非子组件被 memo 化且 props 稳定。useWindowWidth()把宽度存入状态后条件 1 在每次resize事件触发时都被满足。而组件真正需要的其实只有一个布尔结果——当前是不是移动端——这个结果只有在跨越阈值768px的那一刻才会发生变化。换句话说你在为一个每秒可能变化几十次的值付费却只需要一个几乎不变的真假值。这就是典型的「订阅了错误粒度的数据」。三、正确做法订阅派生的布尔状态规则文档给出的修正方案是// ✅ 正确只在布尔值真正翻转时才重渲染 function Sidebar() { const isMobile useMediaQuery((max-width: 767px)) return nav className{isMobile ? mobile : desktop} / }两处关键差异数据粒度不同useMediaQuery订阅的是 CSS 媒体查询的匹配结果而不是像素宽度。浏览器只在查询结果从「匹配」翻转为「不匹配」或反过来时才通知订阅者。边界值一致(max-width: 767px)与width 768在语义上等价但前者把「连续值 → 布尔值」的派生计算下沉到了浏览器原生层面matchMediaReact 组件拿到手的永远是干净的布尔快照。结果是窗口在 767px 以内或 768px 以上任意拖动组件都完全不会重渲染只有在跨过断点那一刻isMobile翻转才发生一次重渲染。重渲染频率从「每像素一次」降到「每断点一次」。四、原理支撑布尔阈值如何「截断」effect 的重跑这条规则不只是减少渲染次数它同样能减少useEffect的重复执行。同属该技能包的 .agents/skills/vercel-react-best-practices/rules/rerender-dependencies.md 给出了同一场景的 effect 版本对比// ❌ 错误宽度从 767、766、765……每次变化 effect 都会重跑 useEffect(() { if (width 768) { enableMobileMode() } }, [width]) // ✅ 正确只在布尔值翻转时重跑 const isMobile width 768 useEffect(() { if (isMobile) { enableMobileMode() } }, [isMobile])把派生布尔值放进依赖数组等于给 effect 加了一道「布尔闩」依赖从高频率变化的连续值收窄为低频率翻转的布尔值effect 的执行次数与派生状态的重渲染次数被一起截断。五、仓库落地手写一个可复用的useMediaQuery「订阅派生布尔值」不能只停留在概念上。本仓库的面试题库 manuscript/02-intermedio.md 在第 3182–3200 行讲解useSyncExternalStore时给出了一个直接用浏览器原生matchMedia的实现正是这条规则在生产中的典型落地方式import { useSyncExternalStore } from react function useMediaQuery(query: string): boolean { const mediaQuery window.matchMedia(query) const subscribe (callback: () void) { mediaQuery.addEventListener(change, callback) return () mediaQuery.removeEventListener(change, callback) } const getSnapshot () window.matchMedia(query).matches return useSyncExternalStore(subscribe, getSnapshot) }这个 Hook 的价值在于订阅的是媒体查询的change事件而change事件只在匹配状态翻转时触发天然满足「订阅派生布尔值」的要求useSyncExternalStore是 React 官方提供的「外部数据源」接入点能保证在并发渲染与 hydration 期间读到一致的快照这一点在 manuscript/02-intermedio.md 中明确说明它「连接 React 与外部数据源提供并发渲染与 hydration 期间的一致读取」把它封装成useMediaQuery((max-width: 767px))后组件内部可以放心使用isMobile这种派生布尔值而无需关心窗口原始宽度。顺带一提manuscript/02-intermedio.md 中同一个模式还被用于(prefers-color-scheme: dark)的暗色主题判断——订阅「是否暗色」这个布尔值而不是订阅色值本身思路与本规则完全一致。六、姊妹规则派生状态根本不该进 state 和 effect订阅派生布尔值只是「治标」要彻底根治重渲染还要配合另一条姊妹规则 .agents/skills/vercel-react-best-practices/rules/rerender-derived-state-no-effect.md能在渲染期间从当前 props/state 算出来的值就不要存进 state也不要在 effect 里更新它。它的反面示例是一个经典的「冗余 state effect 同步」反模式// ❌ 错误冗余 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 } // ✅ 正确渲染期间直接派生 function Form() { const [firstName, setFirstName] useState(First) const [lastName, setLastName] useState(Last) const fullName firstName lastName return p{fullName}/p }setFullName在 effect 里触发会导致一次多余的渲染首渲染 effect 后的二次渲染并且当firstName/lastName与fullName的同步逻辑一旦漏改就会出现「状态漂移state drift」——两个 state 各说各话。本仓库的面试题 que-es-el-estado-derivado-y-por-que-conviene-calcularlo-en-el-render.json 对这个话题给出了同样的结论并补充了判断标准派生状态derived state指能由现有 props 或其他 state 直接算出的值。大多数情况下不要为它单独开一个useState直接在渲染期间计算即可。// ❌ 冗余且易失同步每次 items 变化都要记得手动同步 count const [items, setItems] useState([]) const [count, setCount] useState(0) // ✅ 渲染期派生 const [items, setItems] useState([]) const count items.length const expensive useMemo(() compute(items), [items]) // 仅当计算昂贵时该题库条目还总结了派生状态的好处值得在面试和代码评审中直接引用更少的同步 bug单一数据源不存在两处状态需要手动保持一致更少的渲染避免「先 setState 再在 effect 里 setState」的双重渲染唯一的 truth source派生值的正确性由源数据保证。使用useState的边界只有那些独立的、会随时间/交互/副作用变化的数据才需要状态其余一切能算出来的值都应该在渲染期间派生必要时用useMemo包裹昂贵的计算。七、综合判断这条规则适合用在哪什么时候该放弃优先应用useMediaQuery/订阅派生布尔值模式的场景响应式布局的导航、侧边栏、卡片栅格本规则示例中的Sidebar就是典型暗色主题切换prefers-color-scheme一切「业务上只需要布尔结论、底层却是连续数值」的订阅滚动位置是否超过阈值、某元素是否进入视口、列表是否为空等。需要谨慎的地方派生布尔值的计算若发生在每次渲染中且成本高应配合useMemo缓存见 que-es-el-estado-derivado-y-por-que-conviene-calcularlo-en-el-render.json 中「仅当计算昂贵时使用useMemo」的提示但不要为了简单的width 768这类廉价表达式去用useMemo——那只会引入依赖数组比对的开销不要把这条规则与「把派生值存进 state 用 effect 同步」混为一谈订阅派生布尔值解决的是订阅粒度问题渲染期派生解决的是状态冗余问题两者要一起用才能彻底消除多余渲染如果某个布尔派生值的翻转本身就需要触发副作用如进入移动端后加载轻量版组件应像第四节那样把派生布尔值放进 effect 依赖而不是订阅原始连续值。八、速查清单把这条规则沉淀成代码评审时的自检清单问自己这个组件真正需要的是「连续值」还是「布尔结论」只需要布尔结论就订阅布尔值。选择订阅源能用matchMedia/useSyncExternalStore订阅派生布尔值就不要useState存原始值。检查 effecteffect 依赖里是不是在跟连续值width、滚动位置较劲把它替换成派生布尔值。检查 state这个值是不是能直接从 props/state 算出来能算就别useState更别在 effect 里setState去同步rerender-derived-state-no-effect.md。验证收益用 React DevTools 的 Profiler / highlight updates本仓库题库 que-provoca-un-re-render-en-un-componente-de-react.json 推荐的调试方法确认组件在断点之间的窗口拖拽中不再重渲染。一句话总结连续值 → 订阅布尔结论 → 订阅派生的布尔值能算出来的值 → 渲染期直接算。把这三条串起来你就掌握了 React 重渲染优化中最实用的一档基本功——这也是本仓库面试题「什么是派生状态」「什么会引起重渲染」的标准答案在工程实践中的完整落点。赞分享前端教程【免费下载链接】preguntas-entrevista-reactPreguntas típicas sobre React para entrevistas de trabajo ⚛️项目地址https://gitcode.com/gh_mirrors/pr/preguntas-entrevista-react点击查看免费下载相关推荐Plate 项目中的 React 重渲染优化订阅派生布尔状态Derived State以降低重渲染频率Plate 项目中的 React 重渲染优化订阅派生布尔状态Derived State以降低重渲染频率 导读 在 React 富文本编辑器这类高频交互应用人工智能大模型推理引擎深度学习本地部署模型量化模型优化多模态计算机视觉嵌入式Sanity React 性能规则详解:订阅派生布尔状态,降低组件重渲染频率Sanity React 性能规则详解:订阅派生布尔状态,降低组件重渲染频率 本文基于 Sanity 单仓内置的 Vercel React 最佳实践技能 57CMS前端旧电视盒子刷Armbian斐讯T1变7×24小时小服务器的改造攻略旧电视盒子刷Armbian斐讯T1变7×24小时小服务器的改造攻略 用 amlogic s9xxx armbian 项目可以把斐讯T1这类旧盒子的安卓系统换嵌入式开发工具构建工具操作系统上一篇WarcraftHelper免费魔兽争霸3辅助宽屏适配FPS解锁完整指南下一篇3 步完成 WeMod 专业版免费解锁Wand-Enhancer 一键补丁完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考