React is a JavaScript library for building user interfaces — not a full framework, and the difference is worth understanding before you write a line. It handles one thing: rendering views and keeping them in sync with your data. Routing, data fetching, state management beyond the component level — those are your problem to solve, with whatever tools fit the job. That constraint is a feature. It means React composes cleanly with the rest of your stack instead of imposing one.

The library was created at Facebook and has been open-source since 2013. Its longevity owes something to the fact that its core idea is genuinely simple: describe what your UI should look like for a given state, and let React figure out the DOM updates. When your data changes, React reconciles the virtual representation against the real DOM and updates only what needs updating. That makes UI behaviour predictable in a way that direct DOM manipulation rarely is — and predictable code is dramatically easier to debug.

Facebook and Instagram are the most visible early proof-of-concept, but React's adoption across the industry is broad enough now that the real question isn't whether to know it, but how to use it well.

01The practical mechanics

Keep components small. This is the single most repeated piece of React advice because it keeps being true. A component that does too much — fetches data, manages three separate state variables, conditionally renders four different layouts — is hard to test, hard to reason about, and hard to reuse. Split early. If a component's render output is growing, look for the natural seams and extract them. The rule of thumb: a component should be explainable in one sentence.

Props are your component's public interface. When you define a component, props are the attributes you pass in from the outside. They flow downward — parent to child — and a component should treat them as read-only. If a component needs to communicate up, it does so by calling a function passed as a prop, not by mutating shared data. Keeping data flow directional makes the mental model much cleaner.

jsx
function Greeting({ name, onDismiss }) {
  return (
    <div>
      <p>Hello, {name}</p>
      <button onClick={onDismiss}>Dismiss</button>
    </div>
  );
}

Keep state minimal. State — data that a component owns and can change — is where complexity lives. Every piece of state is a surface for bugs: it can be stale, inconsistent, or mutated in ways that are hard to trace. The discipline is to ask, for each thing you're tempted to put in state: does it actually need to live here? Can it be derived from props or from other state instead? The fewer state variables you maintain, the fewer moving parts you have to hold in your head at once.

Understand the component lifecycle — or its modern equivalent. The class-component lifecycle methods that older tutorials lean on heavily (componentDidMount, componentDidUpdate, componentWillUnmount, shouldComponentUpdate) are largely superseded by hooks for any code written since React 16.8. The useEffect hook covers the same ground — running side effects after render, subscribing and unsubscribing, syncing with external systems — with a model that composes better across a codebase. If you're learning React today, learn hooks first; the class API is worth knowing to read legacy code, not as a starting point.

Events are just props. There's nothing magical about event handling in React. You pass a function as a prop — onClick, onChange, onSubmit — and React wires it up. Keep handlers lean: compute, validate, update state or call a callback, and leave rendering to React.

Props are your component's public interface.

02The mindset that makes it click

React's learning curve is often described as shallow to start and steeper as you go — which is accurate. The JSX syntax takes an afternoon to get comfortable with. Basic component composition takes a day or two. What takes longer is internalising good patterns: lifting state to the right level, avoiding prop-drilling through sensible component design, knowing when to reach for useContext or an external state library versus keeping things local.

The ecosystem around React — Next.js for server-side and static rendering, Zustand or Redux for global state, React Query for server state — is large enough that you can waste a lot of time chasing libraries. The better use of that time is writing components, breaking them, reading the output, and building intuition for where the edges are. React rewards a bias toward simplicity: the smallest component that does the job, the least state that keeps it working, the most direct data flow you can maintain.

Related reading