Shivangi G Sabharwal’s Post

useMemo. useCallback. React.memo. Developers treat these as features. They're not. They're workarounds. Every state change in React triggers a full component re-render. The entire function re-executes. A new Virtual DOM tree is produced. A diffing algorithm compares old vs new. Patches are computed and applied. You're paying the cost of diffing an entire tree just to update a single text node. Memoization can prune branches, but it introduces its own overhead - dependency comparison, cognitive complexity, and it's entirely opt-in. You have to manually identify what to memoize. Miss one spot and your "optimized" app is back to re-rendering everything. What if the framework just... didn't re-render? In Granular, components execute once. When a reactive value changes, only the specific DOM node bound to that value updates. Nothing else runs. Nothing else is compared. No memoization needed. No optimization hooks. No mental model of "which renders can I skip." Full explanation: https://lnkd.in/dtQqp9YW #javascript #frontend #react #webdev #performance

Headline: Stop over-engineering your React state. 🛑 "Which state management library should we use?" It’s the first question every React team asks, and usually, the answer is "Redux" by default. But in 2026, the "default" is dangerous. Choosing the wrong tool leads to boilerplate nightmares or massive performance bottlenecks. After breaking (and fixing) a few production apps, here is my "Cheat Sheet" for 2026: 1. React Context API 🧊 Best for: Low-frequency updates. Use it for: UI Themes (Dark/Light), User Authentication status, or Localization (Language). The Trap: Don’t use it for high-frequency state (like a text input or a game loop). Every time a value in Context changes, every component consuming it re-renders. 2. Zustand 🐻 Best for: Most modern SPAs. Use it for: Global state that needs to be fast and simple. It’s unopinionated, has zero boilerplate, and handles transient state updates beautifully. Why I love it: You can grab exactly what you need with selectors, preventing those dreaded unnecessary re-renders. 3. Redux (Toolkit) 🏢 Best for: Large-scale enterprise apps with complex data flows. Use it for: Apps where you need a strict "source of truth," powerful debugging (Redux DevTools), or highly predictable state transitions across a massive team. The Reality: If you aren't using the "undo/redo" logic or complex middleware, you might be carrying extra weight you don't need. The Verdict? Small/Medium:- Context + Local State. Growth/Scale:- Zustand. Complex/Enterprise:- Redux Toolkit. The best developers don't have a favorite tool; they have a favorite solution for the specific problem at hand. 🧠 What’s your go-to in 2026? Are you team "Zustand for everything" or a Redux traditionalist? Let's argue (politely) in the comments! 👇 #ReactJS #WebDevelopment #Zustand #Redux #JavaScript #SoftwareArchitecture #CodingTips

𝗜𝘀 𝘆𝗼𝘂𝗿 "𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗲𝗱" 𝗥𝗲𝗮𝗰𝘁 𝗮𝗽𝗽 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝘀𝗹𝗼𝘄𝗲𝗿? 🕵️♂️ Code splitting is often sold as a performance "magic wand." But without a strategy, you’re just creating a 𝗡𝗲𝘁𝘄𝗼𝗿𝗸 𝗪𝗮𝘁𝗲𝗿𝗳𝗮𝗹𝗹. 𝗧𝗵𝗲 𝗧𝗿𝗮𝗽: 1️⃣ 𝗣𝗮𝗿𝗲𝗻𝘁 𝗝𝗦 lazy-loads. 2️⃣ 𝗣𝗮𝗿𝗲𝗻𝘁 renders, then discovers it needs a 𝗟𝗮𝘇𝘆 𝗖𝗵𝗶𝗹𝗱. 3️⃣ 𝗖𝗵𝗶𝗹𝗱 renders, then finally triggers a 𝗗𝗮𝘁𝗮 𝗙𝗲𝘁𝗰𝗵. The browser is "blind" to deep dependencies. Instead of a 300ms load, your user stares at a "staircase" of loading spinners for 1.5 seconds. 📉 𝗧𝗵𝗲 𝗙𝗶𝘅: 𝗣𝗮𝗿𝗮𝗹𝗹𝗲𝗹 𝗢𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻 𝗛𝗼𝗶𝘀𝘁 𝘁𝗵𝗲 𝗗𝗶𝘀𝗰𝗼𝘃𝗲𝗿𝘆: Trigger the import() for the 𝗖𝗵𝗶𝗹𝗱 at the 𝗥𝗼𝘂𝘁𝗲 𝗹𝗲𝘃𝗲𝗹 alongside the 𝗣𝗮𝗿𝗲𝗻𝘁. 𝗭𝗲𝗿𝗼-𝗟𝗮𝘁𝗲𝗻𝗰𝘆 𝗠𝗼𝘂𝗻𝘁𝗶𝗻𝗴: By the time the 𝗣𝗮𝗿𝗲𝗻𝘁 mounts, the 𝗖𝗵𝗶𝗹𝗱 code is already in the cache. You bypass the <Suspense> spinner entirely. 𝗥𝗲𝗻𝗱𝗲𝗿-𝗮𝘀-𝘆𝗼𝘂-𝗙𝗲𝘁𝗰𝗵: Use Loaders to fetch 𝗗𝗮𝘁𝗮 while the JS chunks are still in flight. We don't split code just to make files smaller; we split it to 𝗼𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗲 𝘁𝗵𝗲 𝗻𝗲𝘁𝘄𝗼𝗿𝗸. When code and data arrive together, the UI feels native. ⚡ #ReactJS #WebPerformance #FrontendArchitecture #Vite #JavaScript #SoftwareEngineering

🚀 A Small React Trick That Can Improve Performance: Initializing State with a Callback When working with useState in React, many developers initialize state like this: const [count, setCount] = useState(expensiveCalculation()); At first glance, this looks fine. But there’s a subtle issue. Every time the component re-renders, expensiveCalculation() runs again — even though React only uses the result during the initial render. For simple values this isn't a problem, but for heavy computations or expensive operations, it can waste performance. ✅ The Better Approach React allows you to initialize state with a callback function: const [count, setCount] = useState(() => expensiveCalculation()); Now React will call expensiveCalculation() only once — during the initial render. Why this matters ✔ Prevents unnecessary computations ✔ Improves performance in complex components ✔ Keeps your components more efficient Real Example const [items, setItems] = useState(() => { const storedItems = localStorage.getItem("items"); return storedItems ? JSON.parse(storedItems) : []; }); Here, the localStorage read happens only once, instead of every render. Key takeaway If your initial state requires computation, data parsing, or reading from storage, wrap it in a function. Small optimization. Big difference in larger apps. 💡 React tip: Not everything that works is optimal — sometimes the smallest patterns make your code more efficient. #React #JavaScript #WebDevelopment #Frontend #ReactJS #ProgrammingTips

React 19 is more than a version upgrade — it’s a shift in how we handle async UI. After exploring the new hooks (useActionState, useOptimistic, useFormStatus, and use()), I wrote a deep dive covering: • Real-world form handling • Optimistic UI patterns • Server-first mental model • Practical code examples If you're building production-scale React apps, this release changes how you structure async workflows. Sharing my detailed breakdown here 👇 #react #frontend #javascript #webdevelopment #react19

⚛️ Props & State in React – The Heart of Component Communication If React components were people: Props are like arguments you pass to someone. State is like their personal memory that they can change. Understanding this difference is key to building dynamic React apps. 🧠 Simple Idea Props → Passed from parent → Read-only State → Managed inside component → Can change → Triggers re-render React updates the UI automatically when state changes. That’s what makes it powerful. 🚀 Why This Matters Enables component communication Makes UI dynamic and reactive Forms the base of React architecture 💡 Insight If data needs to change → use state If data needs to be shared → pass it as props React = Data flows one way (Parent → Child). #React #Frontend #JavaScript #Props #State #WebDevelopment #Coding #InterviewPrep

The Hard Truth About State in React (And Why Most Bugs Come From It) One of the things that took me a while to really understand in React was state. At first, I saw it as just a variable that changes… nothing more. But when I started working on real projects, I noticed that most of the issues I ran into weren’t coming from the UI itself — they were coming from putting state in the wrong place, or having multiple components depend on the same data in an unclear way. So I started asking myself a few questions while building: - Should this state really live here? - Who is responsible for this data? - Am I duplicating the same data in more than one place? - If the app grows… will this still work? I realized that organizing state properly saves a lot of time later on: Debugging becomes easier Re-renders are reduced And the code is much easier for someone else to understand It’s not about using more libraries… It’s about understanding how data flows through your application. Lately, I’ve been trying to improve how I structure state using Context and Reducer patterns to keep things scalable and easier to maintain. #reactjs #frontend #javascript #statemanagement

React Component Lifecycle – Change Phase & Unmount (Simple Explanation) After a component mounts, it doesn’t stay static. It moves into: 🔄 Change (Update) Phase ❌ Unmount Phase Let’s understand both in a simple way. 🔄 Change Phase (Update) A component re-renders when something changes. What triggers a re-render? • State changes – When we update state using useState() • Props changes – When parent sends new data • User events – Click, typing, form submit • Context updates – Theme/Auth changes • Global state updates – Redux / Zustand store changes What React does internally: Change → Re-render → Virtual DOM diff → Update only what changed This is why React apps are efficient. ❌ Unmount Phase (Cleanup) Unmount happens when a component is removed from the screen. Examples: • Page navigation • Modal closed • Conditional rendering becomes false Why cleanup is important: • Prevents memory leaks • Stops background timers • Removes event listeners • Cancels API subscriptions useEffect(() => { consttimer=setInterval(() => { console.log("Running..."); }, 1000); return () => { clearInterval(timer); }; }, []); The return function runs when component unmounts. 💡 Why This Matters Understanding Change & Unmount phases helps you: ✔ Write better hook logic ✔ Avoid unnecessary re-renders ✔ Improve performance ✔ Build scalable React apps As a learner, I’m realizing React becomes easier when you think in lifecycle phases instead of just writing components. #ReactJS #FrontendDevelopment #ReactHooks #WebDevelopment #LearningInPublic #JavaScript

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

-> React 19 just made Context… cleaner. No new library. No complex pattern. Just less boilerplate. If you're still wrapping everything like this 👇 <ThemeContext.Provider value={theme}> <App /> </ThemeContext.Provider> React 19 says: “You don’t need .Provider anymore.” ⚡ What Changed in React 19? Now you can use the context object directly as a provider. <ThemeContext value={theme}> <App /> </ThemeContext> Yes. That’s it. Cleaner. Shorter. More readable. 🧠 Why This Matters ✔ Less nesting noise ✔ Cleaner JSX ✔ Better DX (developer experience) ✔ More intuitive API React is slowly simplifying patterns we’ve used for years. 🔍 Quick Comparison Before React 19: <AuthContext.Provider value={user}> <Dashboard /> </AuthContext.Provider> React 19: <AuthContext value={user}> <Dashboard /> </AuthContext> Same power. Less ceremony. ⚠ Important You still create context the same way: const AuthContext = createContext(null); Only the provider usage syntax changed. Consumers (useContext) stay exactly the same. 🚀 Small Change. Big DX Upgrade. React isn’t just adding features — It’s removing friction. And honestly? This is the kind of upgrade I love. 💬 Have you tried React 19 yet? Do you like this cleaner provider syntax — or do you prefer the old explicit .Provider? Let’s discuss 👇 #ReactJS #React19 #FrontendDevelopment #JavaScript #WebDevelopment #CleanCode #DX #SoftwareEngineering #LearnInPublic 🚀