The '0' Trap in React Conditional Rendering: Why && Operator Betrays You

1. The Ghost in the UI

Every React developer has faced this ghost at least once in their career. You release a shiny new e-commerce site. The code looks clean, the unit tests passed, and the QA team approved the release. Then a customer reports: "Why is there a random zero floating in the middle of the screen?"

You assume it's a backend integration bug. You check the database. Nothing. You check the code: <div>{items.length && <List />}</div>. It looks like perfectly standard React code. This simple, innocent usage of the && operator is the cause of one of the most common, yet confusing UI bugs in the React ecosystem.

When items.length is 5, the list shows up. Perfect. When items.length is 0, you expect nothing to render. Instead, React renders the number 0.

2. Understanding JavaScript Short-Circuit Evaluation

To fix this, we must stop blaming React and look at the underlying language: JavaScript. The Logical AND (&&) operator does NOT return a boolean (true/false). It returns the value of one of the operands. This is a fundamental concept in JS called Short-Circuit Evaluation.

The logic is simple but dangerous:

• If the left side is Truthy, return the right side.
• If the left side is Falsy, return the left side immediately.

Let's verify this in the browser console:

/* Standard Truthy cases */
true && "Render Me"       // returns "Render Me"
10 && "Render Me"         // returns "Render Me"
"Non-empty" && "Render Me"// returns "Render Me"

/* The Falsy cases - The Safe Ones */
false && "Render Me"      // returns false (React renders nothing)
null && "Render Me"       // returns null (React renders nothing)
undefined && "Render Me"  // returns undefined (React renders nothing)

/* The Falsy case - THE BUG */
0 && "Render Me"          // returns 0  <-- !!!
NaN && "Render Me"        // returns NaN

When you write {count && <Component />} and count is 0:

1. JS engine evaluates 0. It is falsy.
2. The && operator "short-circuits" and returns 0 immediately. It doesn't even look at the component on the right.
3. React receives 0 as the child of the parent div.
4. React renders numbers. Unlike false, null, or undefined which are essentially invisible in the DOM, React considers 0 as valid content to display.

So your fancy component logic produced: <div>0</div>. This is technically correct by JS specifications, but practically disastrous for UI development.

3. The React Native Crash (Critical Warning)

In web development, accidentally printing a 0 is just an ugly, low-priority visual bug. In React Native, it is a Fatal Crash.

React Native is much stricter about the view hierarchy. You cannot render "raw text nodes" (strings or numbers) directly inside a generic View without wrapping them in a <Text> component.

If your logic leaks a raw 0:

<View>
  {/* If count is 0, this returns raw 0 inside a View */}
  {count && <Child />}
</View>

React Native throws an "Invariant Violation" error:

"Text strings must be rendered within a <Text> component."

Your app crashes instantly on the user's phone. This makes understanding the '0' trap mandatory for any mobile developer. It’s not just about aesthetics; it’s about application stability and uptime.

4. Three Patterns to Fix It For Good

Here are the safest robust patterns to handle conditional rendering with numbers.

Strategy 1: Make it Explicit (Recommended)

Don't rely on implicit type coercion. Explicitly check the condition using comparison operators.

{/* Clear intent: Render only if count is greater than 0 */}
{count > 0 && <Badge count={count} />}

{/* For arrays */}
{items.length > 0 && <List items={items} />}

This is the most readable approach. It tells other developers (and your future self) that count is a number and we care about the quantity, not just "existence". Reviewers love this clarity.

Strategy 2: The Double Bang (!!)

Force the number to be a strict boolean. !0 is true, so !!0 is false.

{/* 0 becomes false, which React safely ignores */}
{!!count && <Badge count={count} />}

This is concise and popular in the JavaScript community, but some developers find it less readable ("cryptic") than > 0. It hides the intent slightly. If you use this, ensure your team is familiar with the syntax.

Strategy 3: The Ternary Operator

If you prefer to be explicit about the "else" state using null. This is great for handling empty states.

{count ? <Badge count={count} /> : null}

Or better yet, show an empty state:

{count ? <Badge count={count} /> : <span className="empty">Empty</span>}

This is often considered the most "correct" way because it handles both branches of logic explicitly.

5. Another Villain: NaN

The number 0 isn't the only number that acts weird. NaN (Not a Number) is technically a type of number in JS, and it is also Falsy. If you have a calculation that fails (e.g., division by zero 0 / 0), you get NaN.

const progress = loaded / total * 100; // if total is 0, progress is NaN
return (
  <div>
    {progress && <ProgressBar value={progress} />}
  </div>
);

Since NaN is falsy, NaN && <Component /> returns NaN. Your user sees the text NaN printed on the screen. Always check !isNaN(value) or use logical comparisons like value > 0.

6. Automating the Fix: ESLint

You shouldn't rely on memory to catch these bugs. Configure your linter to catch them for you. Use eslint-plugin-react and enable the jsx-no-leaked-render rule.

"rules": {
  "react/jsx-no-leaked-render": ["warn", { 
    "validStrategies": ["ternary", "coerce"] 
  }]
}

This will automatically flag any usage of && with potentially numeric values, forcing you to use a safer pattern. It acts as a safety net for the entire team.

7. Can TypeScript Save Us?

You might be thinking, "I use TypeScript, so this won't happen to me." Unfortunately, TypeScript does not prevent this.

In TypeScript, the && operator preserves the type of the operands.

const count: number = 0;
const result = count && <Component />; 
// The type of 'result' is logicall 'number | JSX.Element'

React's type definitions (ReactNode) allow number as a valid child. So return <div>{result}</div> is perfectly valid TypeScript code. The compiler sees no issue because rendering a number is technically allowed behavior in React. It assumes you intended to render the number 0.

However, you can tighten your TS config or use custom utility types to catch this, but the most effective automated tool remains ESLint, which checks the AST (Abstract Syntax Tree) for this specific dangerous pattern in JSX, regardless of the valid TypeScript types.

8. Common Questions

When hiring React developers, I often ask about this specific edge case to check their understanding of JavaScript fundamentals versus React-specific knowledge.

Q: Why does specific conditional rendering output 0 in React? A: Because of JavaScript's short-circuit evaluation in the && operator. When the left-hand operand is 0, which is falsy, && returns 0 immediately. React renders numbers, so 0 appears in the DOM.

Q: How is this different in Vue or Angular? A: Frameworks like Vue (v-if) or Angular (*ngIf) handle "truthiness" internally and choose whether to render the DOM element or not based on that truthiness. They don't typically leak the value 0 into the DOM because they use template directives rather than direct JavaScript execution for rendering logic.

9. Conclusion: Defensive Coding

The && operator is convenient but dangerous when dealing with numbers (0) or potentially NaN. While idiomatic JavaScript often encourages "falsy checks", React rendering requires stricter types to ensure visual correctness.

Best Practice Checklist:

1. Never use && with a number variable on the left side.
2. Always use explicit comparison (> 0, !== 0, >= 0) to convert the condition to a strict Boolean.
3. Or use the ternary operator (? :) for explicit handling of both the "Success" and "Failure/Empty" states.
4. Enable the ESLint rule react/jsx-no-leaked-render in your project configuration today.

It’s a small habit change that prevents embarrassing UI bugs and, more importantly, keeps your React Native apps from crashing in production. Write code that is easy to read, not just easy to write. Being explicit about your logic is the hallmark of a senior engineer.