Every React component has a lifecycle.
A component is created, displayed on the screen, updated when its data changes, and eventually removed from the UI.
You can think of a React component’s lifecycle as a journey:
Mount → Update → Unmount
Understanding this journey makes it much easier to work with state, effects, API calls, event listeners, timers, and cleanup logic in React applications.
In this article, we’ll explore the React component lifecycle using modern React concepts and Hooks.
What Is the React Component Lifecycle?
The React component lifecycle describes the different stages a component goes through during its existence.
A component generally has three major stages:
1. Mounting
The component is created and added to the page.
2. Updating
The component changes because its state, props, or other relevant data has changed.
3. Unmounting
The component is removed from the page.
A simple way to visualize it is:
Component Created
↓
Mounting
↓
Updating
↓
Unmounting
Not every component updates frequently, but the lifecycle provides a useful mental model for understanding what React is doing.
1. Mounting: When a Component Appears
Mounting is the stage when React creates a component and places it into the user interface.
For example, when a user opens a dashboard, React might mount components such as:
- Navbar
- Sidebar
- Dashboard
- Profile Card
- Notification Panel
At this stage, React renders the component and displays its output.
What Happens During Mounting?
A simplified process looks like this:
Component → Render → DOM Update → Effects
The component determines what should appear on the screen, React updates the DOM, and effects can then run when appropriate.
useEffect and Mounting
In modern React, useEffect is commonly used for operations that need to happen after rendering.
For example, you might use an effect to:
- Fetch data
- Subscribe to an event
- Start a timer
- Connect to an external service
- Update something outside React
A common pattern is an effect with an empty dependency array:
useEffect(() => {
// Run after the component mounts
}, []);
The important idea isn’t the syntax itself.
It’s that the effect doesn’t need to run again because of changes to values listed in dependencies.
2. Updating: When Something Changes
After a component has been mounted, it can be updated.
Updates can happen for several reasons.
State Changes
A user clicks a button and a state value changes.
Props Change
A parent component passes different information to the child.
Parent Re-renders
A parent component renders again, which can cause its children to participate in rendering as well.
For example, consider a counter:
Count: 0
The user clicks a button.
Count: 1
The state changed, so React needs to determine what the UI should look like now.
This is part of the update lifecycle.
Rendering Doesn’t Always Mean DOM Changes
One important concept for React developers is that a component re-rendering does not necessarily mean the entire DOM is rebuilt.
When React renders a component, it calculates what the updated UI should look like.
React then compares the result with the previous version and applies the necessary changes to the actual DOM.
This process helps React update interfaces efficiently.
So you can think of it as:
State/Props Change → Render → React Compares → Necessary DOM Updates
useEffect During Updates
Effects can also run when specific values change.
For example, imagine a component displaying information for a selected user.
When the selected user changes, you may need to fetch new information.
Conceptually:
Selected User Changes
↓
Component
Updates
↓
Effect
↓
Fetch New Data
This is where the dependency array becomes important.
An effect can specify which values it depends on, allowing React to re-run the effect when those values change.
Understanding Effect Dependencies
Consider an effect that depends on a variable called userId.
useEffect(() => {
// Work with userId
}, [userId]);
The effect can run when the component is initially mounted and when userId changes.
This creates a relationship between the effect and its dependencies.
A useful way to think about it is:
“Run this effect when these values change.”
Choosing dependencies correctly is an important part of writing reliable React code.
3. Unmounting: When a Component Leaves
The third major lifecycle stage is unmounting.
Unmounting happens when React removes a component from the UI.
For example, imagine a modal:
Modal Open
↓
Component Mounted
↓
User Closes Modal
↓
Component Unmounted
When a component disappears, you may need to clean up resources associated with it.
This is where effect cleanup becomes especially important.
Cleanup in React
Some operations continue running even after a component is no longer visible.
Examples include:
- Timers
- Event listeners
- Subscriptions
- WebSocket connections
- External connections
If these aren’t cleaned up properly, they can cause unnecessary work or unexpected behavior.
React allows effects to return a cleanup function.
Conceptually:
useEffect(() => {
// Setup
return () => {
// Cleanup
};
}, []);
The cleanup function can run when the component is unmounted.
It can also run before an effect executes again when its dependencies have changed.
A Real-World Example: Event Listener
Imagine a component that listens for browser window events.
When the component appears, it adds an event listener.
When the component disappears, the listener should be removed.
The lifecycle looks like this:
Mount
→ Add listener
Update
→ Reconfigure if required
Unmount
→ Remove listener
This pattern prevents unnecessary listeners from remaining active after the component is gone.
A Real-World Example: API Requests
Data fetching is another common situation where lifecycle concepts are useful.
Imagine a product page.
When the page loads:
Mount → Fetch Product
When the selected product changes:
Update → Fetch New Product
When the component disappears:
Unmount → Stop or clean up related work when necessary
Modern React applications may use different approaches for data fetching depending on the framework and architecture, but understanding the lifecycle helps you understand when these operations happen.
React Lifecycle in Functional Components
Older React applications often used class components with lifecycle methods such as:
componentDidMountcomponentDidUpdatecomponentWillUnmount
These methods explicitly represented different lifecycle stages.
Modern React generally uses functional components and Hooks.
Instead of thinking only in terms of class lifecycle methods, developers commonly use useEffect for synchronizing a component with external systems.
This is one of the biggest shifts between older and modern React development.
Class Lifecycle vs Modern React
A simplified comparison looks like this:
| Class Components | Modern React |
|---|---|
componentDidMount | useEffect |
componentDidUpdate | useEffect with dependencies |
componentWillUnmount | Effect cleanup |
| Lifecycle methods | Hooks and effects |
However, it’s important not to treat useEffect as a direct one-to-one replacement for every class lifecycle method.
Modern React encourages developers to think about synchronization with external systems rather than simply assigning code to lifecycle stages.
The React Lifecycle Is More Than Three Steps
Mounting, updating, and unmounting are useful high-level concepts, but React’s rendering process is more detailed.
At a high level, React works through phases such as:
Trigger
Something causes React to render.
For example:
- State update
- Prop change
- Initial render
Render
React calls components and determines what the UI should look like.
Commit
React applies the required changes to the DOM.
Effects
Effects can run after the relevant rendering and commit work.
This distinction is useful because rendering should remain focused on calculating UI, while side effects belong in the appropriate effect or external mechanism.
Why You Should Avoid Side Effects During Rendering
A React component should ideally behave like a function that describes the UI based on its current inputs.
Rendering is not the right place to:
- Make API requests
- Add event listeners
- Start timers
- Modify external systems
These operations can produce unwanted behavior if they happen during rendering.
Instead, side effects should generally be handled through appropriate React mechanisms such as useEffect or other purpose-built APIs.
A useful rule is:
Render the UI during rendering. Synchronize with external systems through effects.
Common Lifecycle Mistakes
Understanding the lifecycle also helps avoid common problems.
1. Forgetting Cleanup
If you create an event listener, timer, or subscription and never remove it, the operation may continue longer than necessary.
Always consider whether an effect needs cleanup.
2. Using Effects for Everything
Not every piece of logic belongs inside useEffect.
For example, simple calculations based on props or state usually don’t require an effect.
Adding unnecessary effects can make components harder to understand.
3. Ignoring Dependencies
If an effect uses a value that can change, its dependency relationship needs to be considered carefully.
Incorrect dependencies can result in:
- Outdated data
- Effects running too often
- Effects not responding to changes correctly
4. Putting Expensive Work in Render
Rendering can happen more often than you might expect.
Expensive operations inside rendering can affect application performance.
Keep rendering focused and move appropriate work elsewhere.
React Strict Mode and Lifecycle Behavior
When developing React applications, you may sometimes notice effects running more than once in development.
This can happen with Strict Mode.
Strict Mode helps identify certain problems in applications by intentionally performing additional development-only checks.
This behavior can surprise beginners, especially when working with effects.
The important thing to remember is that development behavior can differ from production behavior.
If an effect doesn’t behave correctly when setup and cleanup happen repeatedly, that’s often a sign that the effect needs better cleanup or a clearer synchronization design.
How to Think About the Lifecycle
Instead of memorizing a long list of lifecycle methods, try thinking about a component in terms of these questions:
When does this component appear?
That’s the mounting stage.
What causes this component to change?
Usually props or state changes.
That’s the updating stage.
What happens when the component disappears?
That’s the unmounting stage.
Does the component interact with something outside React?
If yes, you may need an effect and cleanup.
This way of thinking is much more useful than simply memorizing lifecycle method names.
A Simple Lifecycle Example
Imagine a chat application.
When a chat room opens:
Mount
→ Connect to the chat service
While the user is in the room:
Update
→ Respond to changes such as the selected room
When the user leaves:
Unmount
→ Disconnect from the chat service
The complete flow looks like:
Open Chat Room
↓
Mount
↓
Connect
↓
Update
↓
Room Changes
↓
Reconnect
↓
Unmount
↓
Disconnect
This is a practical example of how lifecycle thinking applies to real applications.
Why React Lifecycle Knowledge Matters
You don’t need to memorize every lifecycle detail to become a good React developer.
What matters is understanding when and why something happens.
Lifecycle knowledge helps you:
- Handle API interactions correctly
- Manage subscriptions
- Clean up resources
- Understand re-renders
- Debug unexpected behavior
- Use
useEffectcorrectly - Build more predictable components
- Avoid unnecessary side effects
As React applications become larger, this understanding becomes increasingly valuable.
Final Thoughts
The React component lifecycle describes the journey of a component from creation to removal.
The three major stages are:
Mounting → Updating → Unmounting
Modern React uses functional components and Hooks, so you will often work with useEffect and cleanup functions instead of traditional class lifecycle methods.
The most important lesson is not to memorize lifecycle APIs. Instead, understand the flow:
A component renders UI, responds to changes, synchronizes with external systems when necessary, and cleans up when that work is no longer needed.
Once you understand this model, concepts like effects, API calls, subscriptions, timers, and component updates become much easier to reason about.
And that makes the React lifecycle less about memorization — and more about understanding how your application behaves.
