It has a corresponding element created in the DOM and is connected to that.
They are typically written as functions.
They are pure functions, meaning they always return the same output for the same input (props).
They are primarily used for rendering UI and do not handle logic related to state or lifecycle methods.
They are easier to test and maintain because of their simplicity.
They are typically written as classes (before React 16.8) or as functional components using hooks (after React 16.8).
They can manage state using this.state (in class components) or the useState hook (in functional components).
They can handle lifecycle methods (e.g., componentDidMount, componentDidUpdate) or use the useEffect hook in functional components.
They are used when the component needs to maintain or update data over time.
You need to display a list of product names that never change after the initial fetch. Would you implement the list item as a stateless or stateful component, and why?
If a button component only triggers a callback passed from its parent, how would you structure it in terms of state?
While adding a search filter to a dashboard, the filter component started re‑rendering the entire page on every keystroke. Walk me through how you would diagnose whether the component should be stateless or stateful.
You inherited a form component that mixes local input state with props from Redux. Explain how you would refactor it to improve clarity and testability.
Our UI library needs to support both server‑side rendering and client‑side hydration. How would you decide which components stay stateless and which hold state to minimize hydration mismatches?
When scaling a real‑time collaborative editor, what trade‑offs arise from keeping component state locally versus lifting it to a global store?
We are migrating a legacy codebase that heavily uses class‑based stateful components to a modern hook‑driven architecture. Outline a migration strategy that balances risk, performance, and team productivity.
Across multiple teams, some services render the same UI widget but with different data lifecycles. How would you design a reusable component hierarchy that cleanly separates stateless presentation from stateful data handling?