A ternary in JSX is the cleanest way to express "either A or B": both branches are explicit, and the result is always a valid React node. When you want "render this only sometimes", returning null (or false, or undefined) tells React to render nothing, which is safer than building an empty <div>. The el/render pair here mimics what React.createElement and the renderer do under the hood so we can run the example in plain Node; in your real component you would write <span>Welcome back, {name}!</span> instead. Keep ternaries short; nested ternaries hurt readability fast and should be refactored to early returns or a helper component.

A && B returns B when A is truthy and returns A itself when A is falsy. That second clause is the trap: if A is the number 0, && returns 0, and React happily renders 0 as a text node. The two safe fixes are to compare to a real boolean (count > 0) or to cast (Boolean(items?.length)); both ensure the left operand is true or false, never 0. The same problem applies to empty strings ('') and NaN; if the left side might ever be falsy-but-printable, prefer a ternary or a comparison. The takeaway: && is shorthand for "this thing is a boolean flag", not "this thing is non-zero".

When a component has more than two branches, ternaries inside JSX become unreadable; early returns turn the branching into a plain switch-like cascade that is easy to scan top to bottom. Extracting each branch to a small named helper (LoadingState, ErrorState, EmptyState) lets the parent stay declarative and tells the reader at a glance what each state looks like. This also unlocks easy reuse: another search page can pull EmptyState directly without copy-pasting markup. Avoid the temptation to inline if/else blocks inside JSX with an IIFE; if you ever feel the need, that is a strong signal that the branches deserve to be their own components.