React Hooks Simplified: useState & useEffect Explained

🚀 useEffect in React – Side Effects Made Simple ⚡ After learning useState, the next important hook is useEffect. It helps you handle side effects in React. 1️⃣ What is useEffect? 👉 It runs code after the component renders Used for: ✔ API calls ✔ Event listeners ✔ Timers ✔ DOM updates 2️⃣ Basic Example import { useEffect } from "react"; useEffect(() => { console.log("Component rendered"); }); 👉 Runs after every render 3️⃣ Run Only Once (Like componentDidMount) useEffect(() => { console.log("Component mounted"); }, []); 👉 Empty dependency array = run only once 4️⃣ Run When State Changes useEffect(() => { console.log("Count changed"); }, [count]); 👉 Runs only when count changes 5️⃣ Real World Example (API Call) useEffect(() => { fetch("https://lnkd.in/d6JY2AXf") .then(res => res.json()) .then(data => console.log(data)); }, []); 👉 Fetch data when the component loads 6️⃣ Cleanup Function 🧹 useEffect(() => { const timer = setInterval(() => { console.log("Running..."); }, 1000); return () => clearInterval(timer); }, []); 👉 Cleanup runs when component unmounts 7️⃣ Dependency Array Summary ✔ No array → runs every render ✔ [] → runs once ✔ [value] → runs when value changes 🔥 Key Takeaway useEffect = Handle side effects outside UI rendering #React #JavaScript #Frontend #WebDevelopment #LearningByDoing

Using index as a key is dangerous Every React developer has written this at least once. items.map((item, index) => (  <li key={index}>{item}</li> )) Looks fine. Works fine. But it isn't This is Post 5 of the series: 𝗥𝗲𝗮𝗰𝘁 𝗨𝗻𝗱𝗲𝗿 𝘁𝗵𝗲 𝗛𝗼𝗼𝗱 Where I explain what React is actually doing behind the scenes. Here's what actually happens when you use index as key: You delete one item from a list. React doesn't know which item was removed. It just looks at positions. So it re-renders everything from that index downward. Input states get mismatched. Animations break. Bugs appear that you can't even reproduce consistently. And... No error. Just... wrong behavior. 🔑 Here's what React actually needs: A key isn't just something unique. It needs to be stable, unique, AND tied to the data — not the position. ❌ key={index} → breaks on delete, sort, filter  ❌ key={Math.random()} → new key every render = React destroys and recreates the node  ✅ key={item.id} → stable, reliable, React knows exactly who is who The rule is simple: If your list can ever be reordered, filtered, or deleted from... index as key will silently break your UI. Use your data's ID.  If it doesn't have one, generate it at creation — not during render. const newItem = { id: crypto.randomUUID(),   name: "New Task" } One tiny prop.  Massive impact on how React tracks your entire list. In Post 6 of React Under the Hood: What Happens When You Call setState Follow Farhaan Shaikh if you want to understand react more deeply. 👉 Read the previous post - Understanding diffing algorithm: https://lnkd.in/dzW3NP_V #SoftwareEngineering #ReactJS #WebDevelopment #JavaScript #FrontendDevelopment #BuildInPublic #LearnInPublic #ReactUnderTheHood

🔥 Redux vs Redux Toolkit — Stop Writing Boilerplate! If you're still writing traditional Redux code with multiple files for actions, reducers, and types… you're doing extra work 😅 👉 Enter Redux Toolkit (RTK) — the modern, official way to use Redux. --- 💡 What changed? ❌ Before (Redux): - Separate action types - Separate action creators - Separate reducers - Manual immutability ✅ Now (Redux Toolkit): - "createSlice()" → actions + reducer in one place - "configureStore()" → simple setup - Built-in Immer → write "mutable" code safely --- 💻 Example: Counter using Redux Toolkit import { createSlice, configureStore } from "@reduxjs/toolkit"; const counterSlice = createSlice({ name: "counter", initialState: { count: 0 }, reducers: { increment: (state) => { state.count += 1; // No spread operator needed! }, decrement: (state) => { state.count -= 1; }, }, }); const store = configureStore({ reducer: { counter: counterSlice.reducer, }, }); export const { increment, decrement } = counterSlice.actions; export default store; --- 🎯 Why it matters (Interview + Real Projects) ✔ Less code, more clarity ✔ Easy to scale large apps ✔ Cleaner architecture ✔ Faster development --- 🚀 Pro Tip: Start using RTK Query for API calls — it can replace "useEffect + Axios" completely! --- 💬 My Take: Redux isn’t outdated — but Redux Toolkit is now the standard way to write Redux. --- #ReactJS #Redux #ReduxToolkit #JavaScript #Frontend #WebDevelopment #InterviewPrep

I spent 3 months confused by React. Then I learned Hooks — and everything finally clicked. Most tutorials throw you into class components and lifecycle methods. It's overwhelming. But Hooks changed everything — they made React actually fun to write. Here's the complete mental map I wish I had on day one: ⚡ useState — add local state to any function component ⚡ useEffect — handle side effects (API calls, subscriptions) 🔵 useRef — access DOM elements & persist values without re-rendering 🔵 useContext — share data across the component tree 🟡 useMemo — cache expensive calculations 🟡 useCallback — memoize functions to prevent unnecessary re-renders 🟢 useReducer — manage complex state with reducer logic 🟢 useLayoutEffect — like useEffect, but fires before paint 5 tips to go from beginner → advanced: Master useState & useEffect DEEPLY before moving on Build custom hooks — extract logic you reuse (e.g. useWindowSize) Think in data flow — hooks work best when you understand how state moves Optimize wisely — reach for useMemo/useCallback only when you actually need them Keep building. Real projects teach what tutorials can't. Hooks aren't just syntax — they're a new way of thinking about UI logic. If you're just starting out: be patient with yourself. The mental model takes time. Once it lands, you'll wonder how you ever coded without them. Save this post — it'll make sense in ways it doesn't yet. 🔖 Which Hook was the hardest for you to wrap your head around? Drop it below 👇 #ReactJS #WebDevelopment #JavaScript #Frontend #ReactHooks #Coding #LearnToCode #SoftwareEngineering #100DaysOfCode

🚀 Understanding React from First Principles Instead of jumping directly into hooks and libraries, I decided to step back and ask a simple question: 👉 What problem is React actually solving? At its core, React is not just a library — it’s a way of thinking about UI. 🔍 First Principles Breakdown: • UI = Function of State → The interface changes whenever the data changes • Manual DOM manipulation is inefficient → Traditional JS requires updating elements step-by-step • React solves this using abstraction → You describe what the UI should look like, not how to update it ⚙️ Core Mechanism: Components → Break UI into reusable pieces State → Stores dynamic data Virtual DOM → Efficiently compares changes Reconciliation → Updates only what’s necessary 💡 Insight: React shifts your mindset from "How do I update the UI?" to "What should the UI look like given this data?" This small shift is powerful. I’m currently learning React deeply by focusing on fundamentals and first-principles thinking — not just syntax. #React #Frontend #WebDevelopment #LearningInPublic #JavaScript #FirstPrinciples

🚀 Just Published My Latest Article on React hooks. I’ve been diving deep into React recently, and I decided to put together a Medium article breaking down React Hooks — from first principles all the way to building custom hooks. If you're learning React or trying to level up your understanding, this might give you a clearer mental model rather than just memorizing syntax. Would love to hear your thoughts and feedback 🙌 https://lnkd.in/gnjffAnf #React #WebDevelopment #JavaScript #Frontend #Coding #SoftwareEngineering

𝐈𝐬 𝐲𝐨𝐮𝐫 `𝐮𝐬𝐞𝐄𝐟𝐟𝐞𝐜𝐭` 𝐫𝐮𝐧𝐧𝐢𝐧𝐠 𝐰𝐡𝐞𝐧 𝐢𝐭 𝐬𝐡𝐨𝐮𝐥𝐝𝐧'𝐭? 𝐓𝐡𝐞 𝐜𝐮𝐥𝐩𝐫𝐢𝐭 𝐦𝐢𝐠𝐡𝐭 𝐛𝐞 𝐦𝐨𝐫𝐞 𝐬𝐮𝐛𝐭𝐥𝐞 𝐭𝐡𝐚𝐧 𝐲𝐨𝐮 𝐭𝐡𝐢𝐧𝐤. I just spent a frustrating hour debugging a seemingly random data refetch in a React component, only to trace it back to a non-primitive dependency in my `useEffect` array. When you pass an object or a function created inside your component directly into `useEffect`'s dependency array, React performs a reference equality check. Even if the contents of your object or the logic of your function haven't changed, its reference is new on every render. This forces your effect to re-run unnecessarily. Here's the common trap: ```javascript // 🚨 Problematic: 'config' object reference changes on every render const MyComponent = ({ id }) => { const config = { userId: id, status: 'active' }; useEffect(() => { fetchData(config); }, [config]); // 💥 Effect re-runs even if 'id' hasn't changed // ... }; ``` A cleaner, more performant way is to stabilize those references. For configuration objects, `useMemo` is your friend: ```javascript // ✅ Solution: 'memoizedConfig' reference is stable as long as 'id' is const MyComponent = ({ id }) => { const memoizedConfig = useMemo(() => ({ userId: id, status: 'active' }), [id]); useEffect(() => { fetchData(memoizedConfig); }, [memoizedConfig]); // ... }; ``` This prevents wasted renders and unnecessary side effects, keeping your app snappier and less buggy. It's often the small details in `useEffect` that lead to the biggest headaches! Have you ever battled a similar `useEffect` dependency bug? What was your fix? #ReactJS #FrontendDevelopment #JavaScript #WebDev #ReactHooks

I stopped writing messy React code… and my projects became 10x easier to maintain. Here’s what changed 👇 Most developers focus on “making it work.” But clean code is what makes it scalable. One simple habit I adopted: 👉 Extract logic into reusable hooks Instead of this 👇 useEffect(() => { fetch("/api/users") .then(res => res.json()) .then(data => setUsers(data)) .catch(err => console.error(err)); }, []); I now do this 👇 // useFetch.js import { useState, useEffect } from "react"; export function useFetch(url) { const [data, setData] = useState(null); useEffect(() => { fetch(url) .then(res => res.json()) .then(setData) .catch(console.error); }, [url]); return data; } Then use it anywhere 👇 const users = useFetch("/api/users"); 💡 Why this matters: Cleaner components Reusable logic Easier debugging Better scalability Small improvements like this separate average developers from great ones. What’s one coding habit that improved your workflow? #React #JavaScript #CleanCode #WebDevelopment #Frontend

🚀 Memoization in React — When useMemo & useCallback Actually Matter Most developers learn useMemo and useCallback… 👉 But very few understand when to use them correctly And that’s where performance is won (or lost). 💡 What is Memoization? Memoization is an optimization technique: 👉 Cache the result → Avoid recomputation In React, it helps prevent: Expensive calculations Unnecessary re-renders Function re-creations ⚙️ The Real Problem Every render in React: ❌ Recreates functions ❌ Recomputes values ❌ Triggers child re-renders 👉 Even if nothing actually changed 🔥 Where useMemo Helps const filteredData = useMemo(() => { return data.filter(item => item.active); }, [data]); ✅ Avoids expensive recalculations ❌ But useless for cheap operations 🔥 Where useCallback Helps const handleClick = useCallback(() => { console.log("Clicked"); }, []); 👉 Useful only when: Passing to child components Used with React.memo 🧠 The Real Optimization Rule 👉 Memoization only matters when: ✔ Expensive computation exists ✔ Reference equality affects rendering ✔ Component re-renders are costly ⚠️ Biggest Mistake Developers Make // ❌ Over-optimization const value = useMemo(() => count + 1, [count]); 👉 You added complexity without benefit 🔥 When NOT to use Memoization ❌ Simple calculations ❌ Small components ❌ No performance issue 👉 Premature optimization = bad code 💬 Pro Insight (Senior-Level Thinking) React is already optimized. 👉 Your job is NOT to optimize everything 👉 Your job is to optimize bottlenecks only 📌 Save this post & follow for more deep frontend insights! 📅 Day 16/100 #ReactJS #FrontendDevelopment #JavaScript #PerformanceOptimization #ReactHooks #SoftwareEngineering #100DaysOfCode 🚀