React Component Lifecycle and useEffect Hook

just published part 2 of my React internals series , this one covers what actually happens when you call setState and how does re-rendering works. part 1 (initial render): https://lnkd.in/dycpqavw part 2 (re-render): https://lnkd.in/d4tWTwmk #react #javascript #frontend #webdev

Why does React say: "Don't call hooks conditionally"? 🤔 Let’s break it down simply. React doesn’t track hooks by name. It tracks them by order. Every render, React just walks through hooks like this: 1st hook → 2nd hook → 3rd hook That’s it. No labels. No IDs. Just position. Now imagine this 👇 if (condition) { useEffect(() => { // do something }); } 👉 First render: Hook1 → Hook2 → Hook3 👉 Next render (condition = false): Hook1 → Hook3 Now React gets confused 😵 It expects Hook2… but suddenly sees Hook3. This breaks the internal hook mapping — and boom 💥 unexpected bugs or crashes. 👉 The rule exists because hooks must run in the same order on every render. That’s why: ❌ No hooks inside conditions ❌ No hooks inside loops ❌ No hooks inside nested functions 👉 Always call hooks at the top level. Once you understand this, React hooks feel much less “magical” and more predictable. #ReactJS #JavaScript #FrontendDevelopment #WebDevelopment #LearnInPublic

Most React developers know this rule: “Don’t call hooks inside loops or conditions.” But far fewer understand why. React doesn’t track hooks by variable name or location. It tracks them purely by call order during render. So internally, it’s closer to this mental model: • First useState → slot 0 • Second useState → slot 1 • Third useState → slot 2 Each hook call is mapped based on its position in the sequence. Now imagine this: if (isLoggedIn) { useState(...) } On one render the hook is called, on another it’s not. That shifts the entire sequence. React will still read: • “2nd hook → slot 1” But now it’s actually reading the wrong state. I built a minimal useState implementation (attached) to demonstrate this. You’ll notice: • Hooks are stored in an array • Each call consumes the next index • The index resets on every render • Everything depends on consistent ordering That’s the real rule: It’s not about avoiding conditions It’s about keeping hook calls in the same order every render Once that order changes, state association breaks. #React #JavaScript #Frontend #SoftwareEngineering

⚛️ Old vs New: Handling Loading States the Smarter Way ❌ Before React 19, managing loading states meant dealing with isLoading flags, conditional renders, and custom spinners everywhere. Too much boilerplate… for something we use all the time. ✅ With React 19, the new <Loading /> component changes everything. It works hand-in-hand with Suspense to handle async UI automatically while your components fetch data. ✨ Key Features: 🔄 Automatic Loading State Handling — No more manual flags ⚙️ Built-in with Suspense — Seamless integration with async components 🎨 Customizable UI — Swap <Loading /> with your own spinner or skeleton 🧠 Cleaner Code, Less Re-renders — More declarative, more efficient #react #webdev #frontend #javascript #reactjs #coding #softwareengineering #devtips #ReactTips

Many React bugs are self created Not because React is hard But because we sometimes store things that React can calculate for us. Lets fix one common mistake Dont store derived values in state If a value can be created from existing state or props, you usually dont need useState. Avoid this practice function CartSummary() { const [items, setItems] = useState(3) const [pricePerItem, setPricePerItem] = useState(25) const [total, setTotal] = useState(0) useEffect(() => { setTotal(items * pricePerItem) }, [items, pricePerItem]) return <p>Total: ${total}</p> } Looks ok... but it adds => Extra render cycles => More logic to maintain => Chance of outdated values Better Approach function CartSummary() { const [items, setItems] = useState(3) const [pricePerItem, setPricePerItem] = useState(25) const total = items * pricePerItem return <p>Total: ${total}</p> } Cleaner, Faster and Easier to understand Sometimes the best React code is less React code. #React #JavaScript #Frontend #WebDevelopment #Coding

🧠 React Doesn’t Update State Immediately (Even Inside the Same Function) Most people know state is async. But here’s the part many don’t realize 👇 Example const [count, setCount] = useState(0); function handleClick() { setCount(count + 1); if (count === 0) { console.log("Still zero?"); } } You click the button. Expected: count = 1 But inside that function… 👉 count is still 0 🔍 Why? Because React doesn’t update state inside the current render cycle. It schedules the update and re-renders later. 🧠 The tricky part Even this won’t work: setCount(count + 1); setCount(count + 1); 👉 Final result = +1, not +2 ✅ Correct way setCount(prev => prev + 1); setCount(prev => prev + 1); Now React uses the latest value. 🎯 The Real Insight State inside a function is a snapshot, not a live value. 💥 Why this matters This causes: Unexpected conditions Wrong calculations Confusing bugs #ReactJS #FrontendDevelopment #JavaScript #ReactHooks #WebDevelopment #CodingTips #LearningInPublic

📌 Part 8 of 10: A lot of React bugs make more sense once you realize state behaves more like a snapshot than a live variable. That idea sounds small. But once it clicks, a lot of confusing behavior starts making more sense. Why logs can feel misleading. Why updates don’t look immediate. Why handlers sometimes “see” older values than people expect. Once I really understood that, I stopped fighting React as much. I started designing with it instead. What React concept took longer to click for you than expected? #React #ReactJS #StateManagement #JavaScript #FrontendDevelopment #Debugging #TypeScript

useEffect — The Hook That Confused Me (Until I Got This) useEffect was confusing until I understood one thing: dependencies control everything. The Rule: javascript // Runs ONCE after mount useEffect(() => { fetchData(); }, []); // Runs when userId changes useEffect(() => { fetchUser(userId); }, [userId]); // Runs on EVERY render (avoid!) useEffect(() => { console.log('render'); }); What I Learned the Hard Way: Missing dependencies = stale data Adding everything = infinite loops Cleanup functions matter (especially for subscriptions) My Checklist: What should trigger this effect? Do I need to clean up? Can this cause unnecessary renders? What's your React Hook survival tip? #ReactJS #JavaScript #FrontendDeveloper #WebDev #CodingTi

🚀 JavaScript Output Challenge #5 (Hoisting Trap) Looks simple… but is it really? 👀 🧠 Question: 👉 What will be printed in the console? ⚠️ Don’t run the code. Try to think about: Hoisting Function declaration vs variable declaration Execution context 🤔 Bonus: Why does JavaScript behave this way internally? 💬 Drop your output + reasoning in comments Let’s see who understands JavaScript deeply 🔥 📌 Detailed explanation coming soon... #javascript #webdevelopment #frontend #codingchallenge #reactjs #nodejs

This is subtle but causes real performance issues: ```js // New function reference every render — React remounts the child each time function ParentComponent() { function ChildComponent() { return <div>Child</div>; } return <ChildComponent />; } ``` Every time ParentComponent renders, React sees a brand new component definition. It unmounts and remounts the child — destroying its state and causing unnecessary DOM operations. The fix is simple — define components at the module level: ```js // Stable reference — React correctly reuses the component function ChildComponent() { return <div>Child</div>; } function ParentComponent() { return <ChildComponent />; } ``` This is one of those mistakes that's easy to make and hard to debug when you don't know what to look for. #ReactJS #JavaScript #Frontend #WebDevelopment