Introduction to React

Learning Objectives

By the end of this lesson, you will be able to:

1. Explain what React is in practical and technical terms.
2. Understand why React was created.
3. Explain the problems React solves in frontend development.
4. Understand declarative UI development.
5. Understand React's component-based architecture.
6. Explain how React applications represent UI as a component tree.
7. Understand the relationship between state and UI.
8. Understand React's rendering model at a high level.
9. Understand the role of JSX.
10. Understand React and the browser DOM.
11. Distinguish React from React DOM and React frameworks.
12. Understand React's evolution from its early architecture to modern React.
13. Understand where React fits in an enterprise application.
14. Identify common misconceptions about React.
15. Explain React confidently in technical interviews.

Introduction

Let's begin with a practical problem.

Suppose TechLearningPro starts as a simple website.

You have:

Home
Courses
Tutorials
Blog
About
Contact

Initially, plain HTML and CSS are enough.

Then the application grows.

Now you need:

• login
• registration
• course search
• filters
• user profiles
• course progress
• shopping cart
• payments
• notifications
• dashboards
• personalized recommendations
• real-time updates

Suddenly, the frontend is no longer just a collection of pages.

It becomes an application.

And applications have state.

For example:

User
 │
 ├── Logged in?
 ├── Name
 ├── Role
 └── Permissions
Course
 │
 ├── Title
 ├── Price
 ├── Progress
 └── Completion status

Now imagine that one state change affects several parts of the screen.

A user completes a lesson:

Lesson Completed
       │
       ├── Progress bar changes
       ├── Course status changes
       ├── Dashboard changes
       ├── Certificate becomes available
       └── Notification appears

The central frontend engineering problem becomes:

How do we keep the user interface synchronized with changing application state without turning the application into a collection of difficult-to-maintain DOM manipulation code?

React was created to address this class of problems.

What Is React?

React is a JavaScript library for building user interfaces from reusable components.

That definition is accurate, but for an engineer, it isn't enough.

A better mental model is:

React provides a declarative programming model for describing user interfaces as a function of application state.

Conceptually:

UI = f(State)

For example:

function CourseStatus({ completed }: { completed: boolean }) {
  return completed
    ? <span>Completed</span>
    : <span>In Progress</span>;
}

The component doesn't manually tell the browser:

Find element
        ↓
Change text
        ↓
Change CSS
        ↓
Update icon

Instead, it describes:

If completed
    ↓
Show "Completed"
Otherwise
    ↓
Show "In Progress"

React handles the rendering process.

This is one of the most important ideas in React.

Why Was React Created?

To understand React properly, don't start with:

React has JSX and hooks.

Start with:

What problem was React trying to solve?

Modern web applications became increasingly interactive.

A page could contain:

Navigation
Search
Forms
Tables
Notifications
Dialogs
Charts
Menus
User profiles
Real-time information

And all of these could depend on changing data.

Traditional JavaScript could certainly build these applications.

The problem wasn't:

JavaScript cannot build complex UIs.

It can.

The problem was managing complexity.

Consider an application with:

10 components
50 interactions
100 pieces of UI state
20 API operations

Manually maintaining relationships between data and DOM elements becomes increasingly difficult.

React introduced a different model:

Application State
       │
       ▼
React Components
       │
       ▼
UI

When state changes:

State Change
     │
     ▼
React Render
     │
     ▼
Determine UI Changes
     │
     ▼
Commit Changes
     │
     ▼
Browser

This provides a much more structured way of thinking about UI.

Imperative vs Declarative UI

This distinction is fundamental.

Imperative Programming

Imperative code tells the system how to perform an operation.

For example:

const button = document.querySelector("#login");
button.textContent = "Logout";
button.classList.add("logged-in");

You're explicitly instructing the browser what to change.

The mental model is:

Find element
   ↓
Modify element
   ↓
Modify another element
   ↓
Modify another element

Declarative Programming

React encourages a declarative model.

You describe the desired result:

function LoginButton({ loggedIn }: { loggedIn: boolean }) {
  return (
    <button>
      {loggedIn ? "Logout" : "Login"}
    </button>
  );
}

The logic is essentially:

loggedIn = true
      ↓
    Logout
loggedIn = false
      ↓
     Login

The component describes the UI.

React manages the rendering process.

This doesn't mean React magically eliminates all complexity.

It means the complexity is organized around a different abstraction.

The Component Model

The second major idea behind React is components.

A component represents a reusable part of the user interface.

For example:

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

Another:

function CourseCard() {
  return (
    <article>
      <h2>React Mastery</h2>
      <p>Advanced React course</p>
    </article>
  );
}

Then:

function HomePage() {
  return (
    <>
      <Header />
      <CourseCard />
      <CourseCard />
    </>
  );
}

The UI becomes composable.

Component Composition

Components can contain other components.

Consider:

Application
     │
     ▼
HomePage
     │
 ┌───┼──────────────┐
 ▼   ▼              ▼
Header Hero      CourseList
                  │
             ┌────┼────┐
             ▼    ▼    ▼
          Course Course Course
           Card   Card   Card

This is composition.

Instead of creating one enormous UI structure, we create smaller building blocks.

This provides:

• reuse
• separation of concerns
• easier testing
• easier maintenance
• clearer ownership
• better team collaboration

React as a Component Tree

A React application can be visualized as a tree.

For TechLearningPro:

App
│
├── Header
│   ├── Logo
│   ├── Navigation
│   └── UserMenu
│
├── MainContent
│   ├── Hero
│   ├── CourseSearch
│   └── CourseList
│       ├── CourseCard
│       ├── CourseCard
│       └── CourseCard
│
└── Footer

This tree isn't just a visual representation.

It becomes important for understanding:

• data flow
• state ownership
• rendering
• performance
• context
• debugging
• component architecture

The React Data Flow

React applications traditionally emphasize one-way data flow.

Consider:

Parent
  │
  │ props
  ▼
Child

For example:

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

The parent provides:

<CourseCard title="React Mastery" />

So:

Parent
   │
   │ title
   ▼
CourseCard
   │
   ▼
UI

This makes data relationships easier to reason about.

State and UI

Now introduce state.

Imagine a course page.

The user clicks:

[ Mark Complete ]

The state changes:

completed = false
       │
       ▼
User clicks button
       │
       ▼
completed = true
       │
       ▼
React renders
       │
       ▼
UI reflects new state

The component could conceptually be:

function LessonStatus() {
  const [completed, setCompleted] = useState(false);
  return (
    <button onClick={() => setCompleted(true)}>
      {completed ? "Completed" : "Mark Complete"}
    </button>
  );
}

Notice what we are not doing.

We aren't manually searching the DOM and changing the button text.

We change state.

The UI follows the state.

That is the React mental model.

React Rendering

A simplified React rendering flow is:

Initial Application
       │
       ▼
React Root
       │
       ▼
Component Tree
       │
       ▼
Render
       │
       ▼
Commit
       │
       ▼
Browser DOM

Later, when something changes:

User Interaction
       │
       ▼
State Update
       │
       ▼
React Schedules Work
       │
       ▼
Render
       │
       ▼
Reconciliation
       │
       ▼
Commit
       │
       ▼
DOM

The important point is:

Rendering and DOM mutation are not the same thing.

A React component can render without every DOM element being recreated.

This distinction becomes critical when studying performance.

What Is JSX?

React code frequently looks like:

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

The HTML-like syntax is called JSX.

JSX makes it easier to describe UI structures alongside JavaScript logic.

For example:

function CourseCard() {
  const title = "React Mastery";
  return (
    <article>
      <h2>{title}</h2>
      <button>Start Learning</button>
    </article>
  );
}

JSX is not HTML.

It is syntax that is transformed into JavaScript representation that React can use.

We'll explore JSX deeply in a dedicated lesson.

React and the Browser DOM

The browser fundamentally works with the DOM.

React provides an abstraction for describing UI.

A simplified architecture is:

React Components
       │
       ▼
React Rendering System
       │
       ▼
React DOM
       │
       ▼
Browser DOM
       │
       ▼
Screen

This is why the distinction between:

React

and:

React DOM

matters.

React itself provides the core component and rendering model.

React DOM provides the browser DOM integration.

React Is Not the Browser

This sounds obvious, but it matters architecturally.

React does not replace:

• HTML
• CSS
• JavaScript
• browser APIs
• HTTP
• browser storage
• accessibility standards

Instead:

Browser Platform
       │
       ├── HTML
       ├── CSS
       ├── JavaScript
       ├── DOM
       └── Web APIs
              │
              ▼
            React

React works with the web platform.

A strong React developer should understand the browser itself.

React Ecosystem

React is not an isolated technology.

A production application might use:

React
 │
 ├── React DOM
 │
 ├── React Router
 │
 ├── TanStack Query
 │
 ├── Redux Toolkit
 │
 ├── React Hook Form
 │
 ├── Zod
 │
 ├── Testing Library
 │
 ├── Vitest
 │
 ├── Playwright
 │
 └── Next.js

But these technologies do different jobs.

For example:

A common beginner mistake is to treat the entire ecosystem as "React."

It isn't.

React vs Next.js

This distinction is especially important.

React

Provides the UI programming model.

Components
Hooks
State
Rendering

Next.js

Provides a broader application framework around React.

Depending on the version and configuration, it can provide:

Routing
Server rendering
Static generation
Server components
Server-side capabilities
Caching
Deployment-oriented features

Therefore:

React
   │
   ├── Can be used directly
   │
   └── Can be used inside frameworks
           │
           └── Next.js

You should never say:

React is Next.js.

A better interview answer is:

React is the UI library, while Next.js is a framework built around React that provides additional application-level capabilities.

React's Evolution

React was introduced publicly by Facebook in 2013.

Its evolution can be broadly understood as:

Early React
    │
    ▼
Component-based UI
    │
    ▼
JSX
    │
    ▼
Virtual DOM / reconciliation model
    │
    ▼
Hooks
    │
    ▼
Concurrent rendering capabilities
    │
    ▼
React 18
    │
    ▼
React 19
    │
    ▼
Modern React 19.x

This evolution matters because many tutorials still teach older React patterns.

For example, older React applications frequently use:

Class Components
Lifecycle Methods
Create React App

Modern React development generally emphasizes:

Functional Components
Hooks
Modern tooling
Framework-based development where appropriate

The official React documentation currently lists React 19.2 as the latest stable React release.

React 19 and Modern React

Modern React goes beyond the traditional explanation:

React = components + Virtual DOM.

React 19 introduced a number of improvements around actions, forms, and asynchronous UI workflows.

For example, modern React provides APIs such as:

useActionState
useFormStatus
useOptimistic

These are particularly useful when working with modern form and asynchronous interaction patterns.

React 19.2 further introduced capabilities including:

<Activity />
useEffectEvent
cacheSignal
Partial Pre-rendering
Performance tracks

These features demonstrate an important point:

React continues to evolve beyond its original client-side rendering model.

However, version-specific features should always be checked against the React version used by the application.

React Is Declarative, Not Magical

One misconception is:

React automatically handles everything.

It doesn't.

You still have to make architectural decisions.

For example:

Where should state live?
        │
        ▼
Which API should provide data?
        │
        ▼
How should authentication work?
        │
        ▼
How should permissions work?
        │
        ▼
How should errors be handled?
        │
        ▼
How should the application be tested?

React gives you powerful primitives.

It doesn't automatically create a good architecture.

Real-World TechLearningPro Architecture

Let's imagine TechLearningPro as a production React platform.

                         Browser
                            │
                            ▼
                     React Application
                            │
             ┌──────────────┼──────────────┐
             │              │              │
             ▼              ▼              ▼
          Courses         Learning       Profile
             │              │              │
             └──────────────┼──────────────┘
                            ▼
                       Application
                          Logic
                            │
              ┌─────────────┴─────────────┐
              ▼                           ▼
        Client State                 Server State
              │                           │
              └─────────────┬─────────────┘
                            ▼
                        API Layer
                            │
                            ▼
                      API Gateway
                            │
            ┌───────────────┼────────────────┐
            ▼               ▼                ▼
       Course Service   User Service    Payment Service

Here React is responsible primarily for the user interface and client-side interaction model.

The backend remains responsible for:

• business rules
• authorization
• data persistence
• payment processing
• domain logic

This separation is fundamental to good architecture.

React in Enterprise Development

At enterprise scale, React becomes more than writing components.

You need to consider:

Architecture

Feature boundaries
Dependency boundaries
Shared libraries
Design systems

Performance

Bundle size
Rendering
Network requests
Large lists
Caching

Security

Authentication
Authorization
XSS
CSRF
CSP
Token handling

Quality

Unit tests
Integration tests
E2E tests
Accessibility
Code review
Static analysis

Operations

Logging
Monitoring
Error tracking
Deployment
CI/CD
Feature flags

Therefore, learning React professionally means learning the ecosystem around the component model.

Performance Perspective

A beginner often thinks:

React is fast.

That isn't a sufficient engineering statement.

React can enable efficient UI updates, but poorly designed React applications can still be slow.

For example:

Large component tree
       +
Poor state placement
       +
Huge JavaScript bundle
       +
Large API payload
       +
Expensive calculations
       +
Large unvirtualized list

can produce a slow application.

Performance engineering should follow:

Measure
   ↓
Identify bottleneck
   ↓
Understand cause
   ↓
Optimize
   ↓
Measure again

Not:

Problem
 ↓
Add useMemo()

That distinction will become important later.

Security Perspective

React doesn't eliminate security risks.

For example:

{isAdmin && <DeleteButton />}

is useful for controlling what appears in the UI.

But it is not authorization.

A malicious user could call:

DELETE /api/users/123

directly.

Therefore:

Frontend permission check
          ≠
Backend authorization

The backend must enforce authorization.

Similarly, developers must understand:

• XSS
• secure authentication
• token handling
• cookies
• CORS
• CSRF
• CSP
• dependency vulnerabilities

These topics will be covered later in the course.

Accessibility Perspective

A professional React component should also be accessible.

Prefer:

<button onClick={save}>
  Save
</button>

over:

<div onClick={save}>
  Save
</div>

The semantic button provides better browser behavior and accessibility support.

Important areas include:

Semantic HTML
      ↓
Keyboard navigation
      ↓
Focus management
      ↓
Labels
      ↓
ARIA where appropriate
      ↓
Screen readers

Accessibility should be considered during component design, not added after development is complete.

Common Misconceptions

Misconception 1: React is a programming language

No.

React is a JavaScript library.

Misconception 2: React replaces JavaScript

No.

React is built using JavaScript and relies heavily on JavaScript concepts.

You need strong JavaScript fundamentals.

Misconception 3: React is only the Virtual DOM

No.

The rendering architecture is broader than that.

Misconception 4: React automatically makes applications fast

No.

Poor architecture can still produce poor performance.

Misconception 5: React automatically secures applications

No.

Security requires frontend and backend controls.

Misconception 6: Every application needs Redux

No.

State requirements should determine the architecture.

Misconception 7: Every value belongs in state

No.

Derived values should generally be calculated rather than unnecessarily duplicated.

Misconception 8: useEffect() is the React equivalent of "run this code"

Not exactly.

Effects are primarily for synchronizing React with external systems.

This will be discussed in depth when we reach useEffect.

Misconception 9: React and Next.js are the same

No.

Next.js is a framework built around React.

Misconception 10: More abstractions mean better architecture

Not necessarily.

Good architecture is about appropriate boundaries, not maximum abstraction.

Best Practices

For modern React development:

1. Learn JavaScript deeply before relying on React abstractions.
2. Understand the component model.
3. Prefer functional components.
4. Keep components focused.
5. Use meaningful component boundaries.
6. Keep state close to where it is needed.
7. Avoid unnecessary global state.
8. Separate client state from server state.
9. Avoid unnecessary effects.
10. Use TypeScript for large production applications.
11. Use semantic HTML.
12. Build accessibility into components.
13. Measure before optimizing.
14. Avoid unnecessary memoization.
15. Keep API communication separate from presentation when appropriate.
16. Organize large applications around features/domains.
17. Understand the browser platform.
18. Keep React and ecosystem dependencies current.
19. Understand which features belong to React and which belong to frameworks/libraries.
20. Never treat frontend UI restrictions as backend authorization.

A Simple React Mental Model

If you remember only one diagram from this lesson, remember this:

             APPLICATION STATE
                    │
                    ▼
             REACT COMPONENTS
                    │
                    ▼
               UI DESCRIPTION
                    │
                    ▼
              REACT RENDERING
                    │
                    ▼
               DOM COMMIT
                    │
                    ▼
                 BROWSER
                    │
                    ▼
              USER INTERACTION
                    │
                    ▼
              STATE UPDATE
                    │
                    └──────────────►

This cycle is at the heart of React application development.

Practical Exercise

Build a Simple Course Introduction

Create a React component representing a TechLearningPro course.

Requirements

Create:

CourseIntroduction
│
├── Course Title
├── Description
├── Instructor
├── Difficulty
├── Duration
└── Start Learning Button

Example:

function CourseIntroduction() {
  return (
    <section>
      <h1>React Mastery</h1>
      <p>
        Learn React from fundamentals
        to enterprise architecture.
      </p>
      <p>Level: Advanced</p>
      <p>Duration: 40 hours</p>
      <button>
        Start Learning
      </button>
    </section>
  );
}

Challenge

Now break it into:

CourseIntroduction
       │
       ├── CourseHeader
       ├── CourseMetadata
       └── StartLearningButton

Then ask yourself:

Which component should own which responsibility?

That question will become increasingly important throughout this course.

Interview questions & answers

Final Understanding

After this lesson, you should no longer think of React simply as:

React = JSX + Components

Instead, think:

React
 │
 ├── Declarative UI
 │
 ├── Component Model
 │
 ├── Composition
 │
 ├── State-driven Rendering
 │
 ├── Rendering/Reconciliation
 │
 └── Ecosystem Integration

And around React:

                 React
                   │
       ┌───────────┼───────────┐
       ▼           ▼           ▼
   Routing      State        Data
       │           │           │
       ▼           ▼           ▼
React Router   Redux/       TanStack
               Context      Query
       │           │           │
       └───────────┼───────────┘
                   ▼
             Application
              Architecture

The deeper lesson is this:

React is not valuable simply because it provides components. React is valuable because it provides a predictable way to model complex, state-driven user interfaces.

Once this mental model is clear, the rest of React becomes much easier to understand.

Next Lesson

**React vs Traditional Web Development**

The next lesson should answer an important engineering question:

Why do we need React when JavaScript, HTML, CSS, and the browser DOM already exist?

We will compare:

Traditional Web Development
          │
          ▼
Manual DOM Manipulation
          │
          ▼
Increasing UI Complexity
          │
          ▼
Component-Based Development
          │
          ▼
React

and build a clear understanding of exactly where React provides value—and where plain JavaScript may still be the better choice.