React Home

React Home is one of the foundational pieces of modern React engineering.

Learning Objectives

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

1. Understand what React is and what problem it solves.
2. Understand React's role in modern frontend development.
3. Explain the component-based UI model.
4. Understand how a React application is structured conceptually.
5. Understand the relationship between React, React DOM, and the React ecosystem.
6. Understand the basic React rendering flow.
7. Understand why React applications are modeled as component trees.
8. Distinguish React from frameworks such as Next.js.
9. Understand modern React development practices.
10. Understand the role of TypeScript in production React applications.
11. Understand why Create React App should not be used for new projects.
12. Understand the importance of frameworks and build tools in modern React.
13. Understand the React 19.x generation and modern React capabilities.
14. Identify where React fits in an enterprise frontend architecture.
15. Explain React at a beginner, senior, and architect level.

Introduction

Imagine you are building the homepage of TechLearningPro.

At first, it looks simple:

----------------------------------------------------
| TechLearningPro                                  |
----------------------------------------------------
| Courses | Tutorials | Interview | Blog | Login  |
----------------------------------------------------
|                                                  |
| Learn Java                                       |
| Learn React                                      |
| Learn Spring Boot                                |
| Learn Kubernetes                                 |
|                                                  |
----------------------------------------------------
| Popular Courses                                  |
| [Java] [React] [Angular] [Spring Boot]           |
----------------------------------------------------

But now imagine what happens when the application becomes large.

A user logs in.

The navigation changes.

The course list comes from an API.

The user searches for a course.

The search results update.

A course is added to the wishlist.

The notification counter changes.

A video starts playing.

The progress percentage changes.

A payment dialog opens.

The application needs to work on mobile.

Different teams work on different parts of the application.

Suddenly, frontend development becomes much more complicated than writing HTML.

The real problem becomes:

How do we build a large user interface that remains predictable, reusable, maintainable, and performant as the application grows?

This is where React becomes valuable.

React provides a component-oriented programming model for building user interfaces. The official React documentation describes React as a JavaScript library for rendering user interfaces and emphasizes reusable, nestable components.

What Is React?

At the simplest level:

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

But that definition is only the beginning.

A more useful engineering definition is:

React is a declarative UI library that allows developers to describe what the user interface should look like for a particular application state, while React manages the process of updating the UI.

This distinction is extremely important.

Instead of manually telling the browser:

document.getElementById("course-title").innerText =
  "React Mastery";

you describe the UI:

function CourseTitle({ title }: { title: string }) {
  return <h1>{title}</h1>;
}

Then:

<CourseTitle title="React Mastery" />

The developer focuses primarily on:

Application State
       ↓
UI Description
       ↓
React
       ↓
Browser UI

rather than manually managing every DOM mutation.

The Problem React Solves

Before component-based UI libraries became popular, applications commonly relied heavily on:

HTML
+
CSS
+
JavaScript
+
Manual DOM manipulation

For a small website, this is perfectly reasonable.

For a large application, problems start appearing.

Consider:

User clicks "Add to Wishlist"
             ↓
JavaScript event
             ↓
Update wishlist data
             ↓
Update button
             ↓
Update wishlist count
             ↓
Update navigation
             ↓
Update notification
             ↓
Possibly update another component

If every part of the UI is manually manipulated, maintaining relationships between UI and application state becomes difficult.

React approaches the problem differently.

              Application State
                     │
                     ▼
              React Components
                     │
                     ▼
                UI Output
                     │
                     ▼
                  Browser

When state changes, React can render the appropriate UI based on that state.

The official React documentation describes rendering as a process involving triggering a render, rendering components, and committing changes to the DOM.

The React Mental Model

One of the most important things to understand early is this:

React is not primarily about manipulating HTML. It is about describing UI as a function of state.

Conceptually:

UI = f(state)

For example:

function LoginStatus({ loggedIn }: { loggedIn: boolean }) {
  if (loggedIn) {
    return <button>Logout</button>;
  }
  return <button>Login</button>;
}

If:

loggedIn = false

React renders:

[ Login ]

If:

loggedIn = true

React renders:

[ Logout ]

The component describes the UI for the current state.

This mental model becomes extremely important when you later learn:

• state
• effects
• rendering
• reconciliation
• memoization
• concurrency
• server components
• performance optimization

React Is Component-Based

React applications are built from components.

A component is a reusable piece of UI with its own logic and appearance. React's official documentation describes components as the building blocks of React applications.

For example:

function LoginButton() {
  return <button>Login</button>;
}

Another component:

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

And:

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

The resulting structure can be visualized as:

App
│
├── Header
│   ├── Logo
│   ├── Navigation
│   └── LoginButton
│
├── CourseList
│   ├── CourseCard
│   ├── CourseCard
│   └── CourseCard
│
└── Footer

This is a component tree.

React itself models UI relationships as trees, and understanding those trees becomes useful later for state management, debugging, and performance analysis.

Why Components Matter

Without components, you might end up with one enormous file:

App
 ├── 500 lines of navigation
 ├── 700 lines of course UI
 ├── 400 lines of user profile
 ├── 600 lines of payment UI
 ├── 300 lines of notifications
 └── 800 lines of dashboard

This becomes difficult to:

• understand
• test
• reuse
• modify
• review
• maintain

Instead:

App
│
├── Header
├── Sidebar
├── Dashboard
│   ├── Statistics
│   ├── CourseProgress
│   └── ActivityFeed
│
├── CourseList
│   └── CourseCard
│
└── Footer

Now individual pieces have clear responsibilities.

This is one of the foundations of scalable React architecture.

React in a Real Application

Let's use TechLearningPro as our running example.

A simplified architecture might look like this:

                    Browser
                       │
                       ▼
               React Application
                       │
          ┌────────────┼────────────┐
          │            │            │
          ▼            ▼            ▼
       Header       Course UI     User UI
          │            │            │
          ▼            ▼            ▼
      Navigation    CourseCard    Profile
                       │
                       ▼
                  State / Hooks
                       │
                       ▼
                  Service Layer
                       │
                       ▼
                    REST API
                       │
                       ▼
                Backend Services
                       │
                       ▼
                   Database

React is primarily concerned with the UI layer.

It does not automatically become your:

• database
• backend
• authentication server
• API server
• business system
• complete application framework

This distinction is critical.

React vs React DOM

Beginners often see:

react
react-dom

and assume they are the same thing.

They are related, but they have different responsibilities.

Conceptually:

             React
               │
       UI/component model
               │
               ▼
        React Components
               │
               ▼
           React DOM
               │
               ▼
        Browser DOM

react provides the core React programming model.

react-dom provides React's integration with the browser DOM.

For example, modern React applications commonly use:

import { createRoot } from "react-dom/client";

and:

createRoot(document.getElementById("root")!).render(
  <App />
);

This is an important distinction when discussing architecture.

React vs React Router vs Next.js

React is frequently confused with its ecosystem.

They are not the same thing.

React

UI library.

Components
State
Rendering
Hooks

React DOM

Browser DOM integration.

React
   ↓
Browser DOM

React Router

Routing solution for React applications.

/products
/courses
/profile
/login

Next.js

A React framework that provides additional application capabilities such as routing, server rendering, static generation, and server-oriented features.

The current React documentation recommends starting new applications with a framework when appropriate, while also documenting how to build React from scratch when a framework isn't a good fit.

So don't think:

React = Next.js

Instead:

                 React
                   │
       ┌───────────┴───────────┐
       │                       │
 Client-side apps       React frameworks
       │                       │
 React Router              Next.js
 etc.

Modern React

React has evolved considerably.

This course should not teach React as if it were React 16 from years ago.

The current React documentation identifies React 19.2 as a released version, with React 19.2 released on October 1, 2025. It introduced features including <Activity />, useEffectEvent, cacheSignal, performance tracks, and partial pre-rendering in React DOM.

React 19 itself introduced capabilities such as Actions and improvements to Suspense and React DOM APIs.

Therefore, throughout this course, we should distinguish:

Legacy React
      │
      ▼
React 18
      │
      ▼
React 19
      │
      ▼
React 19.x

And we should avoid presenting experimental APIs as stable.

React explicitly maintains stable and experimental release channels, with stable releases following semantic versioning.

React Is Not Just "Virtual DOM"

A common beginner explanation is:

React is a library that uses Virtual DOM.

This is incomplete.

The Virtual DOM is only one part of the broader rendering model.

A better mental model is:

Component Logic
      │
      ▼
React Elements / Render Output
      │
      ▼
React Rendering
      │
      ▼
Reconciliation
      │
      ▼
Commit
      │
      ▼
Browser DOM

And importantly:

A React render does not automatically mean the browser DOM will be completely rewritten.

React determines what needs to change and commits the necessary updates.

This is why understanding render and commit is more valuable than memorizing "Virtual DOM."

The official React documentation explicitly distinguishes rendering from committing changes to the DOM.

React Rendering Flow

Let's understand the high-level flow.

Suppose a user clicks:

[Add to Wishlist]

A simplified flow is:

User Interaction
       │
       ▼
Event Handler
       │
       ▼
State Update
       │
       ▼
React schedules rendering
       │
       ▼
Component renders
       │
       ▼
React determines UI changes
       │
       ▼
Commit
       │
       ▼
Browser DOM

This will become much more important when we study:

• useState
• batching
• rendering
• reconciliation
• transitions
• performance
• concurrent rendering

For now, remember the conceptual pipeline.

React and Declarative Programming

Consider an imperative approach.

You might say:

Find button
Find counter
Read current value
Increment value
Update text
Change button state

In declarative React:

function Counter({ count }: { count: number }) {
  return <button>{count}</button>;
}

You describe:

Given this state, this is what the UI should look like.

This separation becomes powerful as applications grow.

React Application Architecture

A production React application should not become a collection of random components.

A more mature architecture might look like:

src/
│
├── app/
│   ├── App.tsx
│   ├── routes.tsx
│   └── providers/
│
├── features/
│   ├── courses/
│   │   ├── components/
│   │   ├── hooks/
│   │   ├── services/
│   │   └── types/
│   │
│   ├── authentication/
│   └── profile/
│
├── shared/
│   ├── components/
│   ├── hooks/
│   ├── utils/
│   └── types/
│
├── services/
│
└── main.tsx

This is not a mandatory React folder structure.

It is an example of a feature-oriented architecture.

The important lesson is:

React gives you the component model. Your engineering team must design the application's architecture around it.

React and TypeScript

Modern enterprise React applications frequently use TypeScript.

For example:

interface Course {
  id: string;
  title: string;
  duration: number;
  level: "Beginner" | "Intermediate" | "Advanced";
}
interface CourseCardProps {
  course: Course;
}
function CourseCard({ course }: CourseCardProps) {
  return (
    <article>
      <h2>{course.title}</h2>
      <p>{course.level}</p>
      <p>{course.duration} hours</p>
    </article>
  );
}

This creates an explicit component contract.

Course
   │
   ▼
CourseCardProps
   │
   ▼
CourseCard

TypeScript helps catch many mistakes during development rather than waiting for runtime.

React's official setup documentation explicitly provides guidance for using TypeScript with React.

React Setup in the Modern Era

One important change for new React developers:

Do not start new projects with Create React App.

The current React documentation states that Create React App has been deprecated.

Modern React application creation depends on the project's requirements.

For example:

Need full-stack React capabilities?
        │
        ├── Yes → Consider a React framework
        │
        └── No
             │
             ▼
       Build from scratch
             │
             ▼
      Choose appropriate
       build tooling

React's documentation currently recommends frameworks for new applications when appropriate, while also documenting build-tool approaches such as Vite when building from scratch.

This is an important architectural decision rather than simply an installation command.

React DevTools

When developing production React applications, you should understand the developer tooling ecosystem.

React DevTools allows developers to inspect React components, examine props and state, and investigate performance problems.

Conceptually:

React Application
       │
       ▼
React DevTools
       │
 ┌─────┼────────────┐
 ▼     ▼            ▼
Props State      Components
       │
       ▼
Performance

As a senior engineer, debugging React without understanding the developer tools is a significant weakness.

Real-World Enterprise Example

Imagine TechLearningPro has:

10,000 Courses
1,000,000 Users
Thousands of concurrent users
Multiple frontend teams
Multiple backend services

The architecture might evolve toward:

                         CDN
                          │
                          ▼
                    React Application
                          │
        ┌─────────────────┼─────────────────┐
        │                 │                 │
        ▼                 ▼                 ▼
   Course Feature    User Feature      Admin Feature
        │                 │                 │
        └────────────┬────┴────────────┬────┘
                     │                 │
                     ▼                 ▼
               Client State       Server State
                     │                 │
                     └───────┬─────────┘
                             ▼
                       API Gateway
                             │
              ┌──────────────┼──────────────┐
              ▼              ▼              ▼
         Course Service  User Service   Payment Service
              │              │              │
              ▼              ▼              ▼
           Database       Database       Database

React is only one layer.

A senior engineer must understand the boundaries between:

UI
↓
Client State
↓
Server State
↓
API
↓
Backend
↓
Database

This distinction prevents a common architectural mistake:

Putting business logic, server state, API communication, and UI concerns into one giant React component.

Performance Perspective

React performance is not simply:

Use useMemo() everywhere.

That is a common misconception.

Performance problems can originate from:

Large component trees
        │
        ├── Excessive rendering
        │
        ├── Large JavaScript bundles
        │
        ├── Expensive calculations
        │
        ├── Too many network requests
        │
        ├── Large lists
        │
        ├── Poor state placement
        │
        └── Unnecessary dependencies

A mature performance strategy looks like:

Measure
  ↓
Identify bottleneck
  ↓
Understand root cause
  ↓
Apply targeted optimization
  ↓
Measure again

Later in this course we will explore:

• React Profiler
• memoization
• React.memo
• useMemo
• useCallback
• virtualization
• code splitting
• lazy loading
• Suspense
• bundle optimization
• Web Vitals

Security Perspective

React does not automatically make an application secure.

Security remains an architectural responsibility.

Important areas include:

Authentication
     │
     ▼
Authorization
     │
     ▼
Secure API communication
     │
     ▼
Input handling
     │
     ▼
XSS protection
     │
     ▼
Dependency security
     │
     ▼
Content Security Policy

For example, never assume that hiding a UI element provides authorization.

This:

{isAdmin && <DeleteButton />}

only controls what the user sees.

It does not secure the backend operation.

A malicious user can still call an API directly.

Therefore:

Frontend authorization
        ≠
Backend authorization

The backend must enforce actual authorization.

Accessibility Perspective

A professional React application must also be accessible.

Prefer:

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

instead of:

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

The semantic <button> provides browser and accessibility behavior that a generic <div> does not.

Important areas include:

• semantic HTML
• keyboard navigation
• focus management
• accessible labels
• appropriate ARIA usage
• screen-reader compatibility
• accessible forms

Accessibility should not be treated as something added at the end of development.

It should be part of component design.

Common Beginner Mistakes

Mistake 1: Treating React as a template engine

React is much more than HTML templating.

Mistake 2: Putting everything into `App.tsx`

Large applications should be decomposed into meaningful components and features.

Mistake 3: Using state for everything

Not every value needs React state.

For example:

const fullName = `${firstName} ${lastName}`;

doesn't necessarily need another state variable.

Mistake 4: Using `useEffect()` for every piece of logic

Effects are for synchronizing with external systems, not simply for running arbitrary code after rendering.

This distinction will become very important later.

Mistake 5: Believing every render is bad

Rendering is a normal part of React.

The important question is:

Is the rendering expensive or unnecessary?

Mistake 6: Using `useMemo()` everywhere

Memoization has a cost.

Use it when it solves a demonstrated problem rather than as a default reflex.

Mistake 7: Treating frontend security as sufficient

Hiding buttons does not provide authorization.

Mistake 8: Ignoring accessibility

A visually functional application can still be inaccessible.

Mistake 9: Following old tutorials blindly

React has evolved.

For example:

Create React App

is now deprecated.

Mistake 10: Thinking React is the entire frontend architecture

React is one part of the frontend ecosystem.

You still need to make decisions about:

Routing
State
Data fetching
Forms
Testing
Authentication
Build tooling
Observability
Architecture
Deployment

Best Practices

A professional React team should generally follow principles such as:

1. Prefer functional components.
2. Keep components focused.
3. Use meaningful component names.
4. Keep state as close as practical to where it is used.
5. Avoid unnecessary global state.
6. Separate server state from UI state.
7. Use TypeScript for large production applications.
8. Prefer semantic HTML.
9. Design components for accessibility.
10. Avoid unnecessary effects.
11. Avoid premature optimization.
12. Measure performance before optimizing.
13. Keep API logic separate from presentation components.
14. Organize code around features when the application becomes large.
15. Establish clear component contracts.
16. Avoid giant "god components."
17. Keep business rules out of presentation where appropriate.
18. Test behavior rather than implementation details.
19. Keep dependencies up to date.
20. Understand the React version and ecosystem you're actually using.

Real-World Architecture

A mature React architecture can be visualized as:

                         USER
                          │
                          ▼
                    React UI Layer
                          │
              ┌───────────┼───────────┐
              ▼           ▼           ▼
          Components    Hooks      Routing
              │           │           │
              └───────────┼───────────┘
                          ▼
                  Application Logic
                          │
              ┌───────────┴───────────┐
              ▼                       ▼
         Client State            Server State
              │                       │
              └───────────┬───────────┘
                          ▼
                    Service Layer
                          │
                          ▼
                     HTTP / WS
                          │
                          ▼
                    Backend APIs
                          │
                          ▼
                     Data Layer

The goal is not to create as many layers as possible.

The goal is to establish clear responsibilities.

React Architecture at Staff Engineer Level

At senior and staff levels, the question changes.

A junior developer might ask:

How do I create a React component?

A senior developer might ask:

Where should this state live?

A staff engineer might ask:

What architecture allows five teams to independently develop features without creating excessive coupling?

An architect might ask:

How should the frontend evolve when the organization grows from two teams to twenty teams?

The technology is the same.

The engineering perspective changes.

For example:

Small application
App
 ├── Header
├── Courses
 └── Profile

may eventually become:

Enterprise Platform
Shell
 │
 ├── Authentication
├── Course Domain
├── Learning Domain
├── Payment Domain
├── Analytics Domain
 └── Administration Domain

The React course therefore needs to progress beyond syntax.

Interview questions & answers

Practical Exercise

Exercise: Build a React Home Page

Problem

Create the initial homepage for TechLearningPro.

Requirements

The page should contain:

Header
│
├── Logo
├── Courses
├── Tutorials
├── Interview
├── Blog
└── Login
Hero Section
│
├── Heading
├── Description
└── CTA
Popular Courses
│
├── CourseCard
├── CourseCard
└── CourseCard
Footer

Suggested component architecture

App
│
├── Header
│
├── Hero
│
├── PopularCourses
│   └── CourseCard
│
└── Footer

Difficulty

Beginner → Intermediate

Constraints

Use:

• React
• TypeScript
• Functional components
• JSX
• Props
• Semantic HTML

Do not use a state-management library.

Expected Learning

By completing this exercise, you should understand:

Application
    ↓
Components
    ↓
Composition
    ↓
Props
    ↓
Rendered UI

Summary

React starts with a deceptively simple idea:

Build UI from Components

But that idea scales surprisingly far.

A modern React application can evolve from:

One Component
      ↓
Component Tree
      ↓
Application
      ↓
Feature Architecture
      ↓
Enterprise Frontend
      ↓
Multi-Team Platform

The most important mental model to carry forward is:

                 State
                   │
                   ▼
              React Logic
                   │
                   ▼
              Components
                   │
                   ▼
              Render Output
                   │
                   ▼
             React Rendering
                   │
                   ▼
                 DOM
                   │
                   ▼
                 User
                   │
                   └───────────┐
                               │
                         User Interaction
                               │
                               ▼
                         State Update
                               │
                               └──────► ...

Once you understand this cycle, concepts such as JSX, components, props, state, hooks, effects, rendering, reconciliation, routing, state management, performance, and architecture become much easier to connect.

The official React documentation itself organizes the learning journey around describing UI, adding interactivity, managing state, and understanding escape hatches—an approach that aligns well with this course progression.

Next Lesson

Next: Why React?

In the next lesson, we will answer a much more important engineering question:

Why do we need React in the first place?

We will compare:

Traditional HTML + JavaScript
          ↓
DOM Manipulation
          ↓
Component-Based UI
          ↓
React

and examine why React became valuable for complex applications, what problems it solves, what problems it does not solve, and when using React may actually be the wrong architectural decision.