Frontend: React 18 Automatic Batching (Renders Per Update)

- React 17 and earlier: updates were batched only when called *inside* a React-attached event handler (e.g. an `onClick`). Updates called from `setTimeout`, native event listeners (`addEventListener`), or Promise callbacks each triggered their own re-render.

- React 18+: "automatic batching" - all state updates are batched, regardless of where they're called, as long as they happen in the same microtask. This makes `React.unstable_batchedUpdates(...)` mostly obsolete (still useful for explicit grouping across awaits).

Opting out: wrap an update in `flushSync(() => setX(...))` to force a synchronous render between updates - rarely needed, but matters for things like measuring DOM after a state change before the next update.

Why this matters in interviews: "your component re-renders 3x when this button is clicked" is a typical bug-hunt question. In React 18 it almost always means three separate microtasks (e.g. three awaited promises that each call setState). The fix is either to batch them with `Promise.all` or to consolidate state into a reducer call.

Concurrent-mode subtlety: `useTransition` and `useDeferredValue` let you mark some updates as low-priority, so they can be interrupted by higher-priority updates - the renderer may then "discard" an in-progress render. This isn't "batching" exactly but it's the same family of optimizations.