Sanity 仓库中的 React 渲染实践为什么条件渲染该用三元表达式而非 rendering-conditional-render 规则详解【免费下载链接】sanitySanity Studio – Rapidly configure content workspaces powered by structured content项目地址: https://gitcode.com/GitHub_Trending/sa/sanity本文围绕 Sanity 仓库内置的 Vercel React 最佳实践规则rendering-conditional-render位于 .agents/skills/vercel-react-best-practices/rules/rendering-conditional-render.md展开讲清楚「短路求值在 JSX 中会把0、NaN渲染到页面上」这一经典渲染缺陷的成因并给出可复制的三元表达式写法最后结合 Sanity 源码中的真实组件说明该规则在大型 React 代码库中如何落地验证。规则定位一条 LOW 影响级、防止视觉 Bug 的渲染规范rendering-conditional-render属于仓库中内置的 Vercel React 最佳实践技能集。该技能集共收录 57 条规则分为 8 个优先级类别异步瀑布消除、打包体积、服务端性能、客户端取数、重渲染优化、渲染性能、JS 性能、高级模式完整汇总文档见 AGENTS.md。rendering-conditional-render归入第 6 类「Rendering Performance渲染性能」前缀为rendering-影响等级impactLOW影响描述为「prevents rendering 0 or NaN防止把 0 或 NaN 渲染到页面上」标签tagsrendering, conditional, jsx, falsy-values一句话规则当条件表达式可能取0、NaN等「会被 JSX 渲染的假值」时用显式三元表达式? :替代进行条件渲染。它解决的问题不是性能而是渲染正确性一条写错的不会让组件崩溃却会在用户界面上悄悄多出一个「0」或「NaN」这样的脏字符。该规则在完整汇总文档中的条目为 AGENTS.md 第 6.8 节内容与独立规则文件完全一致可作为规则演进的对照版本。缺陷成因JSX 中哪些「假值」真的会渲染理解这条规则的关键是分清两件事JavaScript 的假值集合与 React 对 JSX 子节点的渲染策略。JavaScript 中共有 6 个假值false、0、、null、undefined、NaN。而a b的语义是当a为假值时直接返回a本身而不是false。把这一点放进 JSX 里就得到完整的行为矩阵count span中的count的求值结果JSX 渲染表现5真值span…/span正常渲染组件00渲染出文本 0NaNNaN渲染出文本 NaN渲染为空字符串页面上不可见null/undefined/false原值React 忽略不渲染任何内容也就是说写法只对null、undefined、false以及视觉上无害的安全只要条件可能是数字计数、数量、页码、进度一旦取到0或NaN这个原始值就会以字符串形式泄漏到 DOM 中。原文档示例Badge 组件的完整对照规则文件给出的反例是一个计数器徽标组件注意count 0时的渲染结果function Badge({count}: {count: number}) { return div{count span classNamebadge{count}/span}/div } // When count 0, renders: div0/div // When count 5, renders: divspan classbadge5/span/div当count为0时0 span求值得到0React 把它作为子节点渲染最终页面输出div0/div——徽标本体没出现却多出一个裸露的「0」字符。若业务逻辑在除零或解析失败时产生NaN则同样会渲染出「NaN」。修正后的写法是用三元表达式显式给出「真」与「假」两个分支假分支渲染nullfunction Badge({count}: {count: number}) { return div{count 0 ? span classNamebadge{count}/span : null}/div } // When count 0, renders: div/div // When count 5, renders: divspan classbadge5/span/div两个分支的行为对照如下count 0条件count 0为false走null分支渲染结果为空的div/divcount 5走真分支正常渲染divspan classbadge5/span/div。这里把「是否为 0」的判断显式写成了count 0同时天然排除了NaN的干扰NaN 0为false比单纯判断「真值/假值」更贴合「有内容才显示」的业务语义。Sanity 源码中的真实写法三元? : null是主库的显式惯例Sanity 主包packages/sanity中有大量组件遵循了这条「显式分支」的写法。几个有代表性的真实例子定时发布输入组件 ScheduledDocumentInput.tsx#L24{doc?._id ? ScheduleBanner id{doc._id} markers{markers} / : null}文档尚未创建时doc._id缺失用? : null显式处理「无 ID 则不渲染横幅」的分支而不是依赖短路求值。PortableText 富文本组合器 Compositor.tsx#L692return dropPosition props.edge ? DropIndicator / : null拖拽落点指示器只有在位置精确匹配时才渲染否则显式返回null。变更列表组件 ChangeList.tsx#L116return isRoot ? NoChanges / : null同样是「条件为真渲染占位组件否则渲染null」的三元结构。从源码结构看? : null三元式在主库的条件渲染中出现频率很高说明该规则并非纸面规范而是团队在评审大型表单/文档编辑界面时实际执行的风格约定。边界辨析并非一律禁用关键看条件的值域规则原文的措辞是「when the condition can be0,NaN, or other falsy values that render」——即只有在条件可能取到可渲染假值时才要求改用三元。对布尔条件依然是合法且更简洁的写法Sanity 源码中同样存在这类安全用法例如评论删除对话框 CommentDeleteDialog.tsx#L77{error TextWithTone tonecritical{t(delete-dialog.error)}/TextWithTone}这里的error是布尔语义的值为假时直接短路成false而 React 对布尔子节点一律忽略不存在泄漏问题。据此可以把该规则整理成一条可操作的判断标准条件是布尔值或明确的布尔派生量isLoading、canDelete、hasError{flag X /}安全且推荐? : null属于冗余条件是数字计数、金额、长度、页码必须用三元表达式如count 0 ? X/ : null防止0泄漏条件可能为NaN来自计算、parseFloat等必须用三元表达式并显式写出判定如Number.isFinite(value) ? X/ : null因为NaN X会渲染出「NaN」条件是字符串本身渲染为不可见文本不会造成视觉问题但若字符串后续还参与逻辑如传给子组件的id仍建议显式分支以保持语义清晰。影响等级解读为什么是 LOW 而不是更高该规则在规则集中被标记为impact: LOW影响描述prevents rendering 0 or NaN。这个评级可以从三个角度理解不影响性能它不改变渲染次数、不改变 bundle 体积、不改变数据获取路径与技能集中 CRITICAL 级的瀑布消除、打包优化不在一个维度影响的是正确性与体验泄漏出的「0」/「NaN」通常出现在徽标、角标、统计栏等小型 UI 中容易被当作设计疏漏甚至干扰屏幕阅读器读出多余字符修复成本极低从a X/改为a ? X/ : null或更严格的业务判定是一次性的一行改动属于「早改早收益」的廉价修复。小结rendering-conditional-render规则的核心只有一句话当 JSX 条件表达式的值域包含0或NaN这类「会渲染的假值」时放弃改用三元表达式显式声明渲染与不渲染两个分支。规则文件rendering-conditional-render.md与汇总文档AGENTS.md#L2045-L2071给出的是同一套 Badge 组件正反例可直接作为代码评审清单中的一条使用而 Sanity 主库中 ScheduledDocumentInput.tsx、Compositor.tsx、ChangeList.tsx 等处的? : null写法则是这条规则在真实大型 React 代码库中落地的佐证。【免费下载链接】sanitySanity Studio – Rapidly configure content workspaces powered by structured content项目地址: https://gitcode.com/GitHub_Trending/sa/sanity创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Sanity 仓库中的 React 渲染实践：为什么条件渲染该用三元表达式而非 （rendering-conditional-render 规则详解）
Sanity 仓库中的 React 渲染实践为什么条件渲染该用三元表达式而非 rendering-conditional-render 规则详解【免费下载链接】sanitySanity Studio – Rapidly configure content workspaces powered by structured content项目地址: https://gitcode.com/GitHub_Trending/sa/sanity本文围绕 Sanity 仓库内置的 Vercel React 最佳实践规则rendering-conditional-render位于 .agents/skills/vercel-react-best-practices/rules/rendering-conditional-render.md展开讲清楚「短路求值在 JSX 中会把0、NaN渲染到页面上」这一经典渲染缺陷的成因并给出可复制的三元表达式写法最后结合 Sanity 源码中的真实组件说明该规则在大型 React 代码库中如何落地验证。规则定位一条 LOW 影响级、防止视觉 Bug 的渲染规范rendering-conditional-render属于仓库中内置的 Vercel React 最佳实践技能集。该技能集共收录 57 条规则分为 8 个优先级类别异步瀑布消除、打包体积、服务端性能、客户端取数、重渲染优化、渲染性能、JS 性能、高级模式完整汇总文档见 AGENTS.md。rendering-conditional-render归入第 6 类「Rendering Performance渲染性能」前缀为rendering-影响等级impactLOW影响描述为「prevents rendering 0 or NaN防止把 0 或 NaN 渲染到页面上」标签tagsrendering, conditional, jsx, falsy-values一句话规则当条件表达式可能取0、NaN等「会被 JSX 渲染的假值」时用显式三元表达式? :替代进行条件渲染。它解决的问题不是性能而是渲染正确性一条写错的不会让组件崩溃却会在用户界面上悄悄多出一个「0」或「NaN」这样的脏字符。该规则在完整汇总文档中的条目为 AGENTS.md 第 6.8 节内容与独立规则文件完全一致可作为规则演进的对照版本。缺陷成因JSX 中哪些「假值」真的会渲染理解这条规则的关键是分清两件事JavaScript 的假值集合与 React 对 JSX 子节点的渲染策略。JavaScript 中共有 6 个假值false、0、、null、undefined、NaN。而a b的语义是当a为假值时直接返回a本身而不是false。把这一点放进 JSX 里就得到完整的行为矩阵count span中的count的求值结果JSX 渲染表现5真值span…/span正常渲染组件00渲染出文本 0NaNNaN渲染出文本 NaN渲染为空字符串页面上不可见null/undefined/false原值React 忽略不渲染任何内容也就是说写法只对null、undefined、false以及视觉上无害的安全只要条件可能是数字计数、数量、页码、进度一旦取到0或NaN这个原始值就会以字符串形式泄漏到 DOM 中。原文档示例Badge 组件的完整对照规则文件给出的反例是一个计数器徽标组件注意count 0时的渲染结果function Badge({count}: {count: number}) { return div{count span classNamebadge{count}/span}/div } // When count 0, renders: div0/div // When count 5, renders: divspan classbadge5/span/div当count为0时0 span求值得到0React 把它作为子节点渲染最终页面输出div0/div——徽标本体没出现却多出一个裸露的「0」字符。若业务逻辑在除零或解析失败时产生NaN则同样会渲染出「NaN」。修正后的写法是用三元表达式显式给出「真」与「假」两个分支假分支渲染nullfunction Badge({count}: {count: number}) { return div{count 0 ? span classNamebadge{count}/span : null}/div } // When count 0, renders: div/div // When count 5, renders: divspan classbadge5/span/div两个分支的行为对照如下count 0条件count 0为false走null分支渲染结果为空的div/divcount 5走真分支正常渲染divspan classbadge5/span/div。这里把「是否为 0」的判断显式写成了count 0同时天然排除了NaN的干扰NaN 0为false比单纯判断「真值/假值」更贴合「有内容才显示」的业务语义。Sanity 源码中的真实写法三元? : null是主库的显式惯例Sanity 主包packages/sanity中有大量组件遵循了这条「显式分支」的写法。几个有代表性的真实例子定时发布输入组件 ScheduledDocumentInput.tsx#L24{doc?._id ? ScheduleBanner id{doc._id} markers{markers} / : null}文档尚未创建时doc._id缺失用? : null显式处理「无 ID 则不渲染横幅」的分支而不是依赖短路求值。PortableText 富文本组合器 Compositor.tsx#L692return dropPosition props.edge ? DropIndicator / : null拖拽落点指示器只有在位置精确匹配时才渲染否则显式返回null。变更列表组件 ChangeList.tsx#L116return isRoot ? NoChanges / : null同样是「条件为真渲染占位组件否则渲染null」的三元结构。从源码结构看? : null三元式在主库的条件渲染中出现频率很高说明该规则并非纸面规范而是团队在评审大型表单/文档编辑界面时实际执行的风格约定。边界辨析并非一律禁用关键看条件的值域规则原文的措辞是「when the condition can be0,NaN, or other falsy values that render」——即只有在条件可能取到可渲染假值时才要求改用三元。对布尔条件依然是合法且更简洁的写法Sanity 源码中同样存在这类安全用法例如评论删除对话框 CommentDeleteDialog.tsx#L77{error TextWithTone tonecritical{t(delete-dialog.error)}/TextWithTone}这里的error是布尔语义的值为假时直接短路成false而 React 对布尔子节点一律忽略不存在泄漏问题。据此可以把该规则整理成一条可操作的判断标准条件是布尔值或明确的布尔派生量isLoading、canDelete、hasError{flag X /}安全且推荐? : null属于冗余条件是数字计数、金额、长度、页码必须用三元表达式如count 0 ? X/ : null防止0泄漏条件可能为NaN来自计算、parseFloat等必须用三元表达式并显式写出判定如Number.isFinite(value) ? X/ : null因为NaN X会渲染出「NaN」条件是字符串本身渲染为不可见文本不会造成视觉问题但若字符串后续还参与逻辑如传给子组件的id仍建议显式分支以保持语义清晰。影响等级解读为什么是 LOW 而不是更高该规则在规则集中被标记为impact: LOW影响描述prevents rendering 0 or NaN。这个评级可以从三个角度理解不影响性能它不改变渲染次数、不改变 bundle 体积、不改变数据获取路径与技能集中 CRITICAL 级的瀑布消除、打包优化不在一个维度影响的是正确性与体验泄漏出的「0」/「NaN」通常出现在徽标、角标、统计栏等小型 UI 中容易被当作设计疏漏甚至干扰屏幕阅读器读出多余字符修复成本极低从a X/改为a ? X/ : null或更严格的业务判定是一次性的一行改动属于「早改早收益」的廉价修复。小结rendering-conditional-render规则的核心只有一句话当 JSX 条件表达式的值域包含0或NaN这类「会渲染的假值」时放弃改用三元表达式显式声明渲染与不渲染两个分支。规则文件rendering-conditional-render.md与汇总文档AGENTS.md#L2045-L2071给出的是同一套 Badge 组件正反例可直接作为代码评审清单中的一条使用而 Sanity 主库中 ScheduledDocumentInput.tsx、Compositor.tsx、ChangeList.tsx 等处的? : null写法则是这条规则在真实大型 React 代码库中落地的佐证。【免费下载链接】sanitySanity Studio – Rapidly configure content workspaces powered by structured content项目地址: https://gitcode.com/GitHub_Trending/sa/sanity创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考