Anshu Kumar’s Post

⚛️ When NOT to Use React Hooks React Hooks are powerful, but using them everywhere is not always the best choice. While building and refactoring components, I learned that knowing when not to use a hook is just as important as knowing how to use one. Here are some real cases where I avoid hooks: ❌ Don’t use useEffect for derived data If a value can be calculated from props or state, it doesn’t belong in useEffect. ❌ Don’t use useState for static values Constants and fixed values don’t need a state. ❌ Don’t use useMemo or useCallback prematurely Optimization hooks should solve real performance issues—not be added by default. ❌ Don’t use useRef to control UI Refs are for storing mutable values, not for triggering re-renders. ❌ Don’t add hooks just because you can Cleaner logic always beats more hooks. ✨ Key lesson: Good React code is not about using more hooks — it’s about writing simpler, more predictable components. How do you decide when a hook is really needed? #React #ReactHooks #WebDevelopment #JavaScript #Frontend #CleanCode #LearningJourney

⚛️ When NOT to Use React Hooks React Hooks are powerful, but using them everywhere is not always the best choice. While building and refactoring components, I learned that knowing when not to use a hook is just as important as knowing how to use one. Here are some real cases where I avoid hooks: ❌ Don’t use useEffect for derived data If a value can be calculated from props or state, it doesn’t belong in useEffect. ❌ Don’t use useState for static values Constants and fixed values don’t need a state. ❌ Don’t use useMemo or useCallback prematurely Optimization hooks should solve real performance issues—not be added by default. ❌ Don’t use useRef to control UI Refs are for storing mutable values, not for triggering re-renders. ❌ Don’t add hooks just because you can Cleaner logic always beats more hooks. ✨ Key lesson: Good React code is not about using more hooks — it’s about writing simpler, more predictable components. How do you decide when a hook is really needed? #React #ReactHooks #WebDevelopment #JavaScript #Frontend #CleanCode #LearningJourney

React State Is a Snapshot — Not a Variable (A Concept Every React Dev Should Know) One of the most misunderstood concepts in React is that state is a snapshot in time, not a mutable variable. When React renders a component, it gives you a snapshot of: props state event handlers That snapshot is fixed for that render. setCount(count + 1); setCount(count + 1); setCount(count + 1); You might expect count to increase by 3 — but it doesn’t. Why? Because all three updates read the same snapshot of count. The Correct Mental Model State updates are queued React re-renders later with a new snapshot Code inside the same render never sees updated state The Fix: Functional Updates setCount(prev => prev + 1); setCount(prev => prev + 1); setCount(prev => prev + 1); Now React applies each update to the latest value, not the old snapshot. Why This Matters Understanding state as a snapshot helps you: Avoid stale state bugs Write predictable event handlers Fix issues with async logic, debouncing, and batching Reason better about concurrent rendering in React 18+ Key Takeaway State doesn’t change inside a render. React gives you a snapshot — and the next render gives you a new one. Once this clicks, many “weird” React bugs suddenly make sense. #ReactJS #Frontend #JavaScript #WebDevelopment #ReactHooks #React18

I recently revisited the React countdown timer. It reminded me of a mistake many of us have made at least once. Two common problems with timers in React - Memory leaks - Stale state caused by JavaScript closures The closure problem: When we create setInterval, the callback captures variables at creation time. So setInterval(() => {     setRemainingMs(remainingMs - 1000) }, 1000) This looks okay, but it is incorrect. Because remainingMs inside a closuer is frozen. The interval keeps the old value even after React re-renders. So this leads to - Frozen timers - Skipped seconds - Incorrect UI state The correct fix: use functional state update:     setRemainingMs(prev => Max.max(prev-1000, 0)) Preventing Memory Leaks: If we create something in useEffect (intervals, listeners, subscriptions), we must clean it up: return () => clearInterval(interval) Otherwise, the timer keeps running even after the component unmounts. How I remember: - If state depends on previous state -> use functional updates - If I create side effects -> I must clean them up So, React did not break my timer; JavaScript closures did, React just made them visible. If this saved you from a future bug, it was worth sharing #React #JavaScript #Frontend #WebDevelopment #CleanCode #development #devnote

React finally fixed one of the most hated parts of hooks and it changes how we write effects forever. useEffect has long caused bugs from stale closures, messy dependencies, and unintended re-runs. React’s new useEffectEvent Hook lets you extract non-reactive logic from effects so your callbacks always see the latest state without bloating your dependency arrays. Before: – add state/props to dependencies and trigger unwanted re-runs – useRefs or workarounds for fresh values Now: useEffectEvent gives you a stable event that always has fresh values and doesn’t force the effect to re-run. This solves stale closure headaches, simplifies timers and callbacks, and dramatically improves effect reliability in React 19.2+. We don’t have to fight with dependency arrays, infinite effects, or custom ref patterns anymore! #react #javascript #webdevelopment #reactjs #frontend

𝐃𝐚𝐲 𝟒 𝐨𝐟 𝐮𝐧𝐟𝐨𝐥𝐝𝐢𝐧𝐠 𝟙𝟝 𝐦𝐚𝐣𝐨𝐫 𝐜𝐨𝐧𝐜𝐞𝐩𝐭𝐬 𝐨𝐟 𝐑𝐞𝐚𝐜𝐭 One of the main reasons we use React is that we don’t manually interact with the DOM. React manages updates efficiently on our behalf. Instead of directly re-rendering the real DOM, React uses the 𝐕𝐢𝐫𝐭𝐮𝐚𝐥 𝐃𝐎𝐌 for better performance. React provides special functions called 𝐇𝐨𝐨𝐤𝐬 that control component behavior and DOM interaction. One important hook is 𝐮𝐬𝐞𝐒𝐭𝐚𝐭𝐞. It is used to store and manage data (state) inside a component. When the state value changes, React automatically re-renders the component and updates only the necessary parts of the DOM. Learning one concept at a time to build a strong foundation in React. #ReactJS #WebDevelopment #LearningInPublic #ReactHooks #VirtualDOM #Frontend #JavaScript

🚀 One simple React optimization that improved performance by ~20% In one of my recent projects, we noticed unnecessary re-renders impacting page load time and user experience. What helped: • Breaking large components into smaller, memoized components • Using React.memo and useCallback where it actually mattered • Implementing lazy loading and code splitting for heavy modules The result? ✔ Faster initial load ✔ Smoother UI interactions ✔ Better maintainability Performance optimization isn’t about over-engineering — it’s about understanding what truly needs to re-render. Curious to know: what’s your go-to React performance tip? 👇 #ReactJS #FrontendDevelopment #WebPerformance #JavaScript #FrontendDeveloper

🤯 Do you want a pro React tip? I started naming my useEffect functions, and its beautiful 👇 React code is full of hooks noise like useState, useEffect, useRef, and useMemo everywhere. It's hard to quickly scan a file and understand what's actually happening because the lifecycle stuff dominates everything. I started using named functions instead of arrow functions for my effects, and it made a massive difference. Here's why: 1️⃣ Cuts through the noise — When you have multiple useEffects in a component, descriptive names like synchronizeMapZoomLevel or fetchUserData let you scan the file and immediately understand the flow without reading implementation details. 2️⃣ Stack traces — If something breaks, the function name shows up in the error stack. Way easier to debug than an anonymous function at line 47. 3️⃣ Forces single responsibility — When you try to name an effect and struggle? That's usually because it's trying to do too many things. It naturally pushes you to split things up or remove them altogether (You might not need an effect) Some people prefer to extract everything into custom hooks immediately, which is great too. But this works really well for simpler cases where a full hook feels like overkill. Have you tried this? Or do you go straight to custom hooks for everything? #React #JavaScript #WebDev #CleanCode

✍️ React Hook Form – quick notes from today Forms in React always felt… heavy 😅 Too many states, too many re-renders. Then I met React Hook Form. What I liked instantly: Minimal re-renders Less boilerplate Easy validation Works great with UI libraries Instead of controlling every input, React Hook Form lets the browser do its job. const { register, handleSubmit } = useForm() <form onSubmit={handleSubmit(onSubmit)}> <input {...register("email")} /> </form> That’s it. No unnecessary useState. Feels lightweight, clean, and very React-friendly. Still learning, but this already feels like the right way to build forms. #ReactJS #ReactHookForm #Frontend #WebDevelopment #LearningInPublic #JavaScript

"useEffect" is one of the most misunderstood hooks in React. Most beginners think it’s for “running code after render” but that mindset causes bugs and unnecessary re-renders. A better way to think about "useEffect" It synchronizes your component with something outside React. Good use cases: Fetching data from an API Subscribing to events Updating document.title Cleaning up listeners Rule of thumb: If your logic doesn’t interact with the outside world, it probably doesn’t belong in "useEffect". Understanding this early makes your React code cleaner, predictable, and easier to maintain. #React #WebDevelopment #Frontend #JavaScript #ReactHooks