AI App Development from Zero Knowledge – 1000 Hours #14

＃14: A Morning in the Props Hell

【Summary】
This episode recounts a frustrating morning of debugging caused by tangled state management between App.js and TaskManager.js. I ran into errors like “duplicate declarations” and confusion over props, ultimately learning that consistent architecture is crucial. Repeated miscommunication with AI about useState, props, and where state should live led to painful—but necessary—lessons about component design in React.

The Beginning of Props Hell

That morning, I just wanted to finish what I left off the previous day—some minor tweaks to the morning check-in button and avatar animation.

But the moment I added a small piece of code to TaskManager.js, the screen froze in red.

"Identifier 'coins' has already been declared"

What? I simply redefined the props I received. What's wrong with that?

One state. One definition.
Me: “I gave you the full code. Why is there a duplicate definition? Check properly.”
ChatGPT: “The coins state is already declared with useState in App.js and passed to TaskManager as props. Using useState again in TaskManager causes a conflict.”
Me: “So I should delete all the useState in TaskManager, right?”
ChatGPT: “No, coins and dailyTasks should only be defined in App.js and passed down. TaskManager should just receive and use them.”

The real issue was the lack of a consistent design philosophy about where state should be maintained.

---

Morning Button and Event Confusion

Then came the next issue: the onClick behavior of the morning meeting button. This was the AI’s suggestion:

<button
  className={`morning-meeting-button ${isMorningMeetingActive ? "" : "disabled"}`}
  disabled={!isMorningMeetingActive}
  onClick={onMorningMeeting} // Just calls the parent function
>
  ⌛
</button>

Me: “Wait, I always put the alert in TaskManager. Why are we moving it to the parent?”

ChatGPT: “By passing the onMorningMeeting function via props, both the alert and state updates can happen in App.js.”

That made sense at first—until confusion hit again. App.js already had a handleMorningMeeting function. So which one is it? onMorningMeeting or handleMorningMeeting? The naming lacked consistency.

---

The Moment Everything Got Messy

Receiving props while also declaring the same variable name with useState leads directly to bugs. I didn’t know that, so I angrily asked the AI:

“What’s the right way? Why can’t I reuse the same variable name?”

ChatGPT:

“You’re right to be confused. My guidance was inconsistent and that led to the mess. State should always be managed in one place. Props should be used, not redefined.”

---

Lessons Learned

• Decide clearly where to use useState—parent or child.
• Never redefine state that's passed in via props.
• Having the same name for props and internal variables is okay—but don’t redeclare them.
• Always know where your functions like onClick={onMorningMeeting} are defined.

---

Conclusion: Consistency Saves Everything

A single line of redundant definition led to two hours of debugging hell. But it also taught me the critical importance of consistency in state management and responsibility separation.

As I continue developing, I’ll be reminded of how vital these basic design principles are. And if this series can light the way for someone in their “first 100 hours,” then all this struggle was worth it.