Introduction to Components

Components are the fundamental building blocks of React applications.

If you understand components deeply, concepts such as props, state, hooks, composition, reusable UI, and application architecture become much easier.

Learning Objectives

By the end of this lesson, you will understand:

1. What a React component is
2. Why React applications are built from components
3. Functional components
4. Component naming conventions
5. Returning JSX from components
6. Using components inside other components
7. Component composition
8. Reusability
9. Component responsibilities
10. Presentational vs container-style thinking
11. Component trees
12. Parent-child relationships
13. Component files
14. How React renders components
15. Common component mistakes
16. Best practices for designing components

What Is a Component?

A component is a reusable piece of UI.

For example, imagine a learning platform:

TechLearningPro
│
├── Header
├── Navigation
├── HeroSection
├── CourseList
│   ├── CourseCard
│   ├── CourseCard
│   └── CourseCard
├── Testimonials
└── Footer

Instead of building the entire page as one giant block of JSX, we divide it into meaningful pieces.

Each piece can become a component.

The Component Mental Model

Think of a component as:

Component
   │
   ├── Input
   │
   ▼
   Logic
   │
   ▼
   UI

For example:

CourseCard
   │
   ├── title
   ├── instructor
   ├── price
   │
   ▼
Rendered course card

The component receives information and produces UI.

Your First Component

A simple React component:

function Welcome() {
  return <h1>Welcome to React</h1>;
}

This is a functional component.

It has:

function
   ↓
Component name
   ↓
()
   ↓
JSX

Calling a Component

Components are used like HTML elements.

function Welcome() {
  return <h1>Welcome to React</h1>;
}

function App() {
  return (
    <div>
      <Welcome />
    </div>
  );
}

Here:

App
 ↓
Welcome
 ↓
<h1>

<Welcome /> tells React to render the Welcome component.

Components Look Like HTML

This:

<Welcome />

looks like an HTML element.

But it isn't a built-in HTML element.

It is a React component.

Compare:

<h1>Hello</h1>

with:

<Welcome />

The first is a browser HTML element.

The second represents a React component.

Component Naming

React components should normally use PascalCase.

Correct:

function CourseCard() {
  return <div>Course</div>;
}

Correct:

function UserProfile() {
  return <div>Profile</div>;
}

Avoid:

function courseCard() {
  // ...
}

Use:

CourseCard
UserProfile
NavigationBar
LoginForm
ProductDetails

PascalCase makes components easy to distinguish from HTML elements.

Why PascalCase?

React uses capitalization to distinguish components from intrinsic HTML elements.

For example:

<div />

means:

HTML div element

Whereas:

<CourseCard />

means:

React component

This distinction is fundamental.

A Component Must Return UI

For example:

function Header() {
  return (
    <header>
      <h1>TechLearningPro</h1>
    </header>
  );
}

The return value describes what should appear in the UI.

Components Can Return More Than One Element

This is valid:

function Profile() {
  return (
    <div>
      <h2>Jagannath</h2>
      <p>React Developer</p>
    </div>
  );
}

The <div> acts as the parent element.

Fragments

You don't always want to add an unnecessary <div>.

React provides fragments:

function Profile() {
  return (
    <>
      <h2>Jagannath</h2>
      <p>React Developer</p>
    </>
  );
}

The empty:

<>
</>

is a React Fragment.

It allows multiple elements without introducing another DOM element.

Components Can Contain Components

Components become powerful when we combine them.

function Header() {
  return <header>Header</header>;
}

function Footer() {
  return <footer>Footer</footer>;
}

function App() {
  return (
    <>
      <Header />

      <main>
        <h1>Home</h1>
      </main>

      <Footer />
    </>
  );
}

The structure becomes:

App
│
├── Header
│
├── main
│
└── Footer

Component Tree

React applications form a component tree.

Example:

App
│
├── Header
│   ├── Logo
│   └── Navigation
│
├── Main
│   ├── Hero
│   └── CourseList
│       ├── CourseCard
│       ├── CourseCard
│       └── CourseCard
│
└── Footer

This tree is one of the most important concepts in React.

Parent and Child Components

If one component renders another component, we can describe the relationship as:

Parent
  ↓
Child

For example:

function Header() {
  return <h1>My Website</h1>;
}

function App() {
  return (
    <div>
      <Header />
    </div>
  );
}

Here:

App
 ↓
Header

App is the parent.

Header is the child.

Why Components?

Imagine building an e-commerce application without components.

You might have one huge file containing:

Header
Navigation
Product
Cart
Checkout
Footer
Login
Profile
Orders

This becomes difficult to:

Understand
Maintain
Test
Reuse
Modify

Components allow us to divide the application into manageable pieces.

Reusability

Suppose we have:

function CourseCard() {
  return (
    <div>
      <h2>React Course</h2>
      <p>Learn React</p>
    </div>
  );
}

We can render it multiple times:

function App() {
  return (
    <>
      <CourseCard />
      <CourseCard />
      <CourseCard />
    </>
  );
}

The same component is reused.

Later we'll learn how to make each card display different information using props.

Components Are Like Templates

Think of:

<CourseCard />

as a reusable UI template.

For example:

CourseCard
┌─────────────────────┐
│ Course Title        │
│ Instructor           │
│ Price                │
│ [Enroll]             │
└─────────────────────┘

You can create many instances:

CourseCard
CourseCard
CourseCard
CourseCard

without duplicating the component's structure.

Components Can Accept Data

Components become significantly more useful when they receive data.

For example:

function CourseCard({ title }) {
  return <h2>{title}</h2>;
}

Then:

<CourseCard title="React" />
<CourseCard title="Java" />
<CourseCard title="Spring Boot" />

Result:

React
Java
Spring Boot

The title is a prop.

We'll study props in detail in the next lessons.

Component Inputs

You can think of components similarly to functions.

A normal JavaScript function:

function add(a, b) {
  return a + b;
}

has:

Input → Function → Output

A React component:

function Greeting({ name }) {
  return <h1>Hello {name}</h1>;
}

has:

Props → Component → UI

This is a very useful mental model.

Component Logic

Components can contain JavaScript logic.

For example:

function UserStatus({ loggedIn }) {
  if (loggedIn) {
    return <p>Welcome back!</p>;
  }

  return <p>Please log in.</p>;
}

The component decides what UI to render based on its inputs.

Components Can Have State

Components can also maintain their own state.

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      {count}
    </button>
  );
}

Now the component has:

State
 ↓
Rendering
 ↓
User interaction
 ↓
State update
 ↓
Re-render

We'll study state separately.

Components Are Not Just Visual Boxes

A component can encapsulate:

UI
+
Behavior
+
State
+
Events
+
Business presentation logic

For example:

ShoppingCart
│
├── Cart UI
├── Remove item
├── Update quantity
├── Calculate subtotal
└── Checkout button

However, good architecture avoids putting everything into one component.

Single Responsibility

A component should generally have a clear responsibility.

Instead of:

UserDashboard
 ├── Login
 ├── Payments
 ├── Course Search
 ├── Notifications
 ├── Profile
 ├── Reports
 └── Settings

you might break it into:

Dashboard
├── DashboardHeader
├── CourseSummary
├── PaymentSummary
├── Notifications
└── RecentActivity

Each component has a clearer responsibility.

Component Size

There is no universal rule such as:

Every component must have exactly 50 lines.

Don't split components purely based on line count.

Instead look for:

Repeated UI
Independent responsibility
Complex logic
Independent state
Reusable behavior
Meaningful conceptual boundary

These are stronger reasons to create a component.

Bad Component Design

For example:

function Everything() {
  // login logic

  // payment logic

  // course logic

  // notification logic

  // profile logic

  // 1000 lines of JSX

  return (
    // enormous UI
  );
}

This is difficult to maintain.

Better Component Design

Instead:

function Dashboard() {
  return (
    <>
      <DashboardHeader />
      <CourseSummary />
      <PaymentSummary />
      <Notifications />
      <RecentActivity />
    </>
  );
}

Now the application structure communicates its intent.

Component Composition

One of React's most important design principles is composition.

Instead of creating giant components with many configuration options, build smaller components and combine them.

Small Components
      ↓
Composition
      ↓
Larger UI

Example:

function Page() {
  return (
    <Layout>
      <Header />
      <CourseList />
      <Footer />
    </Layout>
  );
}

This is composition.

Composition vs Duplication

Bad approach:

function StudentPage() {
  // huge UI
}

function TeacherPage() {
  // duplicate huge UI
}

Better:

Shared Layout
    │
    ├── Header
    ├── Sidebar
    └── Content

Then different pages can compose the shared components.

Layout Components

A common component pattern is a layout.

function Layout({ children }) {
  return (
    <>
      <Header />

      <main>
        {children}
      </main>

      <Footer />
    </>
  );
}

Then:

function App() {
  return (
    <Layout>
      <Home />
    </Layout>
  );
}

Here children represents the content placed inside the layout.

We'll study children in depth later.

Components and Files

A common project structure is:

src/
│
├── components/
│   ├── Header.jsx
│   ├── Footer.jsx
│   ├── CourseCard.jsx
│   └── Button.jsx
│
├── pages/
│   ├── Home.jsx
│   ├── Courses.jsx
│   └── Profile.jsx
│
├── App.jsx
└── main.jsx

Each component can have its own file.

One Component Per File

A common convention is:

CourseCard.jsx
     ↓
CourseCard component

Example:

function CourseCard() {
  return (
    <article>
      <h2>React</h2>
    </article>
  );
}

export default CourseCard;

Then import it:

import CourseCard from "./components/CourseCard";

And use it:

<CourseCard />

Exporting Components

Components need to be exported if another module should import them.

Default export

export default CourseCard;

Then:

import CourseCard from "./CourseCard";

Named export

export function CourseCard() {
  return <div>React</div>;
}

Then:

import { CourseCard } from "./CourseCard";

Both approaches are valid.

Component Modules

A component file is simply a JavaScript module containing React code.

For example:

CourseCard.jsx
      │
      ├── imports
      ├── component
      ├── styles
      └── export

This keeps application code organized.

How React Renders Components

Suppose:

function App() {
  return <Welcome />;
}

function Welcome() {
  return <h1>Hello</h1>;
}

Conceptually:

App
 ↓
Welcome
 ↓
<h1>Hello</h1>
 ↓
DOM

React builds and manages the UI based on the component tree.

Component Re-rendering

When relevant state or props change, React may render a component again.

For example:

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button
      onClick={() => setCount(count + 1)}
    >
      {count}
    </button>
  );
}

Clicking the button changes state.

Conceptually:

count = 0
     ↓
click
     ↓
count = 1
     ↓
React renders updated UI

A re-render does not mean React blindly recreates the entire browser DOM.

React determines what needs to change.

Component Identity

Consider:

<CourseCard />

React treats the component as a particular component type in the tree.

This becomes especially important when dealing with:

State
Keys
Lists
Conditional rendering
Component replacement

We'll explore these concepts later.

Components and Events

Components can respond to user actions.

function LoginButton() {
  function handleLogin() {
    console.log("Login clicked");
  }

  return (
    <button onClick={handleLogin}>
      Login
    </button>
  );
}

The component contains:

UI
+
Event handler

Components and Conditional Rendering

Components can render different UI depending on conditions.

function Status({ isOnline }) {
  return (
    <div>
      {isOnline ? "Online" : "Offline"}
    </div>
  );
}

This is one of the most common React patterns.

Components and Lists

Components are frequently used with arrays.

const courses = [
  "React",
  "Java",
  "Spring Boot"
];

Then:

function CourseList() {
  return (
    <ul>
      {courses.map(course => (
        <li key={course}>
          {course}
        </li>
      ))}
    </ul>
  );
}

Later we'll learn why key is important.

Components Should Be Predictable

A well-designed component should ideally behave predictably:

Same inputs
     ↓
Predictable output

For example:

<CourseCard title="React" />

should consistently represent the React course.

Avoid components that secretly depend on many unrelated global values.

Avoid Unnecessary Global Dependencies

Prefer:

function CourseCard({ title }) {
  return <h2>{title}</h2>;
}

over a component that secretly retrieves unrelated information from many places.

Explicit inputs make components:

Easier to understand
Easier to test
Easier to reuse
Easier to maintain

Presentational Components

A component may primarily focus on UI.

Example:

function CourseCard({ title, price }) {
  return (
    <article>
      <h2>{title}</h2>
      <p>₹{price}</p>
    </article>
  );
}

This component mainly presents data.

Container-Style Components

Another component may coordinate data and behavior.

For example:

function CourseList() {
  // fetch data
  // manage loading
  // handle errors

  return (
    <CourseGrid />
  );
}

Historically, React developers often called these container components.

Modern React architectures don't require a strict container/presentational split, but the underlying idea remains useful:

Separate responsibilities when complexity requires it.

Component Hierarchy Example

Consider an e-commerce page:

ProductPage
│
├── Header
│
├── ProductDetails
│   ├── ProductImage
│   ├── ProductInfo
│   ├── Price
│   ├── QuantitySelector
│   └── AddToCartButton
│
├── Reviews
│   ├── Review
│   ├── Review
│   └── Review
│
└── Footer

This is a component hierarchy.

Component Boundaries

A good component boundary often exists where you have:

A clear concept

ProductCard

Repeated UI

Button

Independent state

SearchBox

Complex behavior

CheckoutForm

Reusable layout

Modal

These are natural component boundaries.

Don't Over-Componentize

There is also a mistake on the opposite side.

For example:

function LetterH() {
  return <span>H</span>;
}

Creating a component for every tiny piece of static markup is usually unnecessary.

Bad:

Page
 └── Section
      └── Div
           └── Span
                └── Text

Components should communicate meaningful concepts.

Good Componentization

Instead:

Page
├── Header
├── SearchBar
├── CourseList
│   └── CourseCard
└── Footer

These names communicate the application's purpose.

Components and Reuse

A reusable component should avoid assumptions that prevent reuse.

Instead of:

function BlueButton() {
  return (
    <button style={{ color: "blue" }}>
      Save
    </button>
  );
}

a reusable button might eventually support:

<Button variant="primary">
  Save
</Button>

This is where component APIs become important.

Component API

A component's API is essentially the way other components interact with it.

For example:

<Button
  variant="primary"
  disabled={false}
  onClick={handleSave}
>
  Save
</Button>

The component API includes:

variant
disabled
onClick
children

Good component APIs are:

Clear
Predictable
Minimal
Flexible

Component Coupling

Avoid tightly coupling a reusable component to a specific application.

For example:

function Button() {
  // directly calls a specific payment API
}

That makes it no longer a generic button.

Instead:

<Button onClick={handlePayment}>
  Pay
</Button>

The parent owns the application-specific behavior.

Parent Controls, Child Displays

A useful pattern is:

Parent
 │
 ├── owns data/behavior
 │
 ▼
Child
 │
 └── receives what it needs

For example:

function CoursePage() {
  const course = {
    title: "React"
  };

  return (
    <CourseCard
      title={course.title}
    />
  );
}

This creates a clean relationship.

Component Composition Is a Core React Skill

Rather than thinking:

How do I make one giant component?

Think:

How can I compose several focused components?

For example:

function App() {
  return (
    <Layout>
      <Header />
      <Sidebar />
      <MainContent />
    </Layout>
  );
}

This is one of the patterns you'll use constantly.

A Real-World Example

Imagine a course card:

function CourseCard() {
  return (
    <article>
      <img
        src="/react.png"
        alt="React"
      />

      <h2>React Fundamentals</h2>

      <p>
        Learn modern React.
      </p>

      <button>
        Enroll
      </button>
    </article>
  );
}

It has:

Image
Title
Description
Button

Later we can extract:

CourseImage
CourseTitle
CourseDescription
EnrollButton

But we shouldn't necessarily do that immediately.

The correct abstraction depends on reuse and complexity.

Refactor When There Is a Reason

Don't start with:

100 tiny components

and don't create:

1 giant component

A practical approach:

Start simple
    ↓
Identify repetition
    ↓
Identify complexity
    ↓
Extract meaningful components
    ↓
Reuse them

This is often more effective.

Component Best Practices

1. Use PascalCase

function CourseCard() {}

2. Give components clear responsibilities

CourseCard
LoginForm
Navigation

3. Prefer reusable components where reuse exists

4. Keep APIs simple

5. Avoid unnecessary global dependencies

6. Compose components

7. Don't over-componentize

8. Keep business logic separate when it becomes complex

9. Make data dependencies explicit

10. Use meaningful names

Common Beginner Mistakes

Mistake 1 — Lowercase component names

function courseCard() {}

Prefer:

function CourseCard() {}

Mistake 2 — Forgetting to return JSX

function Header() {
  <h1>Hello</h1>;
}

This doesn't return the JSX.

Correct:

function Header() {
  return <h1>Hello</h1>;
}

Mistake 3 — Treating components as HTML

Incorrect:

<CourseCard title="React"></CourseCard>

This can technically work, but self-closing syntax is usually cleaner for components with no children:

<CourseCard title="React" />

Mistake 4 — Giant components

App.jsx
2000 lines

Break meaningful sections into components.

Mistake 5 — Too many tiny components

Don't extract every <div> into a component without a meaningful reason.

Component Thinking

When looking at a UI design, start identifying components.

For example:

┌──────────────────────────────┐
│ Logo     Search     Profile  │
├──────────────────────────────┤
│                              │
│       Welcome to React       │
│                              │
├───────────┬──────────────────┤
│           │                  │
│ Sidebar   │  Course Card     │
│           │  Course Card     │
│           │  Course Card     │
│           │                  │
└───────────┴──────────────────┘

You might identify:

Header
Logo
SearchBar
ProfileMenu
Hero
Sidebar
CourseList
CourseCard

This is component thinking.

Component Tree Exercise

Consider:

function App() {
  return (
    <>
      <Header />
      <Main />
      <Footer />
    </>
  );
}

function Main() {
  return (
    <main>
      <Hero />
      <CourseList />
    </main>
  );
}

The component tree is:

App
├── Header
├── Main
│   ├── Hero
│   └── CourseList
└── Footer

Being able to visualize this tree is extremely important.

Components and the DOM

Don't confuse:

Component Tree

with:

DOM Tree

For example:

function Header() {
  return (
    <header>
      <h1>Hello</h1>
    </header>
  );
}

The component is:

Header

The resulting DOM includes:

header
└── h1

A component is a React abstraction.

It isn't itself a DOM element.

Component as a Unit of Organization

Components help organize:

Code
UI
Behavior
State
Testing
Ownership

This is why they are foundational to React architecture.

A More Advanced Mental Model

Think of a component as:

             Component
                 │
       ┌─────────┼─────────┐
       ▼         ▼         ▼
     Props      State    Context
       │         │         │
       └─────────┼─────────┘
                 ▼
               Logic
                 │
                 ▼
                JSX
                 │
                 ▼
               React
                 │
                 ▼
                 UI

Later lessons will explore each of these inputs in depth.

Interview questions & answers

Practical Example

Let's build a small application.

Header

function Header() {
  return (
    <header>
      <h1>TechLearningPro</h1>
    </header>
  );
}

CourseCard

function CourseCard() {
  return (
    <article>
      <h2>React Fundamentals</h2>
      <p>Learn React step by step.</p>
      <button>Enroll</button>
    </article>
  );
}

CourseList

function CourseList() {
  return (
    <section>
      <CourseCard />
      <CourseCard />
      <CourseCard />
    </section>
  );
}

App

function App() {
  return (
    <>
      <Header />

      <main>
        <h2>Available Courses</h2>

        <CourseList />
      </main>
    </>
  );
}

Component tree:

App
├── Header
└── main
    └── CourseList
        ├── CourseCard
        ├── CourseCard
        └── CourseCard

This is the foundation of React development.

What We Will Learn Next

Now that you understand what components are, the natural progression is:

Introduction to Components
          ↓
Creating Components
          ↓
Component Naming
          ↓
Component Composition
          ↓
Props
          ↓
Passing Data
          ↓
Component Children
          ↓
Reusable Components
          ↓
Component State

The next important concept is Props because props are how components receive data from their parents.