Expressions and Conditional Rendering

## Braces embed a value, and React decides what to do with it `{expr}` inside JSX means "evaluate this JavaScript expression and use the result as a child". The braces impose no filtering of their own — whatever the expression produces is handed to React, which then dispatches on the value's type. Knowing that table is the whole of conditional rendering in React, because every conditional idiom ends up producing one of these values. ## The table **Strings** render as a text node, exactly as typed. `{'Ada'}` and the literal text `Ada` in JSX are the same output. An empty string produces an empty text node — no visible output, but a node all the same. **Numbers** render as text too. `{42}` renders `42`, `{0}` renders `0`, and `{NaN}` renders `NaN`. There is no special case for zero, which is precisely why a falsy guard can print a stray digit. **null and undefined** render nothing. No node, no placeholder, no whitespace. **Booleans** render nothing — both `true` and `false`. This is a deliberate convenience so that boolean-producing guards can be written inline without emitting the word `false`. **Arrays** are flattened into the child list: each element is rendered in order, using these same rules recursively. `{['a', 'b']}` renders `ab`; `{[null, 'a']}` renders `a`. **React elements** — what JSX itself produces — render as the subtree they describe. **Plain objects** are not valid children. React raises an error stating that objects are not valid as a React child, naming the object's keys to help you find it. The same applies to a `Date`, a `Map`, or an `Error` instance: they are objects, so they are rejected rather than stringified. ## Why the object case is the one you actually hit Almost every occurrence in a real codebase is the same slip: the data arrived as an object and you rendered the whole thing. ```jsx // throws: objects are not valid as a React child <p>{user}</p> // fine <p>{user.name}</p> <p>{user.createdAt.toLocaleDateString()}</p> <p>{String(error)}</p> ``` Notice that React deliberately does *not* fall back to `String(value)` for objects. Doing so would render `[object Object]` on the page — a silent, useless output — where an error at least points at the line. It is a design decision to fail loudly on the case where the developer almost certainly made a mistake, and to render quietly on the cases (null, booleans) that are almost certainly intentional. ## Consequences you can reason out from the table Once you know the table, several React behaviours stop needing separate memorisation: - `return null` from a component renders nothing, because `null` renders nothing as a child. - `{isReady && <Panel />}` is safe when `isReady` is a real boolean, because the falsy branch produces `false`, which is invisible. - `{count && <Badge />}` is unsafe, because the falsy branch produces the number `0`, and numbers are visible. - Mapping an array of elements works with no wrapper, because arrays are flattened into the child list. - A stray `[object Object]` on the page is *not* a React default; if you see one, someone called `String()` or template-interpolated the object themselves. ## Whitespace, the near neighbour JSX collapses whitespace at the start and end of lines and drops lines that are pure whitespace, so two elements on separate source lines render with no space between them. Because a string child renders literally, the standard fix is to embed one: `{' '}`. It is the same rule — a string expression becomes a text node — applied to a formatting problem. ## What an interviewer is checking They want to see whether you hold a *rule* or a bag of anecdotes. Candidates who have only memorised idioms say "falsy things don't render", which is wrong in exactly the case that matters. Candidates who know the type table can derive the `0` leak, the object error, and the safety of `return null` on the spot, without having met each one before.