React Optimization: When to Use useMemo

React is just not about useState👀 My App.jsx had become a mess — multiple useEffects, auth checks, socket connections, loading states… everything in one place. It worked, but reading it felt like debugging a jungle 😅 That’s when it hit me — this is exactly where custom hooks shine. Instead of stuffing all logic inside components, we can extract it into reusable hooks like: useAuth() → handles user + login state useSocket() → manages connection & events useLoading() → controls loaders Basically turning this 👇 👉 one giant useEffect into this 👇 👉 clean, readable, modular logic What I love about custom hooks is: They clean up components They remove duplication And they make your code feel more like building blocks than chaos Also an underrated point: 👉 Custom hooks don’t share state, they just share logic. (React) That means every component still stays independent, which is exactly what we want. Still learning, but this small shift already made my code 10x better. If you’re writing long useEffects… that’s probably your signal to create a hook ⚡ #ReactJS #FrontendDevelopment #WebDevelopment #CodingJourney #JavaScript

Why does useEffect run twice in React 18? 🤔 - If you’re seeing your API calls execute twice in development, don’t panic. - In React 18, when using StrictMode, React intentionally mounts, unmounts, and re-mounts components to detect side effects and missing cleanup logic. - This happens only in development — not in production builds. - React is stress-testing your components to ensure they are future-ready for concurrent rendering. Key takeaway: - If your useEffect runs twice, your app isn’t broken — React is helping you catch potential bugs early. Development Mode (StrictMode ON) 1️⃣ Mount Component    ↓ 2️⃣ Run useEffect    ↓ 3️⃣ Cleanup useEffect    ↓ 4️⃣ Re-Mount Component    ↓ 5️⃣ Run useEffect Again Coding: useEffect(() => {  console.log("Effect ran");  return () => {   console.log("Cleanup ran");  }; }, []); output Effect ran Cleanup ran Effect ran #ReactJS #Hooks #FrontendDevelopment #JavaScript #WebDevelopment

Stop guessing, start profiling: How I slashed a component's re-render time by 60% 🚀 We’ve all been there: a React app that feels "heavy" or a search bar that lags while typing. Last week, I faced a performance bottleneck that was driving me crazy. The Problem: A complex dashboard component was re-rendering on every single keystroke in a child input field. The Solution: 1. The Investigation: Used React DevTools Profiler to identify the culprit. 2. The Fix: Implemented useMemo for heavy calculations and moved the state down to the specific input component. 3. The Result: Snappy UI and a 60% reduction in unnecessary renders. The Lesson: Don't just throw memo at everything. Understand the "why" behind the render first. What’s your favorite tool for tracking down performance bugs? Let’s talk in the comments! 👇 #ReactJS #WebPerformance #CleanCode #JavaScript #FrontendDeveloper #ProgrammingTips

My React app crashed right in front of my mentor Turns out the problem was simple - the API data hadn’t loaded yet. I tried accessing nested data immediately and got the classic error: Before: user.profile.name Cannot read properties of undefined. App dead. After: user?.profile?.name After staring at the code for a bit, I realized the fix was just using optional chaining (?.) That small change made React check if the data exists before accessing it and the crash was gone. Funny how one tiny character can save your project Lesson I learned today: When working with API data in React, always assume the data might not be there yet. Sometimes the smallest fixes teach the biggest lessons. #ReactJS #MERNStack #JavaScript #WebDevelopment

How React Works Behind the Scenes After learning JSX, I wanted to understand what actually happens when a React app runs. Here’s what I discovered: 1) The browser first loads index.html, which contains a root div. 2) React connects to that root element using main.jsx. 3) The main component (App) is executed and returns JSX. 4) JSX is converted into regular JavaScript (React elements). 5) React creates a Virtual DOM — a lightweight copy of the real DOM. 6)When changes happen (like state updates), React: Creates a new Virtual DOM Compares it with the previous one Updates only the changed parts in the real DOM This process makes React efficient and fast. Understanding what happens behind the scenes makes writing React code much more meaningful. Building strong fundamentals step by step #ReactJS #FrontendDevelopment #WebDevelopment #LearningJourney #JavaScript

## DAY 23 — React To-Do App (Rebuild) Day 23/30: I rebuilt my Day 20 To-Do List in React. Same features. Completely different experience. Vanilla JS version: 200+ lines of DOM manipulation, querySelector everywhere, manual state tracking. React version: clean components, useState for state, props for data flow, and the UI just updates when data changes. No more document.getElementById. I finally understand why React exists. Not because someone explained it — because I built the same thing twice and felt the difference. The code is cleaner, more organized, and I could add new features in minutes instead of hours. 🔗 Live: https://lnkd.in/gWYqnKGu 🔗 Code: https://lnkd.in/g3S9JDnt #30DaysOfCode #React #JavaScript #WebDevelopment #BuildInPublic #WomenInTech

Should you store secrets in .env for frontend apps? 🤔 Many developers think .env files are secure. But in frontend applications, that’s not true.   ❌ Why you shouldn’t store secrets in frontend .env In frontend frameworks like React, Vite, or Next.js, environment variables are embedded into the build. This means they become part of the JavaScript bundle sent to the browser. Anyone can inspect them using DevTools or source files. So .env hides values from your code repository — not from users.   🧩 Example   const apiKey = import.meta.env.VITE_API_KEY;   After building the app, it becomes something like:   const apiKey = "abc123secret";   Now this value exists inside the compiled JavaScript file. Anyone can open DevTools → Sources and find it.   🔒 Better solution Keep sensitive data only on the server. #WebDevelopment #FrontendDevelopment #JavaScript #ReactJS #WebSecurity #CleanCode #SoftwareEngineering

React is fast by default. But are YOU using it fast? Most React apps don't have a performance problem. They have a developer habit problem. Here are the advanced optimizations that separate senior devs from the rest: 1- Stop Abusing useEffect. Not everything belongs in a useEffect. Derived state? Compute it inline. Event-driven logic? Use handlers. useEffect is for synchronization, not control flow. 2- useMemo and useCallback. But only where it hurts. Wrapping everything in useMemo is not optimization, it's anxiety. Profile first. Memoize only when: A child component is wrapped in React.memo The value feeds a heavy computation It's a dependency in another hook 3- Code Splitting is Non-Negotiable Every route you don't lazy-load is bundle weight your user pays for. constDashboard=React.lazy(()=>import('./Dashboard')) Pair with <Suspense> and ship leaner initial loads. 4- Virtualize Long Lists Rendering 1,000 DOM nodes to show 10? That's a you problem. react-window or @tanstack/virtual renders only what's visible. Your scroll performance will thank you. 5- Avoid Anonymous Functions in JSX // ❌ New function reference on every render <Button onClick={()=>handleClick(id)}/> // ✅ Stable referenceconst handleItemClick =useCallback(()=>handleClick(id),[id]) React doesn't slow down. Unthoughtful patterns do. #React #Frontend #JavaScript #WebDevelopment #MERN #ReactJS #SoftwareEngineering #FrontendDevelopment

🚀 Just built a full-featured Todo App in React! ✅ Add, Edit & Update tasks ✅ Mark tasks as Complete / Pending ✅ Filter by All / Completed / Pending ✅ Persistent data with LocalStorage ✅ Clean UI with counters & interactive buttons This project helped me strengthen my React skills, state management, and UI handling. 🌟 Source Code: 👉https://lnkd.in/dSRsWdeM Muhammad Osama Saylani Mass I.T Training (S.M.I.T) #ReactJS #WebDevelopment #JavaScript #FrontendDevelopment #CodingJourney #ProjectShowcase #TodoApp

I just deleted my node_modules folder, and my React app has never run better. 🚀 For years, I accepted the "Black Hole" of dependencies as a mandatory part of being a JavaScript developer. We’ve all been there: Run npm install. Watch 500MB of files pour into your project. Cross your fingers that a "Ghost Dependency" doesn't break production. It felt like gravity—until I tried Yarn Berry with Plug’n’Play (PnP). I realized that the physical node_modules folder isn't a requirement; it’s an implementation choice. Making the switch changed more than just my disk space—it changed my architectural philosophy. Why this shift matters: ✅ Zero Disk Bloat: No more massive folders or slow installations. ✅ Architectural Honesty: If a dependency isn't in your package.json, PnP won't let you use it. No more accidental success. ✅ System Thinking: It forced me to look beneath the UI and understand how module resolution actually works. Real growth as an engineer doesn't always come from a new framework. Sometimes, it comes from questioning the "invisible layers" we’ve taken for granted for a decade. I’ve shared the full story of how this changed my perspective on Medium. #ReactJS #JavaScript #WebDevelopment #SoftwareEngineering #YarnBerry #Coding #FrontendDevelopment Check out the full deep dive here: