useState vs useRef: When to Use Each in React

𝗪𝗵𝘆 𝗠𝗮𝗻𝘆 𝗥𝗲𝗮𝗰𝘁 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝗠𝗶𝘀𝘂𝘀𝗲 𝘂𝘀𝗲𝗠𝗲𝗺𝗼 I often see useMemo added everywhere in React codebases. Something like this: const filteredUsers = useMemo(() => { return users.filter(user => user.active); }, [users]); This code is technically correct. But here’s the important part: Not every computation needs memoization. useMemo itself has a cost. React still needs to: • Store the memoized value • Track dependencies • Compare dependency changes If the computation is cheap, memoization may add more overhead than benefit. For example, operations like filter() or map() on small datasets are already very fast. Memoization becomes useful when the computation is expensive or when stable references help prevent unnecessary re-renders. A simple rule I try to follow: Use useMemo when: • The computation is expensive • The result is reused multiple times • It helps prevent unnecessary re-renders Otherwise, simple code is often better. Optimization should come after measurement, not before. Day 5/100 — sharing practical frontend engineering lessons. Do you usually optimize early, or only after profiling? #ReactJS #WebPerformance #FrontendEngineering #JavaScript #SoftwareArchitecture

🚀 7 Days of Better React – Day 4 Old Approach → Better Approach Faced a common issue while working with a search input. Every keystroke was triggering an API call. ❌ Old approach: useEffect(() => { fetchResults(query); }, [query]); This hits the API on every key press. ✅ Better approach (Debouncing): useEffect(() => { const timeout = setTimeout(() => { fetchResults(query); }, 500); return () => clearTimeout(timeout); }, [query]); Now the API call only happens after the user stops typing. Better performance. Fewer unnecessary requests. Better user experience. Optimization isn’t always complex. Sometimes it’s just controlling timing. #reactjs #frontenddeveloper #javascript #performance #webdevelopment

🧠 𝐓𝐡𝐞 𝐃𝐚𝐲 𝐈 𝐅𝐢𝐧𝐚𝐥𝐥𝐲 𝐔𝐧𝐝𝐞𝐫𝐬𝐭𝐨𝐨𝐝 𝐮𝐬𝐞𝐑𝐞𝐟 𝐢𝐧 𝐑𝐞𝐚𝐜𝐭  𝑊ℎ𝑒𝑛 𝐼 𝑓𝑖𝑟𝑠𝑡 𝑠𝑡𝑎𝑟𝑡𝑒𝑑 𝑙𝑒𝑎𝑟𝑛𝑖𝑛𝑔 𝑅𝑒𝑎𝑐𝑡, 𝐼 𝑡ℎ𝑜𝑢𝑔ℎ𝑡: “Why do we even need useRef? We already have useState.” So I ignored it. Until one day… my dropdown refused to close. 😅 I had built a search bar. It opened perfectly. It showed results perfectly. But when I clicked outside… It just wouldn’t close. I tried everything with useState. Nothing worked. That’s when I discovered something important: 👉 React state manages UI. 👉 But React does NOT know where you clicked. And that’s where useRef enters. I learned that: useRef gives access to the actual DOM element. So I attached a ref to my search bar: const searchBarRef = useRef(null); Then I checked: if (!searchBarRef.current.contains(event.target)) { closeDropdown(); } And suddenly… It worked. 🎉 That’s when I truly understood: 🔹 useState → updates UI 🔹 useRef → gives DOM access 🔹 useRef → stores values without re-render And from that day, I stopped thinking: “useRef is confusing.” Instead, I started thinking: “useRef is powerful — if you use it at the right time.” If you're learning React and useRef feels confusing… Trust me, it clicks one day. And when it does, your understanding of React levels up instantly 🚀 #ReactJS #FrontendDevelopment #WebDevelopment #LearningInPublic #ReactHooks #JavaScript

Most frontend bugs are not actually “bugs”. They’re decisions we made in a hurry. I learned this the hard way while working on a role-based dashboard. We kept adding components. Then more conditions. Then more props. And suddenly… One small change broke three different modules. That’s when I realised: Good frontend isn’t about writing more code. It’s about writing less — but structuring it better. Now I think differently: • Features over random folders • Clear separation between UI & API logic • Optimizing re-renders before adding more state • Designing loading & error states intentionally Frontend isn’t just screens. It’s system thinking. Still learning. Still refining. #ReactJS #FrontendDeveloper #JavaScript #BuildInPublic

⚛️ Improving React Performance with Lazy Loading As React applications grow, the bundle size can increase significantly. Loading all components at once can slow down the initial page load and impact the user experience. React Lazy Loading helps solve this problem by loading components only when they are needed, instead of including everything in the main JavaScript bundle. With tools like "React.lazy()" and "Suspense", React can split the code and dynamically load components when a user navigates to them. Benefits of React Lazy Loading: • Smaller initial bundle size • Faster page load • Better performance on slower networks • Improved overall user experience Optimizing how and when components load is a key step in building scalable and high-performance React applications. Reference from 👉 Sheryians Coding School #React #WebDevelopment #Frontend #JavaScript #Performance #SoftwareEngineering

Your React Components Don't Need That useState. 🎯 Storing everything in state seems convenient - until it starts creating bugs. Multiple dependent states almost always lead to synchronization issues. Here's the thing: Not everything needs to be state. Some things should be derived. The rule that changed my code: → If you can calculate it from existing state, DON'T store it. → If it's derived, compute it during render. → Expensive calculation? useMemo. Not more state. Why this matters: ✅ Fewer bugs (no sync issues) ✅ Less code (no extra setters) ✅ Easier testing (less state to mock) ✅ Better performance (React can optimize) State is expensive. In memory, in complexity, in bugs. Before you write useState, ask: "Can I derive this instead?" Your turn: What's one piece of state you removed and your component got cleaner? 💬 #ReactJS #JavaScript #Frontend #WebDevelopment #CleanCode #SoftwareEngineering

Day 7:𝐘𝐨𝐮𝐫 𝐑𝐞𝐚𝐜𝐭 𝐀𝐩𝐩 𝐈𝐬𝐧'𝐭 𝐒𝐥𝐨𝐰. 𝐘𝐨𝐮𝐫 𝐑𝐞𝐧𝐝𝐞𝐫 𝐀𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐞 𝐈𝐬. Most performance problems in React aren't caused by heavy computation. They're caused by components re-rendering when they shouldn't. And that's an architecture problem — not a React problem. The 3 silent performance killers: -->State too high in the tree When global state lives at the top, every update re-renders the entire subtree. Move state down. Keep it close to where it's used. -->Everything in one component A component that fetches, transforms, and renders — re-renders entirely for any change. Split responsibilities. Isolate re-renders. -->Server state in global store Storing API responses in Redux/Zustand triggers app-wide re-renders. Server state belongs in React Query or SWR — not your global store. The fix isn't useMemo everywhere. That's patching symptoms. The fix is: ✔ Co-locate state with the component that owns it ✔ Separate server state from UI state ✔ Keep components focused and small ✔ Use React DevTools Profiler before optimizing anything 𝐏𝐞𝐫𝐟𝐨𝐫𝐦𝐚𝐧𝐜𝐞 𝐢𝐬 𝐧𝐨𝐭 𝐚 𝐟𝐞𝐚𝐭𝐮𝐫𝐞 𝐲𝐨𝐮 𝐚𝐝𝐝 𝐚𝐭 𝐭𝐡𝐞 𝐞𝐧𝐝. 𝐈𝐭'𝐬 𝐚 𝐜𝐨𝐧𝐬𝐞𝐪𝐮𝐞𝐧𝐜𝐞 𝐨𝐟 𝐭𝐡𝐞 𝐚𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐞 𝐲𝐨𝐮 𝐝𝐞𝐬𝐢𝐠𝐧 𝐟𝐫𝐨𝐦 𝐭𝐡𝐞 𝐬𝐭𝐚𝐫𝐭. 💬 Where have you seen the worst re-render issues in your projects? #ReactJS #Frontend #WebDevelopment #JavaScript #SoftwareArchitecture

𝗪𝗵𝘆 𝘁𝗵𝗲 𝗸𝗲𝘆 𝗣𝗿𝗼𝗽 𝗶𝗻 𝗥𝗲𝗮𝗰𝘁 𝗜𝘀 𝗠𝗼𝗿𝗲 𝗜𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁 𝗧𝗵𝗮𝗻 𝗬𝗼𝘂 𝗧𝗵𝗶𝗻𝗸 Most developers know: “You should add a key when rendering lists.” But many don’t fully understand why. Example: {users.map((user, index) => ( <UserCard key={index} user={user} /> ))} This works. But using an index as a key can cause subtle bugs. Why? Because React uses the key to: • Identify which items changed • Reuse existing DOM nodes • Decide what to update If the list order changes and you’re using the index as the key: React may reuse the wrong component instance. This can lead to: • Wrong UI updates • Input fields losing focus • State appearing in the wrong item Better approach: {users.map((user) => ( <UserCard key={user.id} user={user} /> ))} A stable, unique key helps React track items correctly. The key prop isn’t just a warning fix. It directly affects how React’s reconciliation works. Small detail. Big impact. Day 8/100 — sharing practical frontend engineering lessons. Have you ever faced a bug because of incorrect keys? #ReactJS #FrontendEngineering #JavaScript #WebDevelopment #SoftwareArchitecture

Integrated lucide-react into my React project today — and it reminded me how small decisions impact performance. Icons seem minor… until your bundle size starts growing. Instead of using heavy icon libraries or importing full SVG packs, I switched to lucide-react. Why? • Tree-shakable → only the icons you import are included in the final bundle • Lightweight → minimal impact on performance • Fully customizable via props (size, color, strokeWidth) • Clean React component-based usage ➡️Example: import { Search } from "lucide-react"; <Search size={20} strokeWidth={1.5} /> No manual SVG handling. No unnecessary CSS overrides. No bloated assets. As projects grow, these small optimizations matter — especially when building scalable front-end systems. Learning that performance isn’t only about algorithms… it’s also about choosing the right tools. #reactjs #frontend #webperformance #javascript #buildinpublic