React Developer Tools

React Developer Tools

Learning Objectives

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

1. Understand what React Developer Tools is.
2. Install and enable React Developer Tools.
3. Inspect React component hierarchies.
4. Inspect component props and state.
5. Understand the difference between React DevTools and browser DevTools.
6. Debug component rendering problems.
7. Inspect hooks.
8. Analyze component re-renders.
9. Use the Profiler to investigate performance.
10. Identify unnecessary re-renders.
11. Understand how React DevTools represents the React component tree.
12. Use DevTools effectively in enterprise React applications.
13. Avoid common debugging mistakes.
14. Explain React Developer Tools confidently in interviews.

Introduction

So far, we've learned:

React
   ↓
Vite
   ↓
Project Structure
   ↓
SPA

Now we need an important engineering skill:

How do we see what React is actually doing inside our application?

When an application behaves unexpectedly, looking only at the source code isn't always enough.

For example:

User clicks button
       ↓
State changes
       ↓
Component renders
       ↓
Unexpected child renders
       ↓
Performance issue

You need a way to inspect the React application while it is running.

That's where:

React Developer Tools

becomes extremely useful.

What Is React Developer Tools?

React Developer Tools, commonly called React DevTools, is a browser development tool for inspecting and debugging React applications.

It provides React-specific information that normal browser DevTools don't expose as conveniently.

You can inspect things such as:

Components
Props
State
Hooks
Component hierarchy
Rendered structure
Performance

The official React documentation provides the current installation and usage guidance. React Developer Tools

React DevTools vs Browser DevTools

This distinction is important.

Chrome/Edge/Firefox DevTools can inspect:

HTML
CSS
JavaScript
Network
Console
Storage
Performance

React DevTools adds React-specific visibility:

React Components
Props
State
Hooks
Component tree
React rendering behavior
Profiler information

Think of it as:

Browser DevTools
        │
        ├── DOM
        ├── CSS
        ├── Network
        ├── Console
        └── JavaScript
React DevTools
        │
        ├── Components
        ├── Props
        ├── State
        ├── Hooks
        └── React Performance

They complement each other.

Why React Developer Tools Matters

Imagine you have:

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

Something is wrong.

The browser shows:

React Course

But you want to know:

What props did CourseCard receive?
What state does it have?
Which parent rendered it?
Did it render again?
Why did it render?

React DevTools helps answer these questions.

Installing React Developer Tools

React Developer Tools is available as a browser extension for supported browsers.

You can install it from the official React Developer Tools page. React Developer Tools installation

After installation, open your React application and then open browser DevTools.

You should see React-specific panels such as:

Components
Profiler

The exact UI can vary by browser and DevTools version.

Components Panel

The Components panel is one of the most important parts of React DevTools.

It displays the React component hierarchy.

Suppose our application contains:

<App>
  <Layout>
    <Header />
    <CoursePage>
      <CourseList>
        <CourseCard />
        <CourseCard />
      </CourseList>
    </CoursePage>
  </Layout>
</App>

React DevTools can represent this relationship as a tree:

App
└── Layout
    ├── Header
    └── CoursePage
        └── CourseList
            ├── CourseCard
            └── CourseCard

This is much more useful than looking only at generated HTML.

React Component Tree vs DOM Tree

This distinction is extremely important.

The browser DOM might look like:

body
└── div#root
    └── main
        ├── header
        └── section
            ├── article
            └── article

But the React component tree might look like:

App
└── Layout
    ├── Header
    └── CoursePage
        └── CourseList
            └── CourseCard

These are not the same thing.

React DevTools lets you inspect the React component tree.

Browser DevTools lets you inspect the DOM tree.

Selecting a Component

Suppose you select:

CourseCard

React DevTools can show information about that component.

Conceptually:

CourseCard
Props
├── course
│   ├── id
│   ├── title
│   └── level
│
└── onSelect
Hooks
└── ...

This is extremely useful for debugging.

Instead of adding:

console.log(course);

everywhere, you can often inspect the component directly.

Inspecting Props

Suppose:

<CourseCard
  course={course}
  featured={true}
/>

React DevTools can show:

Props
├── course
│   ├── id: "react-101"
│   ├── title: "React Fundamentals"
│   └── level: "Beginner"
│
└── featured: true

This helps answer:

Is my component receiving the data I expect?

Debugging Props

Imagine the UI displays:

Unknown Course

Your first thought might be:

CourseCard is broken.

But DevTools might reveal:

course
  title: undefined

Now the problem may actually be upstream.

The flow could be:

API
 ↓
State
 ↓
CourseList
 ↓
CourseCard

DevTools helps you inspect the data at the component boundary.

Inspecting State

Suppose:

function CourseFilter() {
  const [search, setSearch] = useState("");
  // ...
}

React DevTools can expose hook/state information associated with the component.

Conceptually:

CourseFilter
Hooks
└── State
    └── search: "react"

You can then understand the component's current runtime state.

State Debugging Example

Suppose the UI contains:

Search: react

but the API request is behaving as if:

Search: java

You can inspect the component state.

If DevTools shows:

search = "react"

then the issue is probably downstream.

If it shows:

search = "java"

then you have immediately narrowed the problem.

This is the value of runtime inspection.

Inspecting Hooks

Modern React applications heavily use hooks.

For example:

function CoursePage() {
  const [courses, setCourses] = useState([]);
  const [loading, setLoading] = useState(true);
  const value = useMemo(() => {
    // ...
  }, []);
  // ...
}

DevTools can show hook-related information for components.

Conceptually:

CoursePage
Hooks
├── State
│   └── courses
├── State
│   └── loading
└── Memo

The exact representation depends on the React version and hook usage.

Custom Hooks

Suppose:

function CoursePage() {
  const {
    courses,
    loading,
    error
  } = useCourses();
  // ...
}

And:

function useCourses() {
  // ...
}

DevTools can help you inspect the component's hook information.

This is particularly useful when debugging:

Data fetching
Authentication
State
Effects
Memoization
Custom behavior

Component Ownership

The component tree also helps answer:

Who rendered this component?

For example:

App
└── Dashboard
    └── CourseWidget
        └── CourseCard

If CourseCard receives an unexpected prop, you can move upward through the tree and inspect:

CourseCard
    ↑
CourseWidget
    ↑
Dashboard
    ↑
App

This is often faster than reading hundreds of lines of source code.

Inspecting Component Source

React DevTools can also help you connect runtime components back to their source location, depending on your development setup and browser tooling.

For example:

CourseCard
    ↓
src/features/courses/components/CourseCard.tsx

This makes the debugging loop:

Runtime
   ↓
Component
   ↓
Source Code
   ↓
Fix

much faster.

Component Filtering

Large applications may contain hundreds or thousands of components.

The Components panel therefore provides filtering/search capabilities.

For example:

Search:
Course

might narrow the tree to:

CoursePage
CourseList
CourseCard
CourseFilters
CourseProgress

This becomes especially useful in enterprise applications.

Inspecting DOM from React DevTools

When a component is selected, React DevTools can help connect the React component to the corresponding DOM representation.

This creates a useful debugging path:

React Component
      │
      ▼
DOM Element
      │
      ▼
CSS / Layout

For example:

CourseCard
   ↓
<article>
   ↓
CSS
   ↓
Unexpected layout

You can then move into browser DevTools for detailed DOM/CSS inspection.

React DevTools and Console

React DevTools doesn't replace the browser console.

Use the console for:

Network errors
JavaScript exceptions
Logs
Warnings
API debugging

Use React DevTools for:

Component hierarchy
Props
State
Hooks
React-specific behavior

A strong developer uses both.

Example Debugging Workflow

Imagine a button isn't working.

Start with:

Button click
   ↓
No expected behavior

Step 1 — Browser Console

Check:

JavaScript error?

Step 2 — React DevTools

Select the component:

CourseCard

Inspect:

Props
State
Hooks

Step 3 — Trace Parent

Check:

Who provided onSelect?

Step 4 — Network

If the click triggers an API:

Request sent?
Correct URL?
Correct payload?
Response?

Step 5 — Source

Return to:

CourseCard.tsx

and fix the problem.

This is much more effective than blindly adding console.log() statements everywhere.

The Profiler

React DevTools also provides a Profiler.

The Profiler helps investigate rendering performance.

Suppose your application behaves like:

User clicks filter
        ↓
Entire page becomes slow

You want to know:

Which components rendered?
How long did rendering take?
Which part of the tree changed?

The Profiler can help answer these questions.

What Is Profiling?

Profiling means measuring application behavior rather than guessing.

Instead of:

I think CourseList is slow.

you can investigate:

Render
├── Dashboard       2ms
├── CourseList     80ms
├── CourseCard      1ms
└── Sidebar         3ms

The exact numbers are illustrative.

The principle is:

Measure before optimizing.

Recording a Profile

A typical workflow is:

Open Profiler
      ↓
Start recording
      ↓
Perform interaction
      ↓
Stop recording
      ↓
Analyze render activity

For example:

Click Filter
     ↓
Record
     ↓
Observe component renders
     ↓
Identify expensive subtree

Render Performance

Suppose:

Dashboard
├── Header
├── Sidebar
├── CourseList
└── Notifications

You change:

Course filter

But somehow:

Header
Sidebar
CourseList
Notifications

all render again.

That may or may not be a problem.

The Profiler helps determine whether those renders are actually expensive.

This is important:

A re-render is not automatically a performance bug.

Re-render vs DOM Update

This is a very important React concept.

Suppose:

function Counter() {
  const [count, setCount] = useState(0);
  return <button>{count}</button>;
}

When:

count: 0 → 1

React may re-render the component.

But that does not mean React blindly recreates the entire DOM.

Conceptually:

State change
    ↓
React render
    ↓
Compare result
    ↓
Commit necessary DOM changes

Only the required DOM changes are committed.

React DevTools helps you inspect the component side of this process.

Why Unnecessary Re-renders Matter

Imagine:

Dashboard
  └── LargeDataTable
       └── 5,000 rows

If changing a small unrelated state causes expensive work inside the table repeatedly, the application may become slow.

You might see:

User changes theme
       ↓
Dashboard renders
       ↓
DataTable renders
       ↓
5,000 rows processed

The Profiler can help you identify such patterns.

Common Causes of Unnecessary Rendering

Some common causes include:

Parent re-render
New object references
New function references
Context updates
State placed too high
Large component trees
Poor state ownership
Expensive calculations

For example:

<CourseCard
  course={course}
  options={{ featured: true }}
/>

creates a new object during each parent render.

This doesn't automatically mean the child will be slow, but object identity can matter when using memoization or equality-based optimizations.

We'll study this deeply later.

`memo` and DevTools

Suppose:

const CourseCard = memo(function CourseCard({
  course
}) {
  return <div>{course.title}</div>;
});

Now React can skip rendering the component when its props haven't meaningfully changed according to the memoization comparison.

But don't use memo everywhere.

The correct engineering process is:

Problem
  ↓
Measure
  ↓
Identify expensive render
  ↓
Understand cause
  ↓
Optimize
  ↓
Measure again

Not:

Add memo everywhere

Profiler and Production Performance

Development behavior and production behavior can differ.

For example:

Development
   ↓
Strict Mode
   ↓
Additional development checks

may make certain behavior appear different from production.

Therefore, performance decisions should be validated in realistic production-like builds and with real measurements.

React DevTools and Strict Mode

You may notice components appearing to execute more than expected in development.

For example:

<StrictMode>
  <App />
</StrictMode>

React's development behavior can intentionally expose unsafe patterns.

This can make developers think:

React is rendering twice because something is broken.

Not necessarily.

Development-only checks can cause additional invocation behavior.

Therefore:

DevTools observation
      +
React development behavior
      ↓
Interpret carefully

We'll cover Strict Mode separately.

React DevTools Settings

React DevTools provides settings that can affect what information is displayed.

Depending on the version, you may encounter options related to:

Component filters
Theme
Profiler behavior
Debugging

The exact options can change across DevTools versions.

Avoid relying on screenshots from old tutorials because the interface evolves.

Production Builds

One important distinction:

Development debugging capabilities are not equivalent to production behavior.

A production application is typically optimized and may expose less development information.

For security reasons, you should not assume that development debugging tools should be available or unrestricted in production.

Don't Depend on DevTools for Security

This is extremely important.

Suppose DevTools shows:

user.role = "USER"

A developer might think:

I'll hide the admin button.

But hiding:

<AdminButton />

is not security.

A malicious user can call the API directly.

Correct:

Frontend
   ↓
UX restriction
Backend
   ↓
Security enforcement

React DevTools is a debugging tool, not a security boundary.

React DevTools for API Debugging

React DevTools isn't a replacement for Network DevTools.

Use:

React DevTools

to inspect:

Component state

Use:

Network

to inspect:

HTTP request
HTTP response
Headers
Payload
Timing
Status

Combined workflow:

Component State
       ↓
API Request
       ↓
Network
       ↓
API Response
       ↓
Component State
       ↓
Rendered UI

This is one of the most powerful debugging patterns.

Example: Course Loading Bug

Suppose the UI shows:

No courses found

But the backend definitely contains courses.

Investigate:

React DevTools

CoursePage
   ↓
courses = []

Network

GET /api/courses
Status: 200
Response:
[
  ...
]

Now the problem is probably between:

API response
     ↓
state update

Alternatively, if Network shows:

GET /api/courses
Status: 500

the problem is likely backend/API related.

This is how DevTools helps narrow the fault domain.

Example: Authentication Bug

Suppose the user logs in but still sees the login page.

React DevTools:

AuthProvider
   │
   └── isAuthenticated = false

Network:

POST /api/login
200 OK

Now investigate:

Login response
       ↓
Token/session handling
       ↓
Auth state update

Again, the combination of tools is more powerful than either one alone.

Example: Slow Dashboard

Suppose:

Dashboard

takes several seconds to respond to filters.

Profiler:

Dashboard       5ms
Chart          30ms
DataTable     450ms
CourseList     100ms

Now you have evidence.

You can investigate:

DataTable

instead of randomly optimizing:

Header
Sidebar
Dashboard

This is the difference between:

Guessing

and:

Profiling

React DevTools in Enterprise Development

For a large application:

App
├── Authentication
├── Dashboard
├── Courses
├── Payments
├── Reports
└── Administration

React DevTools can help developers understand:

Component ownership
Props
State
Hooks
Rendering
Performance

This is especially useful when a component tree is much larger than the code currently being modified.

Debugging Workflow for Senior Engineers

A strong debugging process is:

                 Problem
                    │
                    ▼
              Reproduce Issue
                    │
                    ▼
             Browser Console
                    │
                    ▼
             React DevTools
                    │
           ┌────────┼────────┐
           ▼        ▼        ▼
         Props    State     Hooks
           │        │        │
           └────────┼────────┘
                    ▼
                 Network
                    │
                    ▼
                Profiler
                    │
                    ▼
               Root Cause
                    │
                    ▼
                  Fix
                    │
                    ▼
               Re-measure

This is a much better workflow than:

Add console.log()
Add another console.log()
Add another console.log()

Practical Exercise

Use the React application we've been building.

Create:

function CourseCard({
  title,
  level
}: {
  title: string;
  level: string;
}) {
  return (
    <article>
      <h2>{title}</h2>
      <p>{level}</p>
    </article>
  );
}

Then:

function CourseList() {
  return (
    <>
      <CourseCard
        title="React"
        level="Advanced"
      />
      <CourseCard
        title="Spring Boot"
        level="Advanced"
      />
    </>
  );
}

Open React DevTools.

You should conceptually see:

CourseList
├── CourseCard
└── CourseCard

Select each CourseCard.

Inspect:

Props

You should see values such as:

title = React
level = Advanced

and:

title = Spring Boot
level = Advanced

Practical Exercise — State

Create:

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

Open React DevTools.

Select:

Counter

Click the button several times.

Observe the state changing.

Conceptually:

Initial
count = 0
Click
count = 1
Click
count = 2
Click
count = 3

This demonstrates runtime state inspection.

Practical Exercise — Profiler

Create a component:

function ExpensiveList() {
  const items = Array.from(
    { length: 1000 },
    (_, index) => index
  );
  return (
    <ul>
      {items.map((item) => (
        <li key={item}>{item}</li>
      ))}
    </ul>
  );
}

Then open:

Profiler

Record an interaction.

Observe which components render and how much time they consume.

The purpose isn't to optimize this artificial example.

The purpose is to learn:

How to measure rendering behavior.

Practical Exercise — Parent/Child Rendering

Create:

function Parent() {
  const [count, setCount] = useState(0);
  return (
    <>
      <button
        onClick={() => setCount(count + 1)}
      >
        {count}
      </button>
      <Child />
    </>
  );
}

And:

function Child() {
  return <div>Child</div>;
}

Use React DevTools/Profiler to observe what happens when the parent state changes.

This exercise prepares you for:

Re-rendering
Memoization
React.memo
useMemo
useCallback

which we'll study later.

Common Mistakes

Mistake 1: Using Only console.log

console.log() is useful, but don't use it as your only debugging strategy.

Use:

React DevTools
Browser DevTools
Network
Profiler

together.

Mistake 2: Assuming Every Re-render Is Bad

This is incorrect:

Re-render = Performance bug

React is designed to render.

The real question is:

Is the rendering work unnecessarily expensive?

Mistake 3: Optimizing Without Measuring

Don't immediately add:

memo
useMemo
useCallback

Measure first.

Mistake 4: Confusing React Tree With DOM Tree

React DevTools shows React components.

Browser DevTools shows the DOM.

They answer different questions.

Mistake 5: Treating Frontend Inspection as Security

Anything available to the browser should be considered inspectable.

Never trust React state for authorization.

Interview questions & answers

Senior Debugging Scenario

Scenario

Your manager says:

The course dashboard becomes very slow whenever I change the filter.

You shouldn't immediately say:

Let's add React.memo.

Instead:

Step 1

Reproduce:

Dashboard
   ↓
Change Filter
   ↓
Slow

Step 2

Use React Profiler:

Which components rendered?
Which consumed the most time?

Step 3

Inspect state:

Filter state
Course state
Pagination state

Step 4

Inspect Network:

Did changing the filter trigger
multiple API requests?

Step 5

Investigate rendering:

10,000 rows?
Expensive calculation?
Large chart?
Unnecessary child renders?

Step 6

Choose the solution.

Potential solutions might include:

Server-side filtering
Debouncing
Caching
Virtualization
Memoization
Code splitting
State restructuring

Step 7

Measure again.

This is the engineering mindset you should develop.

React DevTools + Architecture

React DevTools becomes much more valuable when your application has clear architecture.

For example:

App
│
├── AuthenticationProvider
│
├── Router
│
└── CoursePage
    │
    ├── CourseFilters
    ├── CourseList
    │   ├── CourseCard
    │   ├── CourseCard
    │   └── CourseCard
    │
    └── Pagination

Now you can reason about:

Ownership
Data flow
Rendering
State
Performance

This connects directly with our earlier folder-structure discussion.

Recommended Debugging Model

Whenever something goes wrong, think:

                  Problem
                     │
       ┌─────────────┼─────────────┐
       ▼             ▼             ▼
     React          API          Browser
       │             │             │
       ▼             ▼             ▼
  Components      Network         DOM
  Props           Request         CSS
  State           Response        Layout
  Hooks           Timing          Paint
       │             │             │
       └─────────────┼─────────────┘
                     ▼
                 Root Cause

React DevTools is primarily your React-side microscope.

Final Mental Model

Remember:

                    React Application
                           │
                           ▼
                  React Developer Tools
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
         Components       Props        State
              │            │            │
              └────────────┼────────────┘
                           ▼
                         Hooks
                           │
                           ▼
                       Profiler
                           │
                           ▼
                  Rendering Analysis

And combine it with browser tools:

React DevTools
      │
      ├── Components
      ├── Props
      ├── State
      ├── Hooks
      └── Profiler
               │
               ▼
       Browser DevTools
               │
       ├── Console
       ├── Network
       ├── DOM
       ├── CSS
       └── Performance

The most important principle is:

React Developer Tools turns the React application from a black box into an inspectable component system, allowing you to understand runtime state, component relationships, rendering behavior, and performance instead of debugging purely through guesswork.

Next Lesson

JSX Basics

Now we'll move from understanding React architecture and debugging to actually understanding the syntax used to build React UI:

JSX
 │
 ├── JSX Syntax
 ├── Expressions
 ├── JavaScript in JSX
 ├── Attributes
 ├── className
 ├── Events
 ├── Conditional UI
 ├── Fragments
 ├── JSX vs HTML
 └── JSX Compilation

The key mental model will be:

JSX
  ↓
React Element Description
  ↓
React Rendering
  ↓
DOM
  ↓
Browser UI

This is the foundation for understanding components, props, state, events, and rendering in the lessons that follow.