# React Fundamentals: Components, JSX, State, and Re-rendering
JavaScript has always been capable of changing web pages. You can select an element, update its text, change a class, hide a button, or create new elements using the DOM.
So why did developers need React?
The short answer is **complexity**.
As web applications became more interactive, managing the DOM manually became increasingly difficult.
A modern application might have navigation, forms, notifications, user profiles, product cards, dashboards, filters, modals, and dozens of interactive elements, all changing based on user actions and application data.
React introduced a different way to think about this problem:
> **Instead of manually telling the browser how to update the UI, describe what the UI should look like for a particular state, and let React handle the updates.**
That idea leads to several fundamental React concepts:
**JSX → Components → Props → State → Re-rendering**
Understanding these concepts is more important than memorizing React APIs. Once the mental model is clear, React becomes much easier to learn.
## 1\. Why Does React Exist?
Before React, developers commonly manipulated the DOM directly using JavaScript or libraries built around DOM manipulation.
For example, imagine a simple counter:
```html
0
```
You could update it with JavaScript:
```javascript
let count = 0;
document
.getElementById("increment")
.addEventListener("click", () => {
count++;
document.getElementById("count").textContent = count;
});
```
This works perfectly well for a small example.
But imagine an application with hundreds of UI elements that depend on one another.
A user updates their profile.
That might affect:
* the profile section
* navigation
* account information
* comments
* posts
* notifications
* sidebar information
With manual DOM manipulation, developers have to keep track of **what changed, which elements need updating, and when those updates should happen**.
> `As applications grow, this becomes difficult to reason about.`
### The traditional approach
A simplified mental model looks like this:
```text
User Action
↓
JavaScript Event
↓
Find DOM Element
↓
Change DOM
↓
Find Another Element
↓
Change Another DOM Element
↓
Keep Everything in Sync
```
The developer is responsible for managing the UI changes.
### The React approach
React encourages a different model:
```text
Application State
↓
React
↓
UI Output
```
When the state changes, React determines what needs to be updated.
### Why React became popular
React became popular because it provided a practical solution to several problems involved in building complex interfaces:
* reusable components
* predictable data flow
* declarative UI
* state-driven rendering
* easier organization of large applications
* a component-based mental model
React did not make JavaScript unnecessary.
Instead, it provided a better way to **structure UI logic using JavaScript**.
![](https://cdn.hashnode.com/uploads/covers/67f6938ae40bfe8436125463/15d87c9a-d289-419b-9129-ca23711e6e1e.png align="center")
## 2\. Understanding JSX
One of the first things you notice when learning React is code like this:
```jsx
function Welcome() {
return
Hello, React!
;
}
```
At first glance, this looks like HTML inside JavaScript.
It is not exactly HTML.
> It is **JSX**.
### What is JSX?
JSX is a syntax extension that allows developers to write **UI-like markup inside JavaScript.**
For example:
```jsx
const element =
Hello, React!
;
```
JSX makes it easier to describe what the UI should look like.
Instead of separating all markup and logic into completely different places, JSX lets a component express its structure and related logic together.
### Why was JSX introduced?
JavaScript can create UI without JSX:
```javascript
const heading = React.createElement(
"h1",
null,
"Hello, React!"
);
```
> This is valid, but it is harder to read.
The JSX version is much easier to understand:
```jsx
const heading =
Hello, React!
;
```
JSX provides a more natural way to describe UI.
It also becomes particularly useful when the UI contains JavaScript logic.
### JSX vs HTML
JSX looks similar to HTML, but there are important differences.
For example, HTML commonly uses:
```html
```
In JSX, you typically write:
```jsx
```
Another example is JavaScript expressions.
```jsx
const name = "Aisha";
return
Hello, {name}!
;
```
The `{}` tells JSX:
> "Evaluate this as JavaScript."
### Embedding JavaScript inside JSX
You can place **JavaScript expressions** inside JSX using curly braces.
```jsx
const username = "Rahul";
const age = 24;
return (
{username}
Age: {age}
);
```
You can also use expressions:
```jsx
const isLoggedIn = true;
return (
{isLoggedIn ? "Welcome back!" : "Please log in"}
);
```
This is one of the important ideas behind JSX:
> `JSX describes the UI while still giving you access to JavaScript expressions.`
### How JSX gets compiled
Browsers do not directly understand JSX syntax.
A build tool transforms JSX into regular JavaScript.
Conceptually:
```text
JSX
↓
JSX Compiler / Transpiler
↓
JavaScript
↓
Browser
```
For example:
```jsx
Hello
```
is transformed into JavaScript representing that UI element.
The exact transformation depends on the React tooling and JSX runtime being used, but the important beginner-level idea is:
> `JSX is developer-friendly syntax that gets transformed into JavaScript before the browser executes it.`
![](https://cdn.hashnode.com/uploads/covers/67f6938ae40bfe8436125463/74e7ad88-f8d5-461f-aea5-0fc6b19fc5f0.png align="center")
## 3\. Components in React
If JSX describes UI, **components are the building blocks used to organize that UI**.
> A component is a reusable piece of interface and its associated logic.
For example, a social media application might contain:
```text
App
├── Navbar
├── Profile
├── PostList
│ ├── Post
│ ├── Post
│ └── Post
└── Footer
```
Each part can become a component.
### Function components
Modern React applications commonly use function components.
```jsx
function Welcome() {
return
Welcome to React!
;
}
```
A component is simply a JavaScript function that returns UI.
You can then use it like a custom element:
```jsx
function App() {
return (
);
}
```
The same component can be reused multiple times.
### Components are reusable UI building blocks
Imagine an e-commerce application.
Instead of writing the markup for every product manually:
```text
Product A
Product B
Product C
Product D
```
you create a reusable `ProductCard` component.
```jsx
function ProductCard() {
return (
Wireless Headphones
$99
);
}
```
Then React can render multiple product cards.
The next step is making the component dynamic using **props**.
### Component composition
Components can be combined to create larger components.
For example:
```text
Dashboard
├── Header
├── Sidebar
├── DashboardContent
│ ├── RevenueCard
│ ├── UsersCard
│ └── SalesChart
└── Footer
```
> This is called **component composition**.
Instead of building one massive component, you combine smaller components.
This makes applications easier to:
* understand
* maintain
* test
* reuse
* modify
### Breaking large UIs into smaller pieces
A useful question when building a React interface is:
> "What independent pieces of UI can I identify?"
For a user profile, you might have:
```text
UserProfile
├── Avatar
├── UserInfo
├── FollowButton
└── Stats
```
Each piece has a clear responsibility.
This is one of the most important habits to develop as a React developer.
![](https://cdn.hashnode.com/uploads/covers/67f6938ae40bfe8436125463/9dbe5c3a-83e6-4e7d-b468-b73058e399a0.png align="center")
## 4\. Props in React
Components become much more useful when they can receive data.
> This is where **props** come in.
Props are values passed from one component to another, usually **from a parent component to a child component.**
For example:
```jsx
function UserProfile({ name }) {
return
{name}
;
}
```
A parent can provide the value:
```jsx
function App() {
return ;
}
```
The child receives:
```text
name = "Aisha"
```
and renders it.
### Props represent communication
Think of props as a way for a parent component to provide information to a child.
```text
Parent
|
| props
↓
Child
```
For example:
```jsx
function ProductCard({ name, price }) {
return (
{name}
${price}
);
}
```
Now the same component can represent different products:
```html
```
One component, multiple pieces of data.
That is the power of reusable components.
### Props are read-only
A child component should treat its props as **read-only.**
For example, this is not the right mental model:
```jsx
function User({ name }) {
name = "Another Name";
}
```
> The child should not modify the value it received from its parent.
Instead, if something needs to change, that change should generally be represented through state owned by the **appropriate component.**
### Parent → child communication
A common React data flow looks like this:
```text
Parent
|
| data through props
↓
Child
```
For example:
```jsx
function App() {
const username = "Aisha";
return ;
}
```
The parent owns the value and passes it down.
This predictable direction of data flow makes applications easier to reason about.
![](https://cdn.hashnode.com/uploads/covers/67f6938ae40bfe8436125463/3debda05-81ad-4905-a58b-4b37931e03f1.png align="center")
## 5\. State in React
Props allow components to receive data.
But what happens when a component needs to **remember something that can change**?
> That's where **state** comes in.
**State** represents data that belongs to a component and can change over time.
Examples include:
* whether a menu is open
* the current counter value
* text entered into a form
* whether a button is selected
* the current page in a UI
* whether a user has liked a post
### Why does state exist?
Consider a counter.
The component needs to remember the current count:
```text
Count: 0
```
When the user clicks the button:
```text
Count: 1
```
Then:
```text
Count: 2
```
The component needs some form of persistent data between renders.
> React provides state for this purpose.
A simple example is:
```jsx
import { useState } from "react";
function Counter() {
const [count, setCount] = useState(0);
return (
Count: {count}
);
}
```
For this article, you don't need to memorize every detail of `useState`.
The important mental model is:
```text
State
↓
UI
```
When state changes:
```text
New State
↓
React renders UI again
↓
Updated UI
```
### Local component state
**State** is often local to the component that needs it.
For example, a dropdown might need to know whether it is open:
```jsx
function Dropdown() {
const [isOpen, setIsOpen] = useState(false);
// ...
}
```
The dropdown can manage its own **state** without forcing unrelated components to know about it.
This is one reason component-based architecture works so well.
### State updates
You should update **state** using the state setter rather than changing the **state** variable directly.
Avoid:
```jsx
count = count + 1;
```
Instead:
```jsx
setCount(count + 1);
```
**Why?**
Because React needs to know that the component's state has changed so **it can schedule the appropriate UI update.**
### State-driven UI
A useful React mental model is:
> **The UI is a representation of the current state.**
For example:
```text
isLoggedIn = true
↓
Show Dashboard
```
While:
```text
isLoggedIn = false
↓
Show Login Page
```
You are not necessarily thinking:
> "Find the dashboard element and hide it."
Instead, you think:
> "If the user is logged in, the UI should contain the dashboard."
That difference is at the **heart of React.**
## 6\. Understanding Re-rendering
**Re-rendering** is one of the concepts beginners often find ***confusing***.
A re-render does **not** simply mean:
> "React destroys the entire webpage and creates it again."
Instead, React calls components again to determine what the UI should look like based on the current inputs, such as **state and props**, and then **updates the rendered result as needed.**
### What causes a re-render?
Several things can cause a component to render again.
Two *important* ones for beginners are:
**1\. State changes**
```jsx
setCount(count + 1);
```
> A state update can cause the component to render again.
**2\. Parent renders with changed inputs**
When a parent component renders, React may also ***render*** its child components as part of evaluating the component tree.
Props can also change when the **parent provides different values**.
For example:
```jsx
```
If `username` changes, the child receives a different prop value.
### State change → UI update
Imagine a like button:
```text
liked = false
```
The UI displays:
```text
♡ Like
```
The user clicks it.
State changes:
```text
liked = true
```
React renders based on the new state.
The UI becomes:
```text
♥ Liked
```
The developer doesn't need to manually search for the button and replace its text.
![](https://cdn.hashnode.com/uploads/covers/67f6938ae40bfe8436125463/497aa77a-48b8-4e8c-937e-4eb4ea89c024.png align="center")
### A high-level view of the component lifecycle
At a beginner level, you can think about a component in three broad stages:
```text
Component appears
↓
Component renders
↓
Data/state changes
↓
Component renders again
↓
Component eventually leaves the UI
```
React has more detailed lifecycle behavior, but beginners don't need to **memorize** every lifecycle phase to understand the fundamental rendering model.
The important idea is that **React keeps the UI synchronized with the component's current data**.
## 7\. React's Declarative Nature
One of React's biggest ideas is **declarative programming**.
To understand React, it helps to compare declarative and imperative approaches.
### Imperative programming
Imperative programming focuses on **how** to perform a task.
Imagine a button that should display different text depending on whether a user has liked a post.
An imperative approach might look conceptually like:
```text
When the user clicks:
find the button
check its current text
change the text
change the class
update the icon
```
You are explicitly telling the program how to manipulate the UI.
### Declarative programming
React encourages you to describe **what the UI should look like**.
For example:
```jsx
function LikeButton({ liked }) {
return (
);
}
```
You describe the relationship:
```text
liked = true
↓
show "♥ Liked"
liked = false
↓
show "♡ Like"
```
You don't manually manipulate the DOM for every state transition.
### Why declarative rendering helps
Declarative UI has several advantages:
* **Easier reasoning**
You can look at a component and ask:
> "What should this UI look like given these values?"
* **Fewer manual DOM operations**
React handles the relationship between rendered output and the underlying UI.
* **More predictable updates**
When state changes, the component describes what the new UI should be.
* **Better component reuse**
Components can be designed around inputs and outputs instead of specific DOM manipulation steps.
![](https://cdn.hashnode.com/uploads/covers/67f6938ae40bfe8436125463/5c7f110c-258d-40c1-86f3-532086b859c5.png align="center")
## 8\. Component Tree Architecture
React applications are naturally organized as **trees**.
At the **top**, you typically have a **root component.**
That component contains other components, which contain more components.
For example:
```text
App
├── Header
│ ├── Logo
│ └── Navigation
├── Main
│ ├── Dashboard
│ │ ├── RevenueCard
│ │ ├── UsersCard
│ │ └── ActivityCard
│ └── RecentPosts
│ ├── Post
│ └── Post
└── Footer
```
> This structure is called the **component tree**.
### Parent components
A parent component renders one or more child components.
```jsx
function Dashboard() {
return (
);
}
```
Here, `Dashboard` is the parent.
`RevenueCard` and `UsersCard` are children.
### Child components
A child is a component rendered by another component.
Children should generally focus on their own responsibilities.
For example:
```jsx
function UsersCard({ totalUsers }) {
return
Users: {totalUsers}
;
}
```
The component doesn't need to know where `totalUsers` originally came from.
> It simply receives the value through props.
### Data flow
React generally encourages data to flow downward:
```text
App
↓
Dashboard
↓
UsersCard
```
For example:
```text
App
|
| users
↓
Dashboard
|
| users
↓
UsersCard
```
This predictable flow helps developers understand where data comes from.
### Component hierarchy and application structure
When an application grows, the component tree can become large.
That isn't necessarily a **problem.**
The goal isn't to have as few components as possible.
The goal is to create **clear boundaries and responsibilities**.
A good component often answers one clear question:
> "What part of the interface does this component own?"
![](https://cdn.hashnode.com/uploads/covers/67f6938ae40bfe8436125463/c6410ae8-3eb3-4a4a-9d53-a475274ef8b1.png align="center")
## 9\. Common Beginner Mistakes
React's concepts are simple individually, but beginners often combine them incorrectly.
Here are some common mistakes to watch for:
* **Mistake 1: Mutating state directly**
Avoid directly changing state:
```jsx
count = count + 1;
```
Use the state updater:
```jsx
setCount(count + 1);
```
State updates need to go through **React's state mechanism.**
* **Mistake 2: Confusing props and state**
A useful distinction is:
### Props
Data provided **to** a component.
```text
Parent → Child
```
### State
Data managed by a component that can change over time.
```text
Component → State → UI
```
A simple mental model:
> **Props are inputs. State is changing component data.**
* **Mistake 3: Putting everything into state**
Not every value needs to be state.
Suppose you have:
```jsx
const firstName = "Aisha";
const lastName = "Sharma";
```
You don't necessarily need state just because these values appear in the UI.
**State** is useful when the value needs to change and that change should **cause the UI to update.**
Ask:
> "Does this value need to change over time and affect rendering?"
If not, it may not need to be **state**.
* **Mistake 4: Creating huge components**
A component containing hundreds of lines of unrelated UI and logic becomes difficult to maintain.
Instead of:
```text
HugeDashboard
├── everything
├── everything
├── everything
└── everything
```
consider:
```text
Dashboard
├── Header
├── Sidebar
├── Stats
├── Activity
└── RecentOrders
```
Smaller components can be easier to understand and reuse.
* **Mistake 5: Poor component organization**
Creating components is not enough.
They should also have **meaningful responsibilities.**
Avoid splitting an application into dozens of tiny components simply because "small components are always better."
The goal is **useful boundaries**, not maximum fragmentation.
A component should ideally have a clear purpose.
## 10\. Building Applications with Components
Once you understand JSX, components, props, state, and rendering, you can start thinking about React applications differently.
Instead of beginning with:
> "Which HTML elements do I need?"
try asking:
> "What are the major pieces of this interface?"
### Think in components
Imagine you are building a social media application.
You might identify:
```text
SocialApp
├── Navbar
├── Sidebar
├── Feed
│ ├── CreatePost
│ ├── Post
│ ├── Post
│ └── Post
└── ProfileSidebar
```
Each part can have a responsibility.
For example:
* `Navbar`: Handles navigation and account-related controls.
* `Post`: Displays a single social media post.
* `CreatePost`: Handles the interface for creating a post.
* `ProfileSidebar`: Displays information about the current user.
This makes the overall application easier to reason about.
### Reusable design patterns
Suppose you create:
```jsx
function Card({ title, description }) {
return (
{title}
{description}
);
}
```
Now the same component can be used in many places:
```jsx
```
The **component** defines the structure.
**Props** provide the changing data.
This separation is extremely powerful.
### Component composition
Large applications are built by combining smaller components.
> Think of it like building with LEGO.
![](https://cdn.hashnode.com/uploads/covers/67f6938ae40bfe8436125463/2a693f0c-89fe-4f4d-b033-1f704f285f99.png align="center")
For example:
```text
Button
↓
ProductCard
↓
ProductGrid
↓
ProductPage
↓
E-commerce Application
```
Each level builds on the previous one.
### Component architecture
Good **architecture** isn't about following one **perfect folder structure.**
It's about keeping responsibilities clear.
A growing application might eventually organize components conceptually like:
```text
src/
├── components/
│ ├── Button
│ ├── Card
│ └── Navbar
│
├── features/
│ ├── auth/
│ ├── products/
│ └── dashboard/
│
├── pages/
│ ├── Home
│ ├── Profile
│ └── Settings
│
└── App
```
**The exact structure can vary between projects.**
The principle is more important than the folders:
> **Organize code around clear responsibilities and reusable pieces of UI.**
### Scaling React applications
As applications become larger, you will eventually encounter more advanced topics:
* shared state
* routing
* server communication
* forms
* error handling
* performance optimization
* testing
* accessibility
* advanced hooks
But these topics become much easier when the **fundamentals are solid.**
Before worrying about optimization, **first understand:**
```text
JSX
↓
Components
↓
Props
↓
State
↓
Rendering
↓
Component Architecture
```
That **foundation** is what everything else builds upon.
## 11\. The Most Important React Mental Model
If you remember only one idea from this article, remember this:
> **React lets you describe what the UI should look like based on data, rather than manually describing every DOM change.**
You can visualize the relationship as:
```text
Props
↓
┌─────────────┐
State → │ Component │
└─────────────┘
↓
JSX
↓
Rendered UI
```
When state or relevant inputs change:
```text
State / Props Change
↓
Component Renders
↓
React Evaluates UI
↓
Necessary UI Updates
```
> This is the foundation of React's declarative approach.
## 12\. React as a Way of Thinking
React is not just a library where you memorize syntax.
It introduces a different way of thinking about interfaces.
Instead of asking:
> "How do I change this DOM element?"
you start asking:
> "What should this component display when its data looks like this?"
Instead of asking:
> "How can I reuse this HTML?"
you ask:
> "Can this interface become a reusable component?"
Instead of asking:
> "Where should I manually update the UI?"
you ask:
> "What state should represent this UI?"
And instead of building one giant page, you start seeing the application as a collection of components:
```text
Application
↓
Pages
↓
Sections
↓
Components
↓
Smaller Components
```
That shift in thinking is one of the most valuable things React teaches.
![](https://cdn.hashnode.com/uploads/covers/67f6938ae40bfe8436125463/8a38e855-4566-41a4-92ba-36a6a2bfe6b9.png align="center")
## 13\. A Beginner's React Checklist
Before moving into advanced React topics, make sure you can explain these questions in your own words:
* What problem does React solve?
* What is JSX?
* How is JSX different from HTML?
* What is a component?
* Why are components useful?
* What are props?
* Why are props read-only?
* What is state?
* When should something be state?
* What causes a component to render again?
* How are props and state different?
* What does "declarative UI" mean?
* What is a component tree?
* How does data flow through a React application?
* Why should large components be broken into smaller pieces?
> If you can answer these questions without simply memorizing definitions, you have a strong React foundation.
## Final Takeaway
**React's** fundamentals can be summarized in a simple progression:
* **JSX :** Describe what the UI should look like.
* **Components :** Break the UI into small, reusable pieces.
* **Props :** Pass data from one component to another.
* **State :** Store and manage data that can change.
* **Re-rendering :** React updates the UI when state or props change.
* **Component Architecture :** Organize components to build scalable applications.
* **Mental Model :** The real power of React is understanding how components, props, state, and data flow work together.
* **Foundation for Advanced React :** Once these fundamentals become natural, more advanced React concepts become easier to understand.
![](https://cdn.hashnode.com/uploads/covers/67f6938ae40bfe8436125463/8750aff9-d26c-4b2a-a7fe-3bab9051360f.png align="center")
## One Sentence to Remember
> **React is a way to build user interfaces by composing reusable components and describing how those interfaces should look** based **on their current props and state.**
## In closing
I hope that you’ve found this blog on “React Fundamentals: Components, JSX, State, and Re-rendering” helpful...!
That's all for today! 😁 You reached the end of the article 😍.