⚛️ React Component Architecture

What Is React?

React is a JavaScript library for building user interfaces, created at Facebook (now Meta) and open-sourced in 2013. It is especially strong for applications where the screen changes constantly in response to user actions or new data — dashboards, feeds, chat apps, editors. Instead of manually finding elements and updating them, you describe what the UI should look like for a given set of data, and React figures out the changes needed to make the real page match.

💡 The LEGO analogy. A React component is like a LEGO brick: small, self-contained, and reusable. You snap simple bricks together to make bigger structures, and those into a whole model. The same brick can appear many times, and swapping one out never disturbs the rest. That is exactly how you build a React app — from many small components composed into one tree.

Three ideas define React's philosophy, and everything else in this module builds on them:

• Declarative: you describe what the UI should be for the current data, not the step-by-step DOM instructions to get there. React handles the "how."
• Component-based: UIs are built from encapsulated components that manage their own markup and behavior, then composed together.
• Unidirectional data flow: data flows downward from parent to child, which makes an app far easier to trace and debug.

Components: The Building Blocks

A component is a JavaScript function that returns markup describing a piece of UI. That markup is written in JSX — an HTML-like syntax you'll study in depth in the next lesson. A component's name must start with a capital letter so React can tell your components apart from built-in HTML tags.

A modern function component

Since React 16.8 (2019), function components with Hooks are the standard. A function component is just a function that returns JSX:

// Greeting.jsx — the simplest useful component
function Greeting({ name }) {
  return <h1>Hello, {name}!</h1>;
}

export default Greeting;

The { name } in the parameter list destructures the incoming props object, so you can use name directly. Here are the common ways to write the same component — pick the one your team prefers and stay consistent:

// Function declaration
function Greeting({ name }) {
  return <h1>Hello, {name}!</h1>;
}

// Arrow function with an explicit return
const Greeting = ({ name }) => {
  return <h1>Hello, {name}!</h1>;
};

// Arrow function with an implicit return (concise)
const Greeting = ({ name }) => <h1>Hello, {name}!</h1>;

Adding interactivity with a Hook

Components can hold their own memory using the useState Hook. Here is the classic counter — a component that re-renders whenever its state changes:

import { useState } from 'react';

function Counter() {
  // useState returns [currentValue, updaterFunction]
  const [count, setCount] = useState(0);

  return (
    <div>
      <h2>Count: {count}</h2>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

export default Counter;

Props, State & Data Flow

Two kinds of data drive every component. Getting the distinction right is the single most important concept in this module.

Passing props looks just like setting HTML attributes, but the values can be any JavaScript expression inside { }:

function App() {
  return (
    <UserProfile
      name="Alice"
      role="Admin"
      isActive={true}
      loginCount={42}
    />
  );
}

function UserProfile({ name, role, isActive, loginCount }) {
  return (
    <div className="user-profile">
      <h2>{name}</h2>
      <p>Role: {role}</p>
      <p>Status: {isActive ? 'Active' : 'Inactive'}</p>
      <p>Logins: {loginCount}</p>
    </div>
  );
}

Unidirectional data flow

Data always travels one direction: down. A parent hands props to its children; children never reach up and mutate the parent directly. When a child needs to affect the parent, the parent passes down a callback function as a prop, and the child calls it — sending information back up through a controlled channel.

This is why React apps are predictable: to understand any piece of the screen, you trace props down from where the data lives. There is one source of truth, and it flows outward.

The Virtual DOM

Directly touching the real browser DOM is slow, and doing it by hand for every little change is error-prone. React's answer is the Virtual DOM: a lightweight JavaScript representation of what the UI should look like.

When state changes, React builds a fresh virtual tree, diffs it against the previous one (a process called reconciliation), and then makes only the minimal set of real DOM changes needed. You describe the destination; React computes the cheapest route.

💡 Analogy. Imagine editing a printed document. Rather than reprinting every page for one typo (updating the whole DOM), you mark just the changed line and reprint only that page. The Virtual DOM is React's markup of exactly which lines changed.

This is also why keys matter when rendering lists: a stable, unique key prop helps the diffing algorithm match items across renders so it can tell what was added, removed, or reordered. You'll see keys in action in the next lesson.

Composition Patterns

React favors composition over inheritance: you build complex UIs by nesting and combining simple components, not by extending classes. A few reusable patterns cover the vast majority of real code.

1. Basic composition

Split a page into named pieces, each responsible for one area:

function App() {
  return (
    <div className="app">
      <Header />
      <MainContent />
      <Footer />
    </div>
  );
}

2. The children prop

Any content you place between a component's opening and closing tags arrives as the special children prop. This is how you build flexible wrappers like cards, modals, and layouts:

function Card({ title, children }) {
  return (
    <div className="card">
      <div className="card-header"><h2>{title}</h2></div>
      <div className="card-body">{children}</div>
    </div>
  );
}

// The Card doesn't care what's inside — it just renders whatever you pass.
function ProfileCard() {
  return (
    <Card title="User Profile">
      <h3>Jane Doe</h3>
      <p>Frontend Developer</p>
      <button>Edit Profile</button>
    </Card>
  );
}

3. Specialized components

Configure a general component with fixed props to create purpose-built variants. The spread operator ({...props}) forwards any remaining props through:

function Button({ variant = 'primary', children, ...rest }) {
  return (
    <button className={`btn btn-${variant}`} {...rest}>
      {children}
    </button>
  );
}

const PrimaryButton  = (props) => <Button variant="primary" {...props} />;
const DangerButton   = (props) => <Button variant="danger" {...props} />;

Design systems formalize this further with Atomic Design — atoms (Button, Input) compose into molecules (SearchBar), then organisms (Header), templates, and pages. Airbnb, IBM's Carbon, and Material UI all use a hierarchy like this to keep large UIs consistent.

Organizing Components

As an app grows, a predictable folder structure keeps it navigable. A widely used convention groups components by role and colocates each component's related files:

src/
├── components/
│   ├── common/          # Reusable anywhere (Button, Card, Modal)
│   │   └── Button/
│   │       ├── Button.jsx
│   │       ├── Button.test.jsx
│   │       └── Button.module.css
│   ├── layout/          # Header, Footer, Sidebar
│   └── features/        # Feature-specific (UserProfile, Dashboard)
├── hooks/               # Custom reusable Hooks (useAuth, useFetch)
├── context/             # Context providers for shared state
├── pages/               # Top-level route components
└── utils/               # Plain helper functions

The payoff: components are easy to find, common and feature code stay separated, and each component travels with its test and styles. You do not need this much structure on day one — start simple and grow into it as the app earns the complexity.

Hands-on Exercise

const post = {
  title: 'Getting Started with React',
  author: 'Jane Smith',
  date: '2026-02-10',
  tags: ['React', 'JavaScript', 'Frontend'],
  comments: [
    { id: 1, author: 'John', text: 'Great intro!' },
    { id: 2, author: 'Alice', text: 'Very helpful, thanks.' }
  ]
};

function BlogPost({ post }) {
  return (
    <article>
      <PostHeader title={post.title} author={post.author} date={post.date} />
      <PostBody />
      <TagList tags={post.tags} />
      <CommentSection comments={post.comments} />
    </article>
  );
}

function PostHeader({ title, author, date }) {
  return (
    <header>
      <h1>{title}</h1>
      <p>By {author} · {date}</p>
    </header>
  );
}

function PostBody() {
  return <p>React makes it painless to build interactive UIs…</p>;
}

function TagList({ tags }) {
  return (
    <ul>
      {tags.map((tag) => <li key={tag}>{tag}</li>)}
    </ul>
  );
}

function CommentSection({ comments }) {
  const [count] = useState(comments.length);
  return (
    <section>
      <h2>{count} Comments</h2>
      {comments.map((c) => (
        <div key={c.id}><strong>{c.author}:</strong> {c.text}</div>
      ))}
    </section>
  );
}

Best Practices

Summary & Quiz

📚 Further Reading

• React docs — Your First Component
• React docs — Thinking in React
• React docs — Passing Props to a Component
• Atomic Design by Brad Frost

🚀 What's Next?

You now have the shape of a React app in your head: a tree of components exchanging props. Next we'll zoom into the syntax that makes those components readable — JSX — and go deep on how props actually work.