Mastering React State with Custom Hooks

Most React devs use hooks daily… But a lot of us are using them wrong (or at least inefficiently). Here are 5 React Hooks you're probably misusing 👇 1. useEffect: Doing too much If your useEffect looks like a mini backend service… that’s a red flag. 👉 Keep it focused: one responsibility per effect. 👉 Avoid unnecessary dependencies (or missing ones 😬). 2. useState: Over-fragmenting state Multiple useState calls for tightly related data = messy logic. 👉 Consider grouping related state into one object 👉 Or use useReducer for complex flows 3. useMemo: Premature optimization Not everything needs memoization. 👉 If your calculation is cheap, skip it 👉 Overusing useMemo can hurt readability more than it helps performance 4. useCallback: Blind usage Wrapping every function in useCallback ≠ optimization 👉 Only use it when passing functions to memoized components 👉 Otherwise, you're just adding complexity 5. useRef: Misunderstood power It’s not just for DOM access 👉 Great for persisting values without re-renders 👉 Perfect for timers, previous values, or mutable variables 💡 Rule of thumb: If you can’t clearly explain why you're using a hook… you probably don’t need it. What’s a hook mistake you’ve made (or still make)? 😄 #React #WebDevelopment #Frontend #JavaScript #Programming #CodingTips

setState does not work as you expect Do you think setState works like this: setCount(1) console.log(count) // should be 1, right? Wrong. It's still 0 (or the prev value). And if you don't understand WHY... You'll spend hours debugging something that isn't even a bug. This is Post 6 of the series: 𝗥𝗲𝗮𝗰𝘁 𝗨𝗻𝗱𝗲𝗿 𝘁𝗵𝗲 𝗛𝗼𝗼𝗱 Where I explain what React is actually doing behind the scenes. Here's what's actually happening 👇 setState doesn't update state. It queues a request to React. React then decides WHEN to process it. Not your code. React. That's why the value after setState is still the old one... because the component hasn't re-rendered yet. Now here's where it gets interesting. Call setState 3 times in one click? You'd expect 3 re-renders. React does it in 1. That's called Batching React's built-in performance superpower. It groups all your updates, processes them together, and re-renders once. But batching also leads to one of the most confusing bugs beginners face: setCount(count + 1) setCount(count + 1) // Expected: 2 // Actual: 1 😐 Both calls read the SAME stale snapshot of count. So React queues the same value twice. How to fix this? setCount(c => c + 1) setCount(c => c + 1) // Now it's: 2 ✅ Functional updates always get the latest queued value, not the stale snapshot. One tiny change in how you write setState. Massive impact on how your app behaves. Follow Farhaan Shaikh if you want to understand React more deeply. 👉 Read the previous post: Using index as key is dangerous in list: https://lnkd.in/dPQyScAT #ReactJS #JavaScript #WebDevelopment #Frontend #BuildInPublic #LearnInPublic #ReactUnderTheHood #FrontendDeveloper #Programming #TechStudent

🚀 Just checked out Vite 8 + AI… and honestly, it feels crazy fast. At first, I used to think Vite was just another dev server. But after exploring it more, it’s actually way more powerful. Here are a few things I noticed 👇 ⚡ Builds feel much faster — even big projects start quickly 🧠 Dependency handling seems smoother (less random issues 😅) 📦 SSR support is better now, which is pretty cool 🔌 Plugins are improving and easier to work with 🛠️ Overall dev experience feels cleaner and less frustrating 💻 One thing I really liked: Frontend errors now show directly in the VS Code terminal (Browser Forward Console). Earlier I had to check the browser console, but now everything is in one place — makes debugging much easier. 📂 Also, TypeScript path aliases are supported better now. No more messy imports like ../../components — cleaner and easier to manage. 💭 What I liked the most: Hot reload + fast builds = less waiting, more coding. Still exploring it, but Vite 8 definitely feels like a solid upgrade. If you're working with React, Vue, or modern JS — you might want to give it a try. Has anyone else tried Vite 8 yet? What do you think? #Vite #Frontend #JavaScript #WebDev #React #Vue

You wrapped your component in React.memo… but it still re-renders 🤔 I ran into this more times than I’d like to admit. Everything looks correct. You’re using React.memo. Props don’t seem to change. But the component still re-renders on every parent update. Here’s a simple example: const List = React.memo(({ items }) => { console.log('List render'); return items.map(item => ( <div key={item.id}>{item.name}</div> )); }); function App() { const [count, setCount] = React.useState(0); const items = [{ id: 1, name: 'A' }]; return ( <> <button onClick={() => setCount(count + 1)}> Click </button> <List items={items} /> </> ); } When you click the button the List still re-renders. At first glance, it feels wrong. The data didn’t change… so why did React re-render? The reason is subtle but important: every render creates a new array. So even though the content is the same, the reference is different. [] !== [] And React.memo only does a shallow comparison. So from React’s perspective, the prop did change. One simple fix: const items = React.useMemo(() => [ { id: 1, name: 'A' } ], []); Now the reference stays stable and memoization actually works. Takeaway React.memo is not magic. It only helps if the props you pass are stable. If you create new objects or functions on every render, you’re effectively disabling it without realizing it. This is one of those bugs that doesn’t throw errors… but quietly hurts performance. Have you ever debugged something like this? 👀 #reactjs #javascript #frontend #webdevelopment #performance #reactperformance #softwareengineering #programming #coding #webdev #react #typescript

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

Stop over-complicating form states in React! 🚀 React 19 is officially changing the game with 'Actions'. Gone are the days of manually managing isLoading, isError, and data states using multiple useState hooks for every single form submission. The new useActionState hook (formerly useFormState) handles the heavy lifting for you: ✅ Automatic pending state transitions. ✅ Built-in error handling. ✅ Seamless integration with native HTML forms. ✅ Zero boilerplate for 'isPending' logic. If you're still using useEffect to sync form status or manually toggling booleans in try/catch blocks, it's time to upgrade your workflow. This is a massive win for Developer Experience (DX) and UI consistency. Are you moving to React 19 Actions or sticking with React Hook Form? Let's discuss in the comments! 👇 #ReactJS #WebDevelopment #Frontend #JavaScript #TypeScript #React19 #SoftwareEngineering #Programming #WebDev #CodingLife #FullStack #ReactHooks #TechTrends #SoftwareDevelopment #WebDesign #UIUX #CleanCode

Understanding the React Component Lifecycle 🌿⚛️ Every React component goes through three key phases: 🟢 Mount – when the component is created and added to the DOM 🔵 Update – when state or props change, triggering re-renders 🟣 Unmount – when the component is removed from the DOM With modern React, the useEffect hook ties it all together: Runs after mount (initial render) Runs after updates (when dependencies change) Can clean up on unmount (return function) useEffect(() => { // side effect here return () => { // cleanup on unmount }; }, []); Mastering this flow helps you manage side effects like API calls, subscriptions, and timers cleanly and predictably. #React #WebDevelopment #Frontend #JavaScript #ReactJS #Coding

⚛️ A small mistake in React cost us performance… here’s what happened. Hey devs 👋 We had a dashboard where everything looked fine… until users increased. Suddenly: ❌ UI started lagging ❌ Filters became slow ❌ Re-renders everywhere 👉 The issue? We were passing fresh objects in props on every render. Something like this: <Child data={{ value: count }} /> Looks harmless… right? 💥 But every render = new object reference → child re-render 💡 What fixed it: ✔ Memoizing data with useMemo ✔ Avoiding inline object creation ✔ Using React.memo properly ⚡ Lesson: React doesn’t compare values… it compares references. Small mistakes → big performance issues. Have you ever faced unnecessary re-renders like this? #reactjs #frontend #performance #javascript #webdevelopment #fullstack #softwareengineering #Coding #TechCareers #Programming #success

I spent 3 hours fixing a React bug yesterday. The issue wasn’t complex. My approach was. Earlier, whenever something broke in my app, I used to: ❌ randomly change code ❌ refresh again and again ❌ search Stack Overflow immediately Now I follow a simple process: ✅ check component re-renders ✅ inspect props and state flow ✅ verify API response structure ✅ use console logs step-by-step And honestly, debugging became much faster. One thing I’m learning as a developer: Writing code is important. But understanding why code breaks is what actually improves your skills. Curious to know — what’s the toughest bug you fixed recently? #ReactJS #WebDevelopment #JavaScript #FrontendDevelopment #CodingJourney #FullStackDeveloper #MERN

Why does React feel complicated? It’s not because it’s hard. It’s because we over-optimize everything. With React, devs start thinking about performance too early: - memo everywhere - useCallback everywhere - global state for things that don’t need it Now the code is harder to read, harder to debug, and ironically… not faster. Most apps don’t need that level of optimization. They need clarity. React becomes simple again when you stop trying to be clever. Write straightforward components. Let it re-render. Optimize only when something is actually slow. React isn’t complicated. Overengineering is. #reactjs #javascript #webdevelopment #frontend #softwareengineering #programming