In a React component, `{cart.length && <CartSummary />}` puts a stray `0` on the page when the cart is empty. Why does that happen, and how do you fix it?

## The shape of the bug ```jsx function Cart({ cart }) { return <div>{cart.length && <CartSummary cart={cart} />}</div>; } ``` With three items this renders the summary. With zero items it renders the character `0` — usually somewhere it looks like a typo rather than a bug, which is exactly why it survives review. Nothing here is React magic. Two independent rules combine: what `&&` evaluates to, and what React does with the value it gets as a child. ## Rule one: && yields an operand, not a boolean `a && b` evaluates `a`; if `a` is falsy it returns `a` itself and never evaluates `b`. If `a` is truthy it returns `b`. It is a value-selecting operator, not a boolean-producing one. `0 && <X />` is therefore `0`, `'' && <X />` is `''`, and `NaN && <X />` is `NaN`. Only when the left side is already a boolean (`isOpen && <X />`) does the falsy branch happen to give you `false`. ## Rule two: React classifies children by type, not truthiness When React renders a child value it looks at the type: - **string, number** — rendered as a text node. `0` is a number, so it prints. `NaN` prints as `NaN`. - **null, undefined, true, false** — rendered as nothing at all. These are the only "invisible" values. - **array** — each element is rendered in order. - **React element** — rendered as the described subtree. - **plain object** — an error: React refuses objects as children. The skip list is small and explicit. `0` is not on it, and neither is `''` — an empty string is a string, so React renders an empty text node. It is invisible, so an empty-string guard produces a silent, harmless-looking leak instead of a visible one, and the same defect passes unnoticed for months. So the combination is: `&&` hands React a number, and React faithfully renders numbers. ## The fixes, in order of preference **Compare explicitly.** Make the left operand a boolean by construction: ```jsx {cart.length > 0 && <CartSummary cart={cart} />} ``` This reads as the condition you actually meant ("there is at least one item"), and it cannot leak because `>` always produces a boolean. **Ternary with an explicit null.** Useful when there is an else branch anyway, and self-documenting when there is not: ```jsx {cart.length ? <CartSummary cart={cart} /> : null} ``` The ternary is safe for a different reason: it never returns the tested value, only one of the two branches you wrote. **Coerce.** `Boolean(cart.length) && ...` or `!!cart.length && ...` both work. They are correct but weaker code: the reader has to reconstruct which falsy value you were defending against, and a later refactor from `cart.length` to `cart.total` silently keeps the coercion while the intent drifts. **Early return.** When the whole component has nothing to show, `if (cart.length === 0) return null;` above the JSX is often clearer than any inline guard. ## Related traps in the same family - `{value || <Fallback />}` has the mirror-image problem: if `value` is a renderable-but-unwanted value such as `0`, it is falsy, so the fallback shows when you wanted the zero. If it is a non-empty string it renders that string instead of your fallback. - Optional API data: `{data?.count && <Badge count={data.count} />}` leaks a `0` for a genuinely-zero count, which is a common cause of a stray zero in dashboards. - TypeScript does not save you. `cart.length && <CartSummary />` types as `number | Element`, and `number` is a legal `ReactNode`, so the compiler is satisfied. ## Why interviewers like this question It separates candidates who have memorised the idiom from candidates who can say *why* it fails. The complete answer names both halves — `&&` returns the operand, and React renders numbers — and then picks a fix on readability grounds rather than reciting `!!`. It also opens naturally onto the wider question of what each child value type renders as, which is the same knowledge in a different frame.