Cal.com 渲染规范：用显式条件渲染替代 && 短路写法，规避 0/NaN 被渲染的陷阱
【免费下载链接】cal.diyScheduling infrastructure for absolutely everyone.项目地址: https://gitcode.com/GitHub_Trending/ca/cal.diy
本文基于 cal.diy（Cal.com）仓库内收录的 Vercel React 最佳实践规则rendering-conditional-render，讲解 React JSX 中"条件为 0 时误渲染出字符 0"这一经典问题的成因、判定标准与正确写法，并结合本仓库中真实的组件源码（如应用安装流程的EventTypesStepCard、Blocklist 详情面板等）展示该规则在前端代码库中的落地形态，帮助开发者在编写、评审或让 Agent 重构 React 代码时直接套用正确的条件渲染模式。
规则定位：它属于哪一类优化
该规则文件位于 rendering-conditional-render.md，其 frontmatter 元信息完整定义了规则的身份：
- title：Use Explicit Conditional Rendering
- impact：
LOW - impactDescription：
prevents rendering 0 or NaN（防止把0或NaN渲染到页面上） - tags：
rendering, conditional, jsx, falsy-values
从配套的 SKILL.md 可以看到，它隶属于一份面向 AI Agent 与 LLM 的 45 条 React/Next.js 性能规则集，按影响力分为 8 个优先级类别。其中第 6 类为Rendering Performance（渲染性能，MEDIUM），前缀rendering-，Quick Reference 中对该条的概括是：
rendering-conditional-render- Use ternary, not && for conditionals
完整的规则展开版收录在 AGENTS.md 的 6.7 节（Use Explicit Conditional Rendering），与单文件版本内容一致。也就是说：这条规则虽然单次影响等级为 LOW，但它是"渲染正确性"问题而非"性能"问题——0被渲染出来是用户可直接观察到的 UI 缺陷（比如徽标上凭空多出一个 "0"、空列表里出现一个孤零零的数字），在代码评审中属于应当无条件拦截的 bug 类问题。
问题成因：JS 短路求值 + React 渲染语义的叠加
理解这条规则需要先厘清两层语义：
- JavaScript 层面：
a && b在a为 falsy 时返回a本身，而不是false。0、NaN、""、null、undefined、false都是 falsy 值，0 && <X/>的求值结果就是数字0。 - React 渲染层面：React 会渲染字符串、数字和数组；
0会被字符串化为"0"输出到 DOM，NaN会被输出为"NaN"；而false、null、undefined会被跳过，空字符串""渲染为不可见内容。
两层叠加后得到各 falsy 值在{x && <Component/>}中的实际表现：
左操作数x的取值 | x && <C/>的求值结果 | React 实际渲染 | 是否符合"不渲染"预期 |
|---|---|---|---|
false/null/undefined | false/null/undefined | 什么都不渲染 | 符合 |
"" | "" | 空字符串，无可见内容 | 视觉符合 |
0 | 0 | 页面上出现字符0 | 不符合 |
NaN | NaN | 页面上出现字符NaN | 不符合 |
所以真正的风险面集中在数值型条件：任何"用数字本身当条件"的写法（计数、数组长度、金额、时间戳等）都可能踩中这个坑。
规则原文示例：错误的&&与正确的三元
规则文件给出的反例是典型的"徽标计数"场景：
错误写法（count为 0 时会把 "0" 渲染出来）：
function Badge({ count }: { count: number }) { return ( <div> {count && <span className="badge">{count}</span>} </div> ) } // When count = 0, renders: <div>0</div> // When count = 5, renders: <div><span class="badge">5</span></div>正确写法（count为 0 时什么都不渲染）：
function Badge({ count }: { count: number }) { return ( <div> {count > 0 ? <span className="badge">{count}</span> : null} </div> ) } // When count = 0, renders: <div></div> // When count = 5, renders: <div><span class="badge">5</span></div>两个示例的关键差异在于：错误写法把"条件"与"要展示的值"混为同一个变量count，falsy 分支会泄露原始数值；正确写法用count > 0这样的显式布尔表达式作为三元条件，falsy 分支显式返回null，保证"无数据"时 DOM 里不产生任何可见内容。
判定标准：什么时候&&可以保留，什么时候必须改
规则原文的适用条件是 "when the condition can be0,NaN, or other falsy values that render"。由此可以整理出可操作的判定清单：
必须改用三元（或等价的显式布尔条件）的场景：
- 条件本身是数字或可能为数字：
{count && ...}、{items.length && ...}、{total && ...}； - 条件来自可能为
0的计算结果，如差值、余额、倒计时剩余秒数； - 变量类型不可信（如从接口反序列化的
unknown/ 表单值），理论上可能是0或NaN。
可以安全使用&&的场景：
- 条件是明确的布尔值：
{isLoading && <Spinner/>}、{hasPermission && ...}； - 条件是字符串/对象的有无，且 falsy 分支泄露的是
""、null、undefined等 React 不渲染的值（空字符串渲染为无可见内容）； - 需要的是"真值短路"逻辑而非渲染语义（注意：JSX 中不存在真正的短路，
&&永远会产出左侧值）。
一个实用的工程化兜底是把条件强制布尔化后再短路：{Boolean(value) && <X/>}或{!!value && <X/>}。此时&&左操作数恒为true/false，React 永不渲染false，等价于安全。
仓库源码印证：cal.diy 前端代码库中的实际用法
规则并非纸上谈兵。在 cal.diy 的apps/web前端代码中，可以观察到与规则一致的两类惯用模式：显式length > 0 ?三元，以及Boolean(x) &&布尔守卫。
模式一：三元 + 空态回退。应用安装流程的"选择事件类型"步骤组件 EventTypesStepCard.tsx 在渲染事件类型列表时，对表单字段数组使用了显式长度判断，并在空分支提供 UI 回退：
{fields.length > 0 ? ( fields.map((field, index) => ( <EventTypeCard key={`${field.fieldId}`} handleSelect={() => { update(index, { ...field, selected: !field.selected }); }} userName={userName} {...field} /> )) ) : ( <div className="text-subtle bg-cal-muted w-full p-2 text-center text-sm"> Team has no Events </div> )}（见 apps/web/components/apps/installation/EventTypesStepCard.tsx）这里如果写成{fields.length && fields.map(...)}，当用户尚未添加任何事件类型时，页面上会渲染出一个孤零零的0，而不是"Team has no Events"的空态提示。
同一文件还展示了模式二：Boolean()布尔守卫。在渲染时长徽标时，条件同样是数字（durations.length），作者显式转换后再短路（见 apps/web/components/apps/installation/EventTypesStepCard.tsx）：
{Boolean(durations.length) && durations.map((duration) => ( <Badge key={`event-type-${id}-duration-${duration}`} variant="gray" startIcon="clock"> {duration}m </Badge> ))}由于Boolean(durations.length)恒为true/false，false不会被 React 渲染，从而在不引入完整三元的情况下规避了0泄露问题。此外，该文件中对字符串条件也使用了同类守卫：{Boolean(description) && (<div ...>)}（EventTypesStepCard.tsx）。
模式一在其他模块中同样大量出现，进一步印证这是该代码库的既定风格：
- Blocklist 详情抽屉中的审计历史列表：
{detailsData.auditHistory.length > 0 ? (（BlocklistEntryDetailsSheet.tsx）； - 嵌入配置中的时长选项：
{durationsOptions.length > 0 ? (（Embed.tsx）； - 事件类型的多选人员组件：
{value.length > 0 ? (（CheckedUserSelect.tsx）； - 可用性设置中的主持人列表：
{hosts && hosts.length > 0 ? (（EventAvailabilityTab.tsx，这里hosts可能为null，hosts.length前再加一层空值保护）。
这些用法与规则文档的结论互相印证：凡是以"长度/计数/数值"作为 JSX 条件的地方，仓库代码要么写成x.length > 0 ? ... : 回退三元，要么先做布尔转换，没有发现依赖0会被静默吞掉的裸{count && ...}写法。
给代码评审与 Agent 工作流的检查要点
该规则集本身是面向 AI Agent 与 LLM 的自动化编码指引（见 AGENTS.md 开篇说明："This document is mainly for agents and LLMs to follow when maintaining, generating, or refactoring React and Next.js codebases"）。落地为评审或生成代码时的检查清单：
- 扫描 JSX 表达式：形如
{expr && <JSX>}的写法中，先判断expr的类型； - 数值型条件一律改写：
count、length、total、size、时间戳等数值，改为expr > 0 ? <JSX> : null，或在确有回退 UI 时补全 else 分支（如"暂无数据"提示）； Boolean(expr) && <JSX>视为合规等价写法，保留其简洁性，避免为了机械执行规则而引入冗余三元；- 注意 else 分支选择：无回退 UI 时用
null；需要空态提示时提供回退组件，这同时改善了可访问性与用户体验； - 类型不可信时优先防御：对来自接口/表单的
unknown值，Number.isFinite(x) && x > 0 ? ... : null可同时挡住0与NaN两类渲染泄露（NaN > 0为false，三元会走 null 分支）。
小结
rendering-conditional-render这条 LOW 级规则解决的是一个高频、可见、易被忽略的 React 渲染正确性问题：&&短路的左操作数若是0或NaN，会被原样渲染成字符。正确做法是把条件显式化为布尔表达式（count > 0、list.length > 0），用三元选择渲染分支并以null或空态组件作为 falsy 回退；Boolean(x) &&是等价的简洁写法。cal.diy 仓库在 EventTypesStepCard.tsx、BlocklistEntryDetailsSheet.tsx、Embed.tsx 等组件中的实际代码，完整演示了这两种落地模式，可直接作为新代码与 Agent 生成代码的参照模板。
【免费下载链接】cal.diyScheduling infrastructure for absolutely everyone.项目地址: https://gitcode.com/GitHub_Trending/ca/cal.diy
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
