React Fundamentals: Components, JSX, State, and Re-rendering
I think I understood React a little backwards.
I started with the syntax.
I saw:
function App() {
return <h1>Hello World</h1>;
}
Okay.
Then I saw:
const [count, setCount] = useState(0);
Okay…
Then props.
Then components.
Then re-rendering.
And somehow I was learning all these things without really understanding why React was doing any of this.
I could write React code.
But if someone asked me:
"What problem is React actually solving?"
I probably wouldn't have given a very good answer.
So I decided to step back a little.
Instead of starting with useState() or JSX…
I wanted to understand what React was actually trying to make easier.
And that made the rest of the concepts much easier to understand.
The UI Is Not As Simple As It Looks
When we look at a website, it feels like one thing.
A page.
But it really isn't.
Take something like a dashboard.
You might have:
Navbar
Sidebar
User Profile
Stats
Charts
Tables
Notifications
Forms
Buttons
And all of these things can change.
The notification count changes.
The user updates their profile.
A chart gets new data.
A table gets filtered.
A menu opens.
A form value changes.
A modal appears.
None of these things are difficult individually.
That's what I thought too.
But then I started thinking about what happens when many of them change at the same time.
JavaScript Can Already Do This
This is where I originally got confused about React.
Because JavaScript can absolutely change the UI.
For example:
const button = document.getElementById("button");
const count = document.getElementById("count");
button.addEventListener("click", () => {
count.textContent = "1";
});
Done.
The browser updates.
So React isn't here because JavaScript can't update the page.
JavaScript can.
The problem is what happens when the application becomes much bigger.
Now you have many elements.
Many pieces of data.
Many events.
Many places that depend on the same data.
And suddenly you're spending a lot of time thinking about:
What changed?
Which element should change?
What should it become?
What else depends on this?
Did I update everything?
That was the problem I wasn't really seeing when I first started learning React.
Then I Started Looking At The UI Differently
Instead of thinking:
Something changed.
Now go find the element.
Now update it.
React encourages you to think more like:
Here is the current data.
Based on that data,
this is what the UI should look like.
That sounds like a small difference.
But it's actually a pretty big change in how you approach frontend code.
And I think this is where React started making sense for me.
Components Came First For Me
Once I understood that idea, components became easier.
A component is basically a piece of UI that we can build separately and reuse.
For example:
Navbar
Sidebar
UserProfile
ProductCard
Button
Footer
Instead of thinking about the entire application as one big page…
we can break it into smaller pieces.
For example:
App
├── Navbar
├── Dashboard
│ ├── Stats
│ ├── Chart
│ └── Activity
└── Footer
Now the application has some structure.
And this structure becomes more useful when the components start getting bigger.
A Component Is Not Just A Random Function
At first, I thought:
Okay.
So a component is just a function.
Technically, a function component is a function.
For example:
function Welcome() {
return <h1>Welcome</h1>;
}
But the important part isn't just the function.
The important part is that I'm creating a piece of UI that can be used somewhere else.
For example:
function App() {
return (
<div>
<Welcome />
</div>
);
}
And suddenly Welcome becomes part of the bigger UI.
That's where I started seeing components as building blocks.
Why Not Just One Big Component?
This is where things became practical.
Imagine I'm building a product page.
I could write everything inside:
ProductPage
Image.
Title.
Price.
Description.
Reviews.
Button.
Related products.
Cart logic.
Everything.
It might work.
For a while.
Then the component keeps growing.
And growing.
And eventually I open the file and think:
Where is the code for the product price?
That's not a great place to be.
So instead:
ProductPage
├── ProductImage
├── ProductInfo
├── ProductPrice
├── AddToCartButton
└── Reviews
Now each part has a job.
And if I need the same product card somewhere else…
I can reuse it.
That was one of the first React ideas that felt genuinely useful to me.
Then JSX Started Looking Less Weird
After components, JSX made more sense.
Before that, JSX looked strange.
Something like:
const element = <h1>Hello</h1>;
I remember thinking:
Why am I writing HTML inside JavaScript?
Because it looks like HTML.
But it isn't exactly HTML.
It's JSX.
And JSX gives us a convenient way to describe what the UI should look like.
For example:
function UserProfile() {
const name = "Sahil";
return (
<div>
<h1>{name}</h1>
<p>Welcome back!</p>
</div>
);
}
The {name} part is JavaScript.
The rest looks like markup.
And honestly…
that's what made JSX useful for me.
I can look at the component and almost immediately see the UI it's describing.
JSX Is Not HTML
This was another small thing I had to get used to.
JSX looks like HTML.
But there are differences.
For example:
<div className="card">
instead of:
<div class="card">
And you have things like JavaScript expressions inside {}.
So I stopped thinking:
JSX = HTML
and started thinking:
JSX = a way to describe React UI using a syntax that looks familiar.
That was much easier.
But The Browser Doesn't Understand JSX
Then naturally…
another question.
If JSX isn't normal JavaScript…
how is the browser running it?
The simple version is:
JSX
↓
Transformed
↓
JavaScript
↓
Browser
The tooling transforms JSX into JavaScript.
I didn't need to understand every detail of the transformation to continue learning React.
I just needed to know what was happening at a high level.
And that was enough.
Then Came Props
Now I had components.
But there was another problem.
What if I want the same component to show different data?
Take a product card.
I don't want to create:
MacBookCard
MonitorCard
KeyboardCard
MouseCard
I want one component.
Something like:
function ProductCard({ name, price }) {
return (
<div>
<h2>{name}</h2>
<p>₹{price}</p>
</div>
);
}
And then:
<ProductCard
name="MacBook"
price="99999"
/>
<ProductCard
name="Monitor"
price="12000"
/>
Same component.
Different data.
That's props.
Parent To Child
The easiest way I started remembering props was:
Parent
↓
Props
↓
Child
The parent gives information to the child.
For example:
function App() {
return (
<UserProfile name="Sahil" />
);
}
And:
function UserProfile({ name }) {
return <h2>{name}</h2>;
}
name came from the parent.
The child uses it.
That's basically the idea.
Props And State Were Where I Got Confused
This was probably the part where I had to slow down.
Because both props and state contain data.
So I started asking:
What's actually different?
The mental model that helped me was:
Props
↓
Data coming into the component
State
↓
Data managed by the component
Props are given to the component.
State is something the component can remember and update.
That distinction made things much easier.
State
A simple example is a counter.
import { useState } from "react";
function Counter() {
const [count, setCount] = useState(0);
return (
<button onClick={() => setCount(count + 1)}>
{count}
</button>
);
}
Start:
0
Click:
1
Click again:
2
Pretty simple.
But the interesting question isn't the counter.
It's:
Why does the UI change?
Why Can't I Just Use A Variable?
I could do:
let count = 0;
Then:
count++;
The variable changed.
But React isn't automatically told:
"Hey, the UI needs to change."
That's the difference.
When I use:
setCount(count + 1);
I'm updating React state.
Now React knows something changed.
And that leads to re-rendering.
Re-rendering
The word sounded more complicated than it actually is.
I initially thought:
React is rebuilding the entire page.
Every time state changes.
That didn't sound very good.
The better mental model is:
State changes
↓
Component renders again
↓
React works out the UI
↓
The screen updates
So if:
count = 0
the component produces UI showing:
0
Then:
setCount(1);
The component renders again.
Now the UI represents:
1
That's basically the cycle.
State Is Connected To The UI
This was probably the most important thing I understood.
State isn't just some variable sitting somewhere.
The UI can depend on it.
For example:
isMenuOpen = true
Maybe we show a menu.
If:
isMenuOpen = false
we don't.
Or:
liked = true
might show:
Unlike
while:
liked = false
shows:
Like
So:
State
↓
UI
Change the state…
and the UI can change.
That is where React started feeling much more logical to me.
Props Can Affect Rendering Too
State isn't the only thing.
Props can change too.
For example:
<UserProfile name="Sahil" />
Later:
<UserProfile name="Rahul" />
The component received different data.
So it needs to render using the new value.
That's why I started thinking about React as:
Props + State
↓
Component
↓
UI
If the data changes…
React can render the UI again.
Declarative UI
Then I came across the word:
Declarative.
At first I thought this was going to be another complicated React concept.
It wasn't.
Think about DOM manipulation.
You might say:
Find this element.
Change its text.
Hide this.
Show that.
Add a class.
You're telling the browser how to do it.
That's imperative.
React lets me think more like:
If user is logged in,
show Dashboard.
Otherwise,
show Login.
For example:
function App({ loggedIn }) {
return loggedIn
? <Dashboard />
: <Login />;
}
I'm describing what the UI should look like.
I'm not manually changing the DOM.
That's what finally made the word "declarative" less scary.
The Component Tree
As I started putting components together, another thing became obvious.
They form a tree.
Something like:
App
├── Navbar
├── Dashboard
│ ├── Profile
│ ├── Stats
│ │ ├── Card
│ │ ├── Card
│ │ └── Card
│ └── Activity
└── Footer
There is a parent.
There are children.
Those children can have their own children.
And now props make even more sense.
Data can move down:
App
↓
Dashboard
↓
Profile
Through props.
That parent-child relationship becomes really important when an application gets bigger.
Thinking In Components
I think this is one of the biggest things React changed for me.
Before:
"I need to build this page."
Now:
"What are the pieces of this page?"
For example, a social media application:
App
├── Navbar
├── Feed
│ ├── Post
│ ├── Post
│ └── Post
├── Sidebar
└── Profile
An e-commerce application:
App
├── Navbar
├── ProductList
│ ├── ProductCard
│ ├── ProductCard
│ └── ProductCard
└── Cart
A dashboard:
App
├── Sidebar
├── Header
└── Dashboard
├── Stats
├── Chart
└── Table
Now instead of thinking about one huge UI…
I'm thinking about smaller pieces.
And that's a much better way for me to understand React.
Some Mistakes I Made
Of course…
I didn't understand everything correctly the first time.
Mutating State Directly
One mistake is doing:
count = count + 1;
instead of:
setCount(count + 1);
The second one tells React that the state has changed.
That distinction matters.
Treating Props And State The Same
I already mentioned this one.
But it was genuinely confusing.
The simple version I remember now:
Props
→ Comes from the parent
State
→ Managed by the component
That makes the difference much easier to remember.
Making Everything State
Another mistake is thinking:
"If this value exists, I'll put it in state."
Not everything needs state.
Sometimes a value can just be calculated.
For example:
const total = price * quantity;
I don't necessarily need another state variable just to store total.
Otherwise I'm storing the same information in multiple places.
And that can create more problems.
Creating Huge Components
This is another easy trap.
You create:
Dashboard.jsx
Then everything goes inside.
Navbar.
Cards.
Charts.
Tables.
Modals.
Forms.
Logic.
And suddenly the component is huge.
I've learned that components are useful when they help separate responsibilities.
Not because every tiny piece of JSX needs its own component.
There's a balance.
One Small Example That Connected Everything
Imagine a profile component.
It receives the user's name.
That's props.
It needs to remember whether the user followed the profile.
That's state.
Something like:
function UserProfile({ name }) {
const [followed, setFollowed] = useState(false);
return (
<div>
<h2>{name}</h2>
<button onClick={() => setFollowed(!followed)}>
{followed ? "Following" : "Follow"}
</button>
</div>
);
}
Now I can see all the pieces together.
name comes from outside.
That's props.
followed belongs to this component.
That's state.
Clicking the button changes the state.
React renders the component again.
The button now shows something different.
And I didn't manually find the button and change its text.
I described what it should show based on the state.
That small example made a lot of React concepts connect for me.
What Finally Made React Click
I think I was initially trying to learn React as a list of things.
JSX.
Components.
Props.
State.
Re-rendering.
But they're not really separate.
They connect.
I started thinking about it like this:
Components
↓
JSX describes the UI
↓
Props bring data in
↓
State stores changing data
↓
Data changes
↓
Component renders again
↓
UI reflects the new data
And once I had this picture in my head…
the individual concepts became much easier.
I didn't need to memorize them as isolated definitions anymore.
React Is More About A Way Of Thinking
I think this is the biggest thing I took away from learning the basics.
React isn't just:
A library
+
JSX
+
useState()
It's a different way of thinking about UI.
Instead of constantly asking:
"What DOM element do I need to change?"
I can ask:
"What should the UI look like when the data is like this?"
That's a much more useful question.
Quick Recap
JavaScript can already manipulate the DOM.
React becomes useful when UI complexity starts growing.
React encourages breaking UI into reusable components.
JSX gives us a convenient way to describe UI.
Components can receive data through props.
Props generally flow from parent to child.
Props should be treated as read-only.
State is data managed by a component.
State changes can cause a component to render again.
Props changes can also affect what a component displays.
React encourages a declarative approach.
Components form a parent-child tree.
Not everything needs to be state.
Not every piece of JSX needs to become a component.
Good component structure becomes more important as applications grow.
That's the foundation I wanted before moving into more advanced React topics.
Conclusion
I started React with a pretty simple thought:
"JavaScript already works. Why do I need React?"
I think I understand the answer much better now.
React isn't here because JavaScript can't build interfaces.
It can.
The problem is managing a UI when there are lots of things changing and lots of pieces depending on data.
React gives me a way to break the UI into components.
Props let those components receive information.
State lets components remember things that can change.
And when that data changes, React can render the component again and bring the UI in line with the current state.
The biggest shift for me was actually this:
Before:
"How do I change this element?"
Now:
"What should this UI look like with the current data?"
That feels like a small difference.
But I think that's the part that actually separates writing React code from just learning React syntax.
And honestly…
I'm still learning React.
But these fundamentals finally give me a proper place to start.
If you like this simple learning-style explanation, I write more notes at devwithsahil.hashnode.dev and share my progress on LinkedIn 🙂
#react #reactjs #javascript #frontend #webdevelopment
