Bismay.exe

Posted on Jul 13

🚀 Day 7 of Learning React: How Do Components Share Data? Understanding Lifting State Up

#react #javascript #webdev #beginners

📌 Missed Day 6? I explored how React renders components, why immutable updates matter, how HMR works behind the scenes, and different approaches to handling forms. You can **read it here* and then come back. I'll wait. ☕️*

Bismay.exe

Jul 2

🚀 Day 6 of Learning React: The Day React's Rendering Finally Started Making Sense (HMR, Bundlers & Form Handling)

#react #javascript #webdev #beginners

8 min read

Yesterday, I spent most of my time learning how React updates the UI.

Today, I ran into a completely different problem.

I had a registration form.

I also had a list of user cards.

Whenever someone filled out the form and clicked Register, I wanted a new user card to appear automatically.

Sounds simple...

Except there was one problem.

The form and the user cards lived in different components.

That's when I learned one of React's most important patterns:

Lifting State Up.

Let's dive in. 🚀

🧠 Quick Recap

Yesterday's big question was:

How does React know when something should be re-rendered?

Here's what I took away from Day 6:

🛍️ map() helps render multiple components from data.
🔄 React prefers immutable updates.
📝 Forms become much cleaner when using a single reusable change handler.
🚫 DRY (Don't Repeat Yourself) makes React code easier to maintain.

Today we're answering a different question:

How do two components share the same data? 🤔

🏗️ The Project

Today's project looked something like this.

App
├── Register
└── UserCard

The Register component collected user information.

The UserCard component displayed all registered users.

Pretty straightforward.

At first, I thought these two components could somehow communicate with each other directly.

They can't.

That misunderstanding was the beginning of today's lesson.

🤔 The Problem

Inside my Register component, I already had state.

const [formData, setFormData] = useState({
  name: "",
  email: "",
  password: "",
  image: "",
});

Submitting the form updated formData perfectly.

But another question appeared.

How does UserCard know a new user was registered?

It doesn't.

Because UserCard has absolutely no access to Register's state.

That state belongs only to the Register component.

🚫 Sibling Components Can't Read Each Other's State

This was probably the biggest realization of today's class.

Both components were children of the same parent.

App
├── Register
└── UserCard

That makes them siblings.

And sibling components cannot directly access each other's state.

For a while, I kept thinking there must be some way for one component to "look inside" another.

There isn't.

React doesn't work like that.

💡 The Solution Was Surprisingly Simple

Instead of trying to make the two components communicate...

I moved the shared state up.

From this:

Register
└── users state

To this:

App
├── users state
├── Register
└── UserCard

That small change solved everything.

And that's exactly why this pattern is called:

Lifting State Up.

We're simply moving shared state to the nearest common parent.

📦 The Parent Owns the State

Instead of storing users inside Register, I stored them inside App.

const [users, setUsers] = useState([]);

Now App became the single source of truth.

Instead of owning the users...

The child components simply used them.

📨 Props Started Making Much More Sense

Once the state lived inside App, everything connected beautifully.

Register received the updater function.

<Register setUsers={setUsers} />

Whenever someone submitted the form,

Register simply called:

setUsers((prev) => [...prev, formData]);

It wasn't updating its own state anymore.

It was asking App to update the shared state.

That tiny detail completely changed how I think about props.

They're not just for sending data.

They can also send functions.

🪄 Where Did the New User Card Come From?

This was my favorite part.

I never manually created a new card.

Instead, App rendered the cards like this:

{
  users.map((elem) => (
    <UserCard
      key={elem.email}
      user={elem}
    />
  ));
}

As soon as users changed...

React rendered another UserCard.

No DOM manipulation.

No extra logic.

Just a state update.

That pattern is becoming more and more familiar every day.

💡 My Mental Model

Here's how I visualize today's lesson.

User Fills Form
        ↓
Register Calls setUsers()
        ↓
App Updates users State
        ↓
App Re-renders
        ↓
Updated users Passed to UserCard
        ↓
New User Card Appears ✨

That flow made today's topic click for me.

🤝 Why Lift the State?

At first, moving state to another component felt unnecessary.

But after today's project, it actually made perfect sense.

Now there is:

✅ One place where the users are stored.
✅ One source of truth.
✅ Both components stay synchronized.
✅ No duplicated state.

Instead of each component trying to manage the same information...

They simply rely on the parent.

💡 My Biggest Takeaways Today

🏗️ Components don't automatically share state.
👨‍👧 Sibling components can't directly access each other's state.
⬆️ Shared state should live in the nearest common parent.
📨 Props can pass both data and functions.
🔄 Updating the parent's state automatically updates every child that depends on it.

📚 Learning Source

I'm currently learning React through the React Cohort 3.0 by Devendra Dhote at Sheriyans Coding School.

This article isn't a copy of the course.

It's my personal understanding after today's class, rewritten entirely in my own words.

Writing these articles helps me reinforce what I've learned, and hopefully helps other beginners who are on the same journey. 🤝

If I've misunderstood something, I'd genuinely appreciate your corrections in the comments. 😊

🙌 Final Thoughts

Today's lesson wasn't about learning another Hook or another React API.

It was about learning where state actually belongs.

Earlier, I thought state should always stay inside the component that uses it.

Now I know that's not always true.

If multiple components need the same information, the best solution isn't to duplicate the state.

It's to move that state to their nearest common parent and let React's data flow do the rest.

That one idea made component communication feel much less mysterious.

See you on Day 8! 🚀

💬 When you first learned React, did you also try making sibling components share state directly, or did lifting state up click immediately for you? I'd love to hear your experience in the comments. 😊

I'd love to hear your experience in the comments. 😊

If you're following along with this series, you can also find me on GitHub, where I'll be sharing my projects and documenting my progress.

Bismay-exe (Bismay.exe) · GitHub

👋 Hi, I’m Bismay 💻 Developer passionate about building clean, minimal, and elegant apps 🚀 Focused on coding 🌱 Always learning, creating & new ideas - Bismay-exe

github.com

_{🤖 AI Disclosure: This article is based on my own React learning journey, class notes, code experiments, and understanding. I used ChatGPT to help improve the writing, structure, and readability of this post. I reviewed and verified the technical explanations before publishing, and I take responsibility for everything shared here.}

Thanks for reading! 🚀

Top comments (3)

Frank • Jul 13

How does lifting state up impact performance in larger apps? I'm curious about the tradeoffs between simplicity and optimization. Would love to hear your thoughts on this.

Bismay.exe • Jul 13

Thanks for asking! I actually learned Context API after writing that post, and it helped answer part of this for me. Lifting state up is still a good approach for closely related components, but when data has to travel through many layers, Context API can help avoid prop drilling and keep things cleaner. I'm still learning, but that's my understanding so far. I wrote about it in my latest Day 11 post if you're interested: