Hooks must be called at the top level of a function component or a custom hook. This ensures the order of every hook call stays the same across renders, which React relies on to correctly attach state and effects to each hook. Calling a hook inside a conditional, loop, or nested function would change that order from render to render. That breaks React’s internal bookkeeping and can lead to errors or unpredictable behavior. By placing all hook calls at the top level, you guarantee a stable sequence, and you use the hook results later in render logic or effects as needed. Within a component, you should call the hooks unconditionally in the function body, and then use conditional logic to decide what to render or how to react based on the hook values. Similarly, a custom hook follows the same rule: its hook calls must be at the top level of the function, not inside conditionals. Other options miss this requirement because hooks aren’t tied to lifecycle methods or class components, and they aren’t meant to be invoked after rendering. The correct approach is to call them at the top level of a function component or a custom hook.

useCallback is about keeping function references stable across renders. In React, a new function instance is created on every render, and if you pass that function down to a child component that relies on referential equality (for example a child wrapped with React.memo), the child can re-render unnecessarily just because the function prop changed. Wrapping the function with useCallback returns the same function instance unless its dependencies change, which helps prevent those extra re-renders and keeps performance where it matters. This doesn’t memoize a computed value—useMemo does that. It also isn’t about managing state or performing side effects; those are handled by useState and useEffect, respectively. So the correct idea is that useCallback memoizes stable function references to prevent unnecessary re-renders.

Rendering strategy in React is about where the initial HTML comes from. In client-side rendering, the browser runs the JavaScript bundle to build the UI, producing the markup in the DOM after the JS executes. In server-side rendering, the server generates the HTML for the initial page request and sends that HTML to the browser, so the user sees content right away without waiting for JavaScript to run. When the client loads the server-rendered page, React runs and hydrates that markup—reconciling the server HTML with the client-side code so event handlers and interactivity work correctly without replacing the entire DOM. Hydration is the key bridging step: it attaches the React components to the server-generated HTML, enabling interactivity while preserving the fast, content-first initial load that SSR provides. This explains why SSR often helps with perceived performance and SEO, while CSR can offer quicker interactivity after the bundle loads but may delay the initial visible content. The correct description matches this idea: the browser renders after JavaScript runs, while the server renders the initial HTML and the client hydrates it to become fully interactive. The other options either misstate what SSR or CSR do (for example, claiming CSS-only rendering, or tying SSR/CSR to features like Suspense or portals that aren’t their defining difference).

State is the place where a React component stores data it can change over time. When you update that data, React re-renders the component so the UI stays in sync with the current values. This is why the statement in the question matches how React components manage their own dynamic information: the component uses state to hold data it can alter, such as user input, toggles, counters, or form fields. Props, on the other hand, come from outside the component and are read-only inside it. They’re useful for configuring a component, but the component itself shouldn’t try to mutate them. If you need to reflect changes from outside, you’d typically lift state up or have the parent pass a new prop value, not mutate the prop directly. The idea that state should be mutated by external components is also not how React state works—the component owns its own state, and updates to it should go through the provided update mechanism (like setState or a setter from useState). Similarly, props are not meant to manage internal changes; they’re the inputs the component receives from its parent. In short, state is the right tool for internal, changeable data, which is why the statement is correct.