Aman Yadav’s Post

We had a React page that kept getting slower over time. No obvious bug. Just gradual performance drop. Here’s what we found 👇 Problem: → Page slowed down after repeated navigation → Memory usage kept increasing Root cause: → Event listeners not cleaned up → setInterval running in background → useEffect cleanup missing What I did: → Added proper cleanup functions → Removed unnecessary subscriptions → Ensured effects were scoped correctly Result: → Stable performance → No memory growth → Better user experience Insight: React doesn’t manage side effects for you. If you don’t clean up… Your app pays the price later. #ReactJS #MemoryLeak #Frontend #SoftwareEngineering #CaseStudy #JavaScript #Debugging #WebDevelopment #Engineering #Performance #FrontendDeveloper

🔯 You can finally delete <Context.Provider> 👇 For years, the Context API introduced a small but persistent redundancy. We defined a Context object, yet we couldn't render it directly-we had to access the.Provider property every single time. 🔯 React 19 removes this requirement. ❌ The Old Way: UserContext.Provider It often felt like an implementation detail leaking into JSX. Forget Provider, and your app might silently fail or behave unexpectedly. ✅ The Modern Way: <UserContext> The Context object itself is now a valid React component. Just render it directly. Why this matters ❓ 📉 Less Noise - Cleaner JSX, especially with deeply nested providers 🧠 More Intuitive - Matches how we think: "wrap this in UserContext" 💡Note: Note: <Context.Consumer> is also largely dead in favor of the use hook or useContext. Starting in React 19, you can render <SomeContext> as a provider. In older versions of React, use <SomeContext.Provider>. 💬 Have you tried this in your project? 💬 React 18 or 19 — what are you using? 🔗 Learn More: React Context Docs: https://lnkd.in/dbVWdc-C #React #JavaScript #WebDevelopment #Frontend #React19 #ModernReact #ReactHook #CodingLife #DeveloperJourney #SoftwareDeveloper

⚛️ You can finally delete <Context.Provider> 👇 For years, the Context API introduced a small but persistent redundancy. We defined a Context object, yet we couldn’t render it directly—we had to access the .Provider property every single time. ⚛️ React 19 removes this requirement. ❌ The Old Way: UserContext.Provider It often felt like an implementation detail leaking into JSX. Forget .Provider, and your app might silently fail or behave unexpectedly. ✅ The Modern Way: <UserContext> The Context object itself is now a valid React component. Just render it directly. Why this matters ❓ 📉 Less Noise — Cleaner JSX, especially with deeply nested providers 🧠 More Intuitive — Matches how we think: “wrap this in UserContext” 💡 Note: Note: <Context.Consumer> is also largely dead in favor of the use hook or useContext. Starting in React 19, you can render <SomeContext> as a provider. In older versions of React, use <SomeContext.Provider>. #React #JavaScript #WebDevelopment #Frontend #React19

Everyone says use React.lazy. Here's when it actually makes things worse. React.lazy splits your bundle. That sounds good on paper. But there's a hidden cost: → Waterfalls → Layout shift → Spinner hell on fast connections I've seen apps where lazy-loading a modal added 400ms of perceived lag — on a 100ms network. Why? Because the component fetch only starts when the user triggers it. By then it's already too late. 𝗧𝗵𝗲 𝗳𝗶𝘅 𝗶𝘀𝗻'𝘁 𝘁𝗼 𝘀𝘁𝗼𝗽 𝘂𝘀𝗶𝗻𝗴 𝗥𝗲𝗮𝗰𝘁.𝗹𝗮𝘇𝘆. 𝗜𝘁'𝘀 𝘁𝗼 𝗸𝗻𝗼𝘄 𝘄𝗵𝗲𝗻 𝘁𝗼 𝗽𝗿𝗲𝗳𝗲𝘁𝗰𝗵. Call your import() on onMouseEnter — not on render. The chunk loads in the ~200ms before the click lands. By the time the modal opens, it's already there. If a user is likely to click something within 3 seconds of landing on a page — don't lazy load it. Preload it instead. React.lazy is a network tool. Treat it like one. What did you lazy-load that you later regretted? #ReactJS #Frontend #WebPerformance #JavaScript #WebDev

🚀 New Project: Interactive Joke Generator in Next.js! I just built a dynamic random joke app exploring the power of Next.js Client Components and State Management. Technical Highlights: 🏗️ Architecture: Organised with Route Groups (projects) for a clean, scalable folder structure. ⚡ Data Fetching: Leveraged async/await and useEffect to pull live data from the Official Jokes API. 🧠 State Control: Implemented useState for a smooth Reveal/Hide punchline toggle and "Next Joke" functionality. 🎨 Styling: Fully responsive UI built with Tailwind CSS integrated via globals.css. Understanding the "use client" boundary and preventing unnecessary re-renders was a great deep dive into React performance! #NextJS #ReactJS #WebDev #TailwindCSS #Coding #Javascript

Why does your page refresh the moment you hit submit? It is the browser's old-school behavior. In the pre-SPA era, browsers were designed to reload and send data to a server after a form submission. But in React, we handle that logic ourselves using state and APIs. This is where 'event.preventDefault()' comes in. By calling it in your 'onSubmit' handler, you tell the browser to stop that default reload. It allows your JavaScript to process the data, show a loading spinner, or update the UI without the user ever losing their place. It is the key to keeping your application feeling like a fast, seamless experience. It is not just for forms. You might use it on anchor tags to stop navigation when a link acts as a button, or on 'onContextMenu' to replace the standard right-click menu with a custom one. It is all about taking full ownership of the user experience and ensuring the browser doesn't step on your toes. #ReactJS #WebDevelopment #SoftwareEngineering #Javascript #Frontend #CodingTips

Most JavaScript bugs aren’t “big” bugs. They’re small ones hiding in places like this: Trying to read a nested property that doesn’t exist. And suddenly: Cannot read properties of undefined One tiny operator that saves a lot of headaches: Optional chaining (?.) Instead of writing: user.company.address.city Write: user.company?.address?.city If something is missing, your app doesn’t crash. It just returns undefined. Small JS tip. Big difference in real projects. Do you use ?. everywhere already or still catch yourself forgetting it sometimes? #JavaScript #Frontend #WebDevelopment #SoftwareEngineering #CodingTips #ReactJS #TypeScript #Developers #AITechDaily

Ever clicked two dropdowns and both stayed open at the same time? 😾 Looks unprofessional. Feels broken. Users hate it. Here is how I fixed it in React with just 2 lines : 👉 When Explore opens → force "Degree" dropdown to close onClick={() => {  setIsExploreMenuOpen(!isExploreMenuOpen);  setIsDegreeMenuOpen(false); // ← this one line does it }} 👉 When Degree opens → force "Explore" dropdown to close onClick={() => {  setIsDegreeMenuOpen(!isDegreeMenuOpen);  setIsExploreMenuOpen(false); // ← same idea }} The logic is simple: When you open something → explicitly close everything else. React does not do this automatically. You have to tell it exactly what to close. Small detail. Big difference in user experience. #react #nextjs #javascript #webdevelopment #tailwindcss #buildinpublic #frontenddevelopment

I just started a deep dive into React and came across how it uses snapshots to re-render the view, by strictly comparing references of the old state copy in memory to the newer one. That immediately triggered a question: When we do so many state updates in a large production app, we are essentially creating so many snapshots in memory that will most likely never be used again. What happens to all this garbage sitting in memory? There must be massive leaks everywhere, right? Short answer: No. Long answer: Here's why. Every state update creates a new snapshot in memory. The old one loses all references pointing to it. JavaScript's Garbage Collector sees this and frees it automatically. GC's only rule → if nothing points to it, it's gone. 🧹 Real leaks in React come from YOU accidentally holding references outside React's control: ❌ Pushing state into an array that lives outside the component ❌ Adding event listeners without removing them ❌ setInterval running after the component unmounts In all these cases GC sees "something still points here" and leaves it alone, forever. useEffect cleanup exists for exactly this reason: return () => window.removeEventListener("resize", handler); One line. Prevents an entire class of memory leaks. React is not the problem. Uncleaned side effects are. #React #JavaScript #Frontend #SoftwareEngineering #WebDev

I struggled with this React concept more than I expected… 👇 👉 Why are my API calls running twice? ⚙️ What you’ll notice You open your network tab and suddenly see this: api/me → called twice api/roles → called twice api/permissions → called twice Just like in the screenshot 👇 Same request, duplicated… again and again. ⚙️ What’s actually happening In React (development mode), if your app is wrapped in Strict Mode, React will run effects twice on purpose. useEffect(() => { fetch("/api/users") .then(res => res.json()) .then(setUsers); }, []); Even though it looks like it should run once… it doesn’t (in dev). 🧠 What’s going on under the hood React basically does a quick cycle: mount → unmount → remount Why? To catch hidden side effects To check if cleanup is handled properly To make sure your logic doesn’t break on re-renders So if your API call runs twice, React is just making sure your code can handle it. 💡 The important part This only happens in development Production behaves normally (runs once) Your side effects should be safe to run multiple times 🚀 Final thought If your network tab looks “noisy” like the screenshot, it’s not React being broken — it’s React being careful. And once you understand this, debugging becomes a lot less confusing. #React #Frontend #JavaScript #WebDevelopment #ReactJS #SoftwareEngineering