Upasana Shinde’s Post

Nobody talks about this React performance trap — and it bit me hard in production. I was using useContext to manage auth + theme + cart state in a mid-size app. Only a few components actually used the cart state. But every time the cart updated — every single component consuming the context re-rendered. Even the ones that only needed the user's name. Here's why: React's Context API re-renders all consumers whenever the context value reference changes — regardless of which slice of state they actually use. There are workarounds with Context: → Split into multiple contexts (AuthContext, CartContext, ThemeContext separately) → Wrap consumers in React.memo() → Use useMemo to stabilize the context value But honestly? All of these feel like duct tape. This is exactly where Zustand and Redux Toolkit shine. Both let you subscribe to only the slice of state you need. A component using useSelector(state => state.user.name) will only re-render when that specific value changes — not when the cart updates, not when the theme toggles. ZUSTAND Minimal boilerplate, great for small-to-mid apps. Selector-based subscriptions built in. REDUX TOOLKIT Structured, scalable. useSelector memoizes out of the box with Reselect. The lesson I took away: useContext is great for low-frequency, global state (auth, theme, locale). The moment you have state that changes often and is consumed by many components — reach for a proper state manager. Performance issues in React are rarely obvious until they're in production. Knowing why re-renders happen matters more than memorizing which hook to use. Have you run into this? Would love to hear how you solved it — Context splitting, Zustand, RTK, or something else entirely? #ReactJS #JavaScript #WebDevelopment #Frontend #Zustand #Redux

🚀 𝗗𝗲𝗰𝗼𝗱𝗲 𝗠𝗘𝗥𝗡 𝘄𝗶𝘁𝗵 𝗠𝗲 – 𝗗𝗮𝘆 𝟳 Today’s focus wasn’t just UI… It was about writing smarter React code. I explored 𝗖𝘂𝘀𝘁𝗼𝗺 𝗛𝗼𝗼𝗸𝘀— a concept that changes how you structure your applications. Instead of repeating logic in multiple components, I learned how to extract it into a reusable function. So I built a simple project to apply it 👇 📌 𝗣𝗿𝗼𝗷𝗲𝗰𝘁: Notes App with Auto Save A minimal app, but with a strong concept behind it. ✔ Notes are saved automatically ✔ Data persists even after refresh ✔ No backend used — everything handled in the browser ✔ Clean and simple UI with Tailwind CSS ⚙️ 𝗪𝗵𝗮𝘁 𝗺𝗮𝗱𝗲 𝗶𝘁 𝗶𝗻𝘁𝗲𝗿𝗲𝘀𝘁𝗶𝗻𝗴? I created a custom hook: useLocalStorage This hook handles: • State management • Data storage • Sync between UI and localStorage One hook → reusable logic → cleaner components 🧠 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆: When your logic is reusable, your code becomes scalable. And that’s where React starts to feel powerful. 🔗 𝗖𝗼𝗱𝗲: https://lnkd.in/gBuMk4TG Learning one concept at a time. Building one project at a time. #MERN #ReactJS #CustomHooks #WebDevelopment #LearningInPublic #100DaysOfCode

⚛️ Zustand — A Clean & Minimal Approach to State Management in React When building applications with React, one thing that really impacts code quality over time is how you manage state. There are plenty of options out there, but Zustand stands out for keeping things simple without sacrificing flexibility. 🧠 What is Zustand? Zustand is a lightweight state management library that lets you manage global state with very little setup. 👉 No providers 👉 No reducers 👉 No heavy boilerplate It keeps things straightforward and easy to reason about. ⚡ How it works At its core, Zustand is just a simple store: import { create } from "zustand"; const useStore = create((set) => ({ count: 0, increment: () => set((state) => ({ count: state.count + 1 })), })); And you can use it anywhere in your app: const count = useStore((state) => state.count); const increment = useStore((state) => state.increment); No extra wrapping or complex setup needed. 🔥 Why Zustand works well ✔ Clean and minimal API ✔ Updates only what actually changes (better performance) ✔ No need to wrap your entire app ✔ Helps you move faster with less code ⚠️ Where to be cautious Zustand is great, but it’s not a one-size-fits-all solution. 👉 For large-scale apps with complex workflows 👉 When you need strict structure or advanced debugging tools you might want something more opinionated. 💡 Practical perspective Zustand fits really well when: ✔ Your app is small to medium in size ✔ You want to keep things simple ✔ You don’t need heavy state architecture 🚀 Final thought State management doesn’t have to be complicated. Sometimes, keeping things simple is the best decision you can make for your codebase. ❓ What are you using in your projects — Redux or Zustand? 📌 I’ll share a detailed comparison of Redux vs Zustand in my next post. #reactjs #zustand #redux #frontenddevelopment #javascript #webdevelopment #softwareengineering #fullstackdeveloper #dotnetfullstackdeveloper #react

🚀React Bundle Analysis & Optimization Your React app might look fine… But if your bundle is heavy, users will feel the slowdown ⚠️ Let’s break this down simply 👇 🧩 What is a Bundle? 👉 When you build a React app, all your code + libraries are combined into JavaScript files (bundles) 💡 Example: • React • UI libraries • Utility functions ➡️ All packed into one or multiple JS files ⚠️ Why Large Bundles Are a Problem ❌ Slow initial load ❌ More JavaScript to execute ❌ Poor performance on low-end devices 👉 Bigger bundle = Slower app 🔍 What is Bundle Analysis? 👉 It helps you understand: • Which library is heavy • What is increasing bundle size • Where optimization is needed 📊 Tools give a visual breakdown of your bundle 🛠️ Tools You Can Use ✔ webpack-bundle-analyzer ✔ source-map-explorer 👉 Shows which dependency is taking the most space ⚡ How to Optimize Bundle 🧩 1. Code Splitting → Break bundle into smaller chunks ⚡ 2. Lazy Loading → Load components only when needed 🌳 3. Tree Shaking → Remove unused code automatically 📦 4. Dynamic Imports → Load heavy modules on demand 🧹 5. Remove Heavy Libraries → Replace with lighter alternatives 🔥 Real Impact ✔ Faster load time ✔ Better performance ✔ Improved user experience ✔ Smaller bundle size 🧠 Simple Way to Understand • Without Optimization → Big bundle → Slow app ❌ • With Optimization → Small chunks → Fast app ✅ 💬 Have you ever checked what’s inside your bundle? #React #WebPerformance #Frontend #JavaScript #WebDevelopment #Optimization #Coding #SoftwareEngineering

Your React app feels slow, and you have no idea why. The truth is, it is probably re-rendering 10x more than it should be. React core philosophy is that UI is a function of state. When state changes, React re-evaluates the component tree. But if you are not careful, a single state change at the top of your tree can trigger a massive wave of unnecessary re-renders all the way down to the bottom. Here are the 3 most common reasons your React app is re-rendering too much: 1. Passing new object references in props. If you pass an inline object or function like style={{ color: 'red' }} or onClick={() => doSomething()}, React sees a brand new reference on every single render. Even if the contents are identical, React thinks the prop changed. 2. State lifted too high. If you have a form input that updates on every keystroke, and its state lives in a parent component alongside heavy data tables, typing one letter re-renders the entire table. 3. Missing memoization. Complex calculations or heavy child components that do not depend on the changed state will still re-render by default. React is fast, but it is not magic. Example: Instead of passing inline functions like this: <Button onClick={() => handleSubmit()} /> Use useCallback to keep the reference stable: const handleSubmit = useCallback(() => { ... }, []); <Button onClick={handleSubmit} /> Key takeaways: - Keep state as close to where it is used as possible. - Use memo for expensive child components. - Use useMemo and useCallback to preserve reference equality for objects and functions passed as props. #reactjs #webdevelopment #frontend #javascript #performance #softwareengineering #coding #webdev #reactdeveloper #programming

Ever wondered how apps handle scroll events, button spam, or rapid user actions efficiently? 🤔 That’s where Throttling in JavaScript comes in. 💡 Throttling ensures that a function executes at a controlled rate, no matter how many times an event is triggered. Instead of running a function hundreds of times (like during scrolling), throttling limits execution to once every fixed interval — making your app much more efficient ⚡ 📌 Why it matters: Improves performance Prevents unnecessary function calls Enhances user experience 🚀 Common use cases: Scroll events Window resizing Mouse movements API calls on frequent triggers 🧠 Key takeaway: Throttling is about limiting execution frequency, not delaying it (that’s debounce 😉). Currently exploring more performance optimization techniques to build smoother and scalable web apps. #javascript #webdevelopment #frontend #reactjs #performance #coding

For a long time, I thought sprinkling useMemo and useCallback everywhere made my React apps faster. It didn't. It made them slower to read, harder to maintain, and in some cases measurably slower to run. What finally clicked: React.memo, useCallback, and useMemo aren't "optimization hooks." They're reference-equality tools. React.memo skips a re-render only if prop references are stable. If the parent passes a new object or arrow function each render, memo does nothing — except add comparison cost. useCallback and useMemo preserve reference identity. That matters only when a downstream consumer (a memoized child, a useEffect dep, a custom hook) is actually watching that reference. Without a consumer that cares, they're dead weight. But in the right places, these hooks are non-negotiable: → A table with 500 rows doing non-trivial work per row? React.memo is the difference between 60fps and visible jank. → A Context provider whose value is an object literal? Without useMemo, every consumer re-renders on every parent render. That one line can tank a whole app. → A function inside a useEffect dependency array? Without useCallback, you've written an infinite loop. → A custom hook returning a function for consumers to depend on? useCallback is how you don't silently break every caller. The rule I use now: Memoize when I can point to a specific thing that benefits. Otherwise, let React do its job. These hooks aren't reflexes. They're precision tools. Misuse them and you pay for machinery that does nothing. Place them right and the wins are massive — the kind that separate a smooth app from a laggy one. Learn them properly. They're worth it. #ReactJS #JavaScript #SoftwareEngineering

I deleted 70% of useEffect calls in a production React app. Nothing broke actually it became faster. The real problem wasn't "too many effects" it was derived state computed inside effects instead of during render. Context: A dashboard with filters, sorting, and real-time updates. Each filter change triggered useEffect → setState → re-render → another useEffect classical chain reaction. What I did instead: Moved all derived data into useMemo + selector functions. Used event handlers for user actions (filters, sorting). Kept useEffect only for external sync (localStorage, analytics, WebSocket). Rule I now use: If you setState inside useEffect - stop. Ask can this be calculated during render? Result: 7 effects --> 2 effects Rerenders per filter change: from 4 --> 1 Bug: impossible (no more stale closure issues) The shift in thinking: React is not reactive like Vue or Svelte. it's declarative. State --> UI. Effects are escape hatches, not data flow tools Question for you: What is the most confusing useEffect bug you've ever debugged? #react #typeScript #frontendperformance

Your React App is Slow… and You Might Be the Reason Most developers use useMemo and React.memo but very few actually understand when NOT to use them ⚠️ I recently debugged a performance issue in a React dashboard. Everything looked optimized — but still, the UI was lagging. The reason? 👉 Memoization was used… but used wrongly. ⚡ Let’s break it down simply: 🔹 useMemo — Caches Calculations Use it when you have expensive computations Example: const filteredData = useMemo(() => { return data.filter(item => item.active); }, [data]); ✔ Prevents unnecessary recalculations ❌ Useless for cheap operations 🔹 React.memo — Stops Re-renders Wrap your component to avoid re-render when props don’t change const Card = React.memo(({ item }) => { return <div>{item.name}</div>; }); ✔ Great for large lists / heavy UI ❌ Useless if props change every render 🔥 The Real Problem Most people do this: Wrap everything in React.memo Add useMemo everywhere Hope performance improves 👉 Result: More complexity, same performance (sometimes worse) 💡 What Actually Works ✔ Use useMemo only for heavy calculations ✔ Use React.memo only when re-renders are costly ✔ Avoid passing new object/array references every render ✔ Measure performance before optimizing 🧠 The Mindset Shift Optimization is not about adding hooks It’s about removing unnecessary work 🚀 Final Takeaway Don’t optimize blindly. First understand: Why is it re-rendering? Is it actually slow? Then use the right tool. 👇 Curious — have you ever faced unnecessary re-renders in your app? #ReactJS #FrontendDevelopment #JavaScript #WebPerformance #ReactHooks #SoftwareEngineering #CleanCode #DevTips

I got tired of rewriting the same scroll logic… so I built a reusable React hook 👇 In one of my projects, I had multiple places where I needed: → Detect when a user is near the bottom → Trigger API calls (pagination / infinite scroll) → Handle different containers (not just window scroll) Initially, I was repeating this logic everywhere. So I extracted it into a custom hook: 👉 useTableScrollPagination What it does: • Works with both containers and tables (AG Grid in my case) • Lets me control when to trigger (75%, 90%, etc.) • Prevents duplicate API calls while loading • Keeps scroll position intact after data updates The biggest win? 👉 I no longer think about scroll logic — I just reuse it. I know there are libraries for infinite scroll, but in real-world apps: → Custom containers → Complex UI structures → Different trigger behaviors …often need a more flexible approach. Curious — how are you handling infinite scroll in your apps? Library or custom solution? #ReactJS #FrontendDevelopment #TypeScript #DeveloperExperience