React State Updates: Avoiding Stale State Issues

🚀 useReducer in React — When useState is Not Enough As your React app grows… 👉 State becomes complex 👉 Multiple updates depend on each other 👉 Logic gets messy That’s where useReducer comes in. 💡 What is useReducer? useReducer is a hook for managing complex state logic using a reducer function. 👉 Inspired by Redux ⚙️ Basic Syntax const [state, dispatch] = useReducer(reducer, initialState); 🧠 How it works 👉 Instead of updating state directly: setCount(count + 1); 👉 You dispatch actions: dispatch({ type: "increment" }); 👉 Reducer decides how state changes: function reducer(state, action) { switch (action.type) { case "increment": return { count: state.count + 1 }; default: return state; } } 🧩 Real-world use cases ✔ Complex forms ✔ Multiple related states ✔ State transitions (loading → success → error) ✔ Large components with heavy logic 🔥 Why useReducer? 👉 useState works well for simple state 👉 useReducer works better for structured logic 🔥 Best Practices (Most developers miss this!) ✅ Use when state depends on previous state ✅ Use for complex or grouped state ✅ Keep reducer pure (no side effects) ❌ Don’t use for simple state ❌ Don’t mix business logic inside components ⚠️ Common Mistake // ❌ Side effects inside reducer function reducer(state, action) { fetchData(); // ❌ Wrong return state; } 👉 Reducers must be pure functions 💬 Pro Insight (Senior-Level Thinking) 👉 useState = simple updates 👉 useReducer = predictable state transitions 👉 If your state has “rules” → useReducer 📌 Save this post & follow for more deep frontend insights! 📅 Day 20/100 #ReactJS #FrontendDevelopment #JavaScript #ReactHooks #StateManagement #SoftwareEngineering #100DaysOfCode 🚀

Day 22: Error Boundaries in React In real-world applications, errors can happen anytime. A single error in one component can crash the entire UI. To handle this properly, React provides: Error Boundaries 📌 What are Error Boundaries? Error Boundaries are React components that catch JavaScript errors in their child component tree and display a fallback UI instead of crashing the whole app. ✅ Prevents complete app crash ✅ Displays fallback UI ✅ Improves user experience 📌 What Error Boundaries can catch? ✔ Errors in rendering ✔ Errors in lifecycle methods ✔ Errors in constructors of child components 📌 What Error Boundaries cannot catch? ❌ Errors inside event handlers ❌ Errors in async code (setTimeout, promises) ❌ Errors in server-side rendering 📌 Example of an Error Boundary import React from "react"; class ErrorBoundary extends React.Component { constructor(props) { super(props); this.state = { hasError: false }; } static getDerivedStateFromError(error) { return { hasError: true }; } componentDidCatch(error, info) { console.log("Error:", error); console.log("Info:", info); } render() { if (this.state.hasError) { return <h2>Something went wrong!</h2>; } return this.props.children; } } export default ErrorBoundary; 📌 How to use it? import ErrorBoundary from "./ErrorBoundary"; import App from "./App"; function Main() { return ( <ErrorBoundary> <App /> </ErrorBoundary> ); } Now, if any child component crashes, the app will show: 👉 "Something went wrong!" 📌 Why Error Boundaries are important? 🔥 Used in production apps 🔥 Prevents blank screens 🔥 Helps debugging errors #ReactJS #ErrorBoundary #FrontendDevelopment #JavaScript #WebDevelopment #CodingJourney #LearnInPublic

Virtual DOM is NOT why React is fast.🤔 After working on real-world React applications, I realized: 👉 Virtual DOM alone doesn’t make your app fast. Here’s what actually happens behind the scenes: ⚡ State Change User interaction or data update triggers a re-render ⚡ Diffing React compares the previous Virtual DOM with the new one ⚡ Reconciliation Only the changed elements are updated in the real DOM 💡 The real reason React performs well: 👉 It reduces expensive DOM operations Because: Direct DOM updates are slow Re-rendering everything kills performance Smart updates = smooth UI ⚠️ Where most developers go wrong: ❌ Thinking Virtual DOM = automatic performance ❌ Over-rendering components unnecessarily ❌ Ignoring unnecessary state updates ✅ What actually matters in real projects: Controlling re-renders Proper state management Optimizing component structure 💡 In data-heavy applications, this is the difference between: ❌ Laggy UI ✅ Smooth performance 👉 Virtual DOM is just a tool — performance comes from how you use React #ReactJS #FrontendDeveloper #JavaScript #WebDevelopment #SoftwareEngineering #PerformanceOptimization #FrontendArchitecture #TechIndia #Developers

🚨 Why Environment Files are MUST in React Projects? If you're building real-world apps and still NOT using proper environment configuration… you're inviting bugs into production 😅 In every project, we typically have: 👉 Development 👉 Staging (Testing) 👉 Production Now imagine using the SAME API URL or configs everywhere 🤯 Dev APIs in production ❌ Testing configs leaked to users ❌ Wrong analytics / logs ❌ This is where Environment-Based Configuration becomes critical. 💡 What should go into env files? API URLs App configs Feature flags (like enabling new UI) Analytics IDs Logging configs ⚠️ Common mistakes developers make: Not separating env files per environment Forgetting correct build mode (dev/stage/prod) Storing sensitive secrets in frontend env files 👉 In Vite (React), always use VITE_ prefix 👉 Access using import.meta.env 👉 And always build with correct mode When done right, your app becomes: ✔️ Scalable ✔️ Safe ✔️ Easy to manage across environments I’ve explained this with practical examples in my latest video 👇 🎥 https://lnkd.in/g5ca-kcU #ReactJS #Frontend #SystemDesign #JavaScript #WebDevelopment #Coding #SoftwareEngineering #ReactDeveloper

React re-render fixes React performance tips I learned the hard way over 8 years. Not from docs. From debugging slow UIs in production with real users waiting. Here are 5 things I wish someone told me on day one: 𝟭. Stop putting everything in one Context. I've seen apps where one global context holds auth, theme, user data, and cart state. Every update re-renders EVERYTHING. Split your contexts by update frequency. Auth rarely changes. Cart changes constantly. They shouldn't live together. 𝟮. useMemo and useCallback are not free. They have a cost — memory and comparison overhead. I've seen devs wrap every single function in useCallback "for performance." If the component isn't actually re-rendering unnecessarily, you're adding complexity for zero benefit. Profile first. Memoize second. 𝟯. Lazy load below the fold. On a banking platform, we had 40+ components loading on the dashboard. Users only saw 5 on first paint. We implemented React.lazy() + Suspense for everything below the fold. Page load dropped 35%. The trick: wrap lazy components in proper error boundaries, not just Suspense. 𝟰. Key prop abuse kills performance silently. Using array index as key in a list that reorders? React destroys and recreates every DOM node instead of reordering them. On a data grid with 500+ rows, this was the difference between a 200ms and 3-second re-render. Use stable, unique IDs. 𝟱. State colocation > state management libraries. Before reaching for Redux, ask: does this state need to be global? I've refactored apps where 60% of Redux state was only used by one component. Moving state closer to where it's used eliminated 45% of unnecessary re-renders in one project. The fastest React app isn't the one with the cleverest optimization. It's the one that avoids unnecessary work in the first place. What's a React performance lesson you learned the hard way? #ReactJS #JavaScript #FrontendDevelopment #WebPerformance #TypeScript #SoftwareEngineering

I kept wondering why my React app was calling the same API multiple times… 🤯 At first, I thought it was a small issue. But as the project grew, it became a real problem: * Repeated API calls * Too much state handling (loading, error, data) * Debugging became painful All because I was using `useEffect` for API calls. Then I tried something different — **React Query**. And honestly, it changed the way I handle server data: ✅ Automatic caching ✅ Built-in loading & error handling ✅ Cleaner, more maintainable code The biggest realization for me: 👉 *useEffect is not meant for managing server state.* I wrote a short article sharing what I learned and how I fixed these issues in a real project 👇 🔗 https://lnkd.in/gPMTcQBw If you're working with React, this might save you some debugging time. Would love to hear how you're handling API calls in your apps 👇 #React #JavaScript #PerformanceOptimization #WebDevelopment #ReactQuery

⚡ A Simple React Performance Trick: Lazy Loading Components One performance issue I’ve noticed in many React applications is large bundle sizes. When an app loads too much JavaScript upfront, it can slow down the initial page load and impact user experience. One simple solution for this is Lazy Loading. Instead of loading all components at once, we can load them only when they are needed. Here’s a simple example 👇 import React, { lazy, Suspense } from "react"; const Dashboard = lazy(() => import("./Dashboard")); function App() { return ( <Suspense fallback={Loading...}> ); } What’s happening here? 🔹 React.lazy() loads the component only when it is rendered 🔹 Suspense shows a fallback UI while the component is loading 🔹 This reduces the initial bundle size Why this matters 👇 ✅ Faster initial page load ✅ Better performance for large applications ✅ Improved user experience This technique becomes especially useful for: • Dashboards • Admin panels • Large feature modules • Route-based components 💡 One thing I’ve learned while working with React: Small performance optimizations like lazy loading and code splitting can make a big difference as applications scale. Curious to hear from other developers 👇 Do you use lazy loading in your React applications? #reactjs #frontenddevelopment #javascript #webdevelopment #reactperformance #softwareengineering #coding

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

Most developers try to optimize React apps… without knowing what’s actually slow. That’s the problem. Before you optimize… You need to measure. That’s where the React Profiler comes in 🔍 ⚡ What is React Profiler? A tool (inside React DevTools) that shows: • Which components are re-rendering • How long each render takes • Why a component re-rendered 🧠 What it helps you discover • Unnecessary re-renders • Slow components • Expensive computations • Props/state changes causing re-renders 🔍 Real example You click a button and suddenly the whole page re-renders. Profiler shows: 👉 A parent component updated 👉 All child components re-rendered 👉 Even the ones that didn’t need to 🚀 How to fix (after profiling) • Wrap components with React.memo • Use useMemo for heavy calculations • Use useCallback for stable functions • Avoid passing new object/array references 💡 Biggest mistake Optimizing blindly. Adding memoization everywhere… without knowing if it even helps. Measure → Identify → Optimize That’s the correct flow. 💡 React performance is not about writing more code. It’s about writing smarter code based on data. Have you ever used React Profiler to fix a real issue? 👇 #React #Frontend #WebPerformance #JavaScript #SoftwareEngineering #WebDevelopment

Most people think UI bugs are simple. Until one refuses to behave consistently. I’m currently building a multi-channel inbox (Gmail + Telegram) inside a React app, and I hit a problem that looks small… but isn’t. Same email. Same data. But depending on zoom level and viewport size: • The message looks perfectly fine on one screen • Completely broken on another • Sometimes truncated • Sometimes scrolls inside • Sometimes the entire page scrolls instead. No data issues. No API issues. Just rendering behaving differently based on layout conditions. This is where the frontend stops being “React code” and becomes system thinking. Because now you're not debugging components… You’re debugging how containers, heights, overflow, and viewport calculations interact. So I’m curious: For those who have dealt with production-level UI bugs like this… What is the FIRST thing you check when content renders inconsistently across zoom and viewport? Not theory. Actual debugging approach. If you’ve solved something like this before, I’m open to a quick debugging session as well. #ReactJS #FrontendDevelopment #WebDevelopment #JavaScript #UIDesign #Debugging #CSS #ResponsiveDesign #WebPerformance #SoftwareEngineering #BuildInPublic #Developers