★ FEATURED ARTICLE 前端教程【免费下载链接】preguntas-entrevista-reactPreguntas típicas sobre React para entrevistas de trabajo ⚛️项目地址https://gitcode.com/gh_mirrors/pr/preguntas-entrevista-react点击查看免费下载本指南以仓库内 Vercel 工程团队维护的性能规则文档 rerender-transitions.md 为骨架系统讲解如何用startTransition将高频、非紧急的 React 状态更新标记为过渡更新避免渲染阻塞拖慢用户交互。读完你将掌握紧急更新与非紧急更新的优先级模型、startTransition与useTransition的正确用法以及它在滚动跟踪、搜索过滤等真实场景下的落地写法并顺带了解它与useDeferredValue、useRef等同类优化手段的分工。问题场景高频非紧急更新为什么会卡住 UI在 React 中每一次setState都可能触发一次组件树重渲染。当更新频率极高、渲染代价又不低时两者叠加就会让用户明显感到掉帧卡顿。最常见的受害者之一就是滚动跟踪function ScrollTracker() { const [scrollY, setScrollY] useState(0) useEffect(() { const handler () setScrollY(window.scrollY) window.addEventListener(scroll, handler, { passive: true }) return () window.removeEventListener(scroll, handler) }, []) }这段代码的问题在于scroll事件在用户滚动过程中以极高频率触发每一次触发都会调用setScrollY并引发一次同步渲染。如果这个组件或其子树的重渲染成本较高例如下游还挂着复杂的列表、图表渲染就会抢占主线程用户会看到滚动卡顿、输入迟滞——因为浏览器在等待 React 完成渲染后才继续处理下一次交互。从规则文件的前置元数据可以看出它的定位impact: MEDIUMimpactDescription: maintains UI responsiveness标签为rerender, transitions, startTransition, performance。它属于 SKILL.md 中第 5 类Re-render Optimization重渲染优化规则属于中等影响级别目标是维持 UI 响应性。该规则原文明确给出了判断标准Mark frequent, non-urgent state updates as transitions to maintain UI responsiveness——把频繁且非紧急的状态更新标记为 transition。解决方案用 startTransition 包裹非紧急更新修复方式非常直接把非紧急的更新放进startTransition回调里告诉 React这次更新不着急可以晚点再算import { startTransition } from react function ScrollTracker() { const [scrollY, setScrollY] useState(0) useEffect(() { const handler () { startTransition(() setScrollY(window.scrollY)) } window.addEventListener(scroll, handler, { passive: true }) return () window.removeEventListener(scroll, handler) }, []) }对比两个版本差异只有一行setScrollY(window.scrollY)被包进了startTransition(() ...)。效果上滚动位置的更新变成了可延迟、可中断的过渡更新React 会优先处理用户输入、点击等紧急交互在空闲时再完成滚动位置的渲染即使滚动事件连续爆发React 也可以丢弃中间结果只渲染最新的位置。细心的读者还会注意到正确版本中滚动监听器额外传了{ passive: true }。这对应同技能库中的另一条规则 client-passive-event-listeners.md——浏览器默认会等待监听器执行完毕、确认没有调用preventDefault()后才继续滚动从而产生滚动延迟标记passive: true后浏览器即可立即滚动。passive解决的是事件本身阻塞滚动的问题startTransition解决的是状态更新渲染阻塞主线程的问题二者互为补充。原理紧急更新与非紧急更新的优先级模型要理解startTransition为什么有效需要先了解 React 对更新的两种分类。仓库中的问答内容 que-es-start-transition-y-en-que-se-diferencia-de-actualizar-el-estado-de-forma-normal.json 对此有清晰归纳紧急更新Urgent Updates直接由用户交互触发如输入框打字、点击按钮。这类更新必须立刻反映在界面上否则用户会感到延迟。非紧急更新Transition Updates由startTransition标记的更新。React 可以中断或推迟它们把优先级让给紧急更新。典型的组合用法是把两者放在同一个事件处理器里紧急的部分立刻执行非紧急的部分交给 transitionimport { useState, startTransition } from react function Search({ items }: { items: string[] }) { const [query, setQuery] useState() const [filtered, setFiltered] useState(items) function onChange(e: React.ChangeEventHTMLInputElement) { const value e.target.value setQuery(value) // 紧急输入框必须即时回显 startTransition(() { setFiltered(items.filter(i i.includes(value))) // 非紧急可延迟 }) } return ( input value{query} onChange{onChange} / List items{filtered} / / ) }其中setQuery(value)是紧急更新让输入框即时响应setFiltered(...)是过渡更新涉及整个列表的过滤与重渲染可以推迟到空闲时段完成。这正是该规则在滚动场景之外的另一种典型应用搜索过滤。同一个文档还指出了两个容易混淆的边界过渡更新可能落后于紧急更新因此界面可能出现短暂的新旧状态混叠——这是设计使然用于换取流畅度startTransition不能替代useMemo/useCallback。它解决的不是避免重复计算而是渲染优先级问题——前者管缓存后者管调度。useTransition 钩子用 isPending 感知过渡进度如果只是把更新标记为非紧急使用顶层导出的startTransition即可。但当你需要在界面上反馈正在更新中时应该改用useTransition钩子它额外返回isPending标志。仓库问答 para-que-sirve-el-hook-use-transition-y-cuando-deberias-usarlo.json 给出了完整示例import { useState, useTransition } from react function FilterableList({ items }: { items: string[] }) { const [query, setQuery] useState() const [results, setResults] useState(items) const [isPending, startTransition] useTransition() const handleChange (event: React.ChangeEventHTMLInputElement) { const value event.target.value setQuery(value) startTransition(() { const filtered items.filter(item item.toLowerCase().includes(value.toLowerCase()) ) setResults(filtered) }) } return ( input value{query} onChange{handleChange} / {isPending pCargando resultados.../p} ul {results.map(item ( li key{item}{item}/li ))} /ul / ) }useTransition()返回[isPending, startTransition]startTransition与顶层导出的同名函数行为一致用于标记非紧急更新isPending为true表示当前有过渡更新尚未完成可以在界面上显示加载提示如示例中的Cargando resultados...避免用户以为界面卡死。同技能库中的 rendering-usetransition-loading.md 还进一步建议用useTransition替代手写的isLoading状态。手动管理加载态需要自己维护setIsLoading(true/false)的配对容易出错而useTransition自带以下好处自动的 pending 状态无需手动开关加载标志错误韧性即使过渡抛错isPending也能正确复位打断处理新的过渡会自动取消/取代尚未完成的旧过渡天然避免竞态该规则示例中还展示了 React 19 中startTransition可接受 async 函数、在过渡内进行异步取数的写法。使用边界什么时候该用什么时候不该用startTransition不是万能钥匙使用前先回答两个问题更新是否高频是否非紧急两个条件都满足才适合用。适合使用的场景滚动位置、鼠标轨迹等高频跟踪数据的渲染规则主场景搜索/过滤大型列表输入即时回显、列表结果可稍后渲染图表、可视化等代价高昂的派生渲染响应输入数据量大的列表切换、排序等不要求即时反馈的操作。不适合使用的场景必须即时反馈的紧急更新如输入框本身的值、表单校验错误提示强行包进 transition 反而会引入可见延迟低频、一次性的更新——没有阻塞压力包一层 transition 徒增复杂度依赖渲染顺序的代码——过渡更新可能被中断或滞后不应假设包裹后立刻生效。另外注意规则原文的滚动示例把每次滚动更新都包进 transition这是一种兜底写法。如果某个高频值根本不需要驱动 UI 变化同技能库的姊妹规则 rerender-use-ref-transient-values.md 给出了更激进的优化把这类瞬时值放进useRef完全不触发渲染ref 更新不会导致 re-render仅在需要时直接操作 DOM。两条规则的取舍是——需要渲染时用 transition 降低优先级不需要渲染时用 ref 彻底跳过渲染。例如同样是鼠标跟踪如果要点位是渲染出来的元素用useTransition保流畅如果只需移动一个绝对定位的小点useRef 直接改transform更划算。与 useDeferredValue 的分工过渡相关的优化还有一个近亲useDeferredValue。规则 rerender-use-deferred-value.md 与本文规则同属重渲染优化类处理的是输入触发昂贵派生渲染的场景function Search({ items }: { items: Item[] }) { const [query, setQuery] useState() const deferredQuery useDeferredValue(query) const filtered useMemo( () items.filter(item fuzzyMatch(item, deferredQuery)), [items, deferredQuery] ) const isStale query ! deferredQuery return ( input value{query} onChange{e setQuery(e.target.value)} / div style{{ opacity: isStale ? 0.7 : 1 }} ResultsList results{filtered} / /div / ) }二者的区别在于控制粒度startTransition/useTransition把更新的执行标记为非紧急你显式决定哪段setState可以延迟useDeferredValue把某个值标记为可滞后下游基于deferredQuery的渲染自动降级为低优先级且必须搭配useMemo把昂贵计算缓存起来否则延迟没有任何意义该规则在文末有明确 Note。从仓库内容看que-es-start-transition-y-en-que-se-diferencia-de-actualizar-el-estado-de-forma-normal.json 与 para-que-sirve-el-hook-use-transition-y-cuando-deberias-usarlo.json 这两份问答内容也共同佐证了同一结论startTransition不解决重复计算问题那是useMemo/useCallback的职责它解决的是渲染调度优先级问题。实践时可按需组合——过滤逻辑用useTransition包裹昂贵的模糊匹配计算用useMemo缓存。规则在项目中的定位与落地建议本规则文件是 .agents/skills/vercel-react-best-practices 技能包的一部分该技能包由 Vercel 工程团队维护metadata.json 标注了organization: Vercel Engineering面向 React/Next.js 性能优化横跨 8 个类别按影响等级从 CRITICAL 到 LOW 排序供 Agent 与 LLM 在编写、审查、重构 React 代码时引用。每条规则文件都遵循统一结构前置元数据标题、影响等级、影响描述、标签 问题说明 错误示例 正确示例 参考说明详见 README.md。rerender-transitions.md位于第 5 类Re-render Optimization影响等级 MEDIUM与之同类的规则还有rerender-use-deferred-value、rerender-use-ref-transient-values、rerender-memo等。落到实际项目时可按以下顺序自查滚动/输入类高频场景这个值是否必须驱动 UI不需要 → 用useRef存储见 rerender-use-ref-transient-values.md需要驱动 UI 但更新频繁且非紧急→ 用startTransition包裹本文规则需要展示更新中反馈→ 改用useTransition的isPending见 rendering-usetransition-loading.md涉及昂贵的派生计算→ 同时用useMemo缓存见 rerender-use-deferred-value.md监听滚动、触摸、滚轮事件→ 记得加{ passive: true }见 client-passive-event-listeners.md。这套组合拳的核心思想始终如一把渲染调度权交给 React让紧急交互插队让非紧急更新靠边等待。startTransition是其中成本最低、侵入最小的一招——一行包裹换来的是主线程不被高频更新占满用户交互始终保持流畅。赞分享前端教程【免费下载链接】preguntas-entrevista-reactPreguntas típicas sobre React para entrevistas de trabajo ⚛️项目地址https://gitcode.com/gh_mirrors/pr/preguntas-entrevista-react点击查看免费下载相关推荐Phoenix 前端性能实践用 React startTransition 处理非紧急更新保持 UI 响应Phoenix 前端性能实践用 React startTransition 处理非紧急更新保持 UI 响应 导读 本文聚焦 Vercel Engineeri可观测性AI 评测LLMOpsAI 应用人工智能OpenMontage 前端性能实践用 startTransition 处理 React 非紧急更新保持 UI 始终响应OpenMontage 前端性能实践用 startTransition 处理 React 非紧急更新保持 UI 始终响应 导读 在 OpenMontage人工智能AI Agent音视频媒体生成工作流自动化open-agents 中 React 重渲染优化实践用 startTransition 处理非紧急状态更新open agents 中 React 重渲染优化实践用 startTransition 处理非紧急状态更新 本文讲解 open agents 仓库内置 Ve人工智能AI Agent代码智能体Agent 工作流Agent 沙箱工具调用后端前端上一篇Granian日志系统详解如何配置访问日志和运行时日志下一篇Git-Sim代码架构深度解析理解GitSimBaseCommand核心设计创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
