Thinking in Components

React encourages you to build user interfaces as a tree of small components that describe what the screen should look like for a given state. Instead of manually changing the DOM step by step, you describe the UI and let React keep it in sync. Developers coming from imperative environments often start by thinking in terms of "when the button is clicked, find this element, change its class, and update its text." React pushes you toward a different model: state changes, and the UI is recalculated from that state.

This leads to a few important habits:

• Break a page into meaningful components.
• Pass data into components instead of letting them reach everywhere.
• Treat rendering as a function of state and props.
• Prefer describing outcomes over scripting UI mutations.

This way of thinking fits well with Atomic Design because the screen becomes a composition of smaller UI parts. It also aligns with DDD because components can reflect domain concepts such as Product, OrderSummary, or CustomerBadge instead of generic UI names.

When teaching beginners, it helps to stress that React is not "HTML in JavaScript." JSX is just a syntax that lets you describe UI structure close to the logic that drives it.