Components and JSX

A function component is a plain function that takes a props object and returns React elements, using hooks for state and effects. A class extends React.Component and implements render() plus lifecycle methods. Only error boundaries still require a class.

A pure React component returns the same elements for the same props, state and context, and changes nothing outside itself while rendering: no mutating props or existing objects, no writing to module or global variables, no I/O. Side effects belong in event handlers or effects.

Use JavaScript default parameter values in the destructuring of the props argument, such as function Button({ size = 'medium' }). React 19 ignores defaultProps on function components; it is still honoured on class components.

Type the props argument directly: function Button({ label }: ButtonProps). React.FC adds nothing you need, forces the return type, and since @types/react 18 no longer implies children, so teams declare children explicitly with React.ReactNode instead.

Blind spreading leaks unknown props into the DOM, lets callers silently override the component's own attributes depending on spread order, and hides the real API from readers and types. Control it by destructuring what you own, spreading the rest first, and merging className and handlers deliberately.

Strings and numbers render as text. Arrays render each element in order. Null, undefined, true and false render nothing at all. A plain object is not a valid child and React throws an error instead of rendering it.

A Fragment groups several children under one JSX parent while emitting no DOM node. A component can return multiple elements without an extra div that would distort CSS layout, break sibling and child selectors, invalidate HTML nesting, and add noise to the accessibility tree.

React renders a list by putting an array of elements in a JSX slot, normally items.map(item => <Row key={item.id} />). The key prop gives each element an identity independent of its position, so React can match it to the same item on the next render.

Capitalization tells the JSX compiler whether the tag is a value or a string. A capitalized tag compiles to a reference to the variable of that name; a lowercase tag compiles to the string "profile", so React renders a literal DOM tag and your component never runs.

JavaScript's && returns its left operand when that operand is falsy, so an empty cart makes the expression evaluate to the number 0. React skips null, undefined and booleans as children but renders numbers as text, so the 0 appears. Guard with cart.length > 0 instead.

children is an ordinary React prop that holds whatever JSX you nest between a component's opening and closing tags. Its value may be a string, a single element, an array of nodes, or undefined when nothing is nested.

Both older patterns reuse logic by adding components: HOCs stack into deep wrapper chains with silent prop collisions and hidden prop origins, and render props nest into callback pyramids. A hook is a plain function call whose result you name yourself, adding nothing to the tree.

A render prop is a prop whose value is a function that returns JSX. The component holding the state calls that function during its own render and passes its data in as arguments, so the caller controls the markup while the component keeps the behaviour.

The children prop is not reliably an array: a single nested node is passed through as itself, so array methods are undefined on it. React's Children helpers normalize every shape, but they treat a fragment as one node and never look inside it.

You write ConfirmDialog as a normal component that renders Dialog with preset props and its own nested content. React reuses code by composition only: containment passes content through children, and specialization wraps a general component in a more specific one.

Every render re-runs the component body, so the arrow expression evaluates again into a new function object. The allocation itself is cheap; the new identity only matters where something compares it, such as a memoized child or a dependency array.

The first passes the function so React can call it on click. The second calls it during render and passes its return value, usually undefined, so nothing happens on click and the side effect fires on every render.

React ignores a handler's return value entirely. Returning false only cancels defaults in inline HTML attributes and jQuery handlers. In React you call e.preventDefault(), and e.stopPropagation() separately if you also want to stop bubbling.

React passes a SyntheticEvent: a cross-browser wrapper that mirrors the DOM event interface (type, target, preventDefault, stopPropagation). The untouched browser event is always available on e.nativeEvent for anything React does not normalize.

The empty dependency array pins the handler to the first render, where count was 0, so every click computes 0 + 1. Fix it with the updater form setCount(c => c + 1), or by listing count as a dependency.

A controlled input's displayed value comes from React state through the value prop and changes only when onChange updates that state. An uncontrolled input keeps its value inside the DOM node, seeded once by defaultValue, and you read it on demand.

The browser's default form submission navigates, which reloads the page and throws away React state. Call event.preventDefault() as the first thing in the form's onSubmit handler, then read your state and send the request yourself.

The input's value prop started as undefined or null, so React treated the field as uncontrolled, and a later render passed a string, flipping it to controlled. Fix it by initialising the state to an empty string or writing value={x ?? ''}.

Browsers forbid script from setting which file is selected, so React cannot drive a file input from state — it is always uncontrolled. Read the selection from the node's files list or from FormData, and clear it by assigning an empty string to the node's value.

Read one or two fields through a ref, as inputRef.current.value. For a whole form, construct FormData from the form element in the submit handler and pull fields out by name, which needs no per-field wiring at all.

createPortal renders children into any DOM element you name while keeping them in the same React tree. A modal can therefore escape an ancestor's overflow clipping and z-index stacking context without moving the component that owns its state.

React propagates its events along the React element tree, not the document tree. Portal children are still React children of the component that rendered them, so onClick handlers on React ancestors run even though the DOM nodes live under document.body.

Node.contains walks the DOM, and the portalled menu is no longer a DOM descendant of the wrapper, so inside clicks now look outside. Fix it by testing containment against both the trigger element and the portalled content, each with its own ref.

Standardize on one configurable portal root that lives inside the app's theming wrapper, injected through context so consumers can retarget it. The costs are lost CSS inheritance and scoping, global stacking order between overlays, reading order and focus that no longer match the visual layout, and no server-rendered markup.