Akash Tiwari’s Post

Interesting React state issue I debugged recently… While working on a React feature, I hit a bug where a user was removed and then re-invited, but the UI refused to update the “Invited” status. API calls were perfect but UI Completely confused. What was going wrong: 1.User removed 2.User re-invited 3.React still showed the old state Turns out, the problem was how I was updating state. The fix was simple but important: 1.Stop mutating state 2.Always create a new state reference 3.Update state only after the API response If React doesn’t see a new state, it won’t re-render no matter how correct your logic feels. Frontend bugs like this are great reminders that React is all about state, not assumptions. #ReactJS #FrontendDevelopment #JavaScript #WebDev

React & JS #25 Why Context API becomes slow at scale:- React gives us many ways to centralize state… but performance and maintainability change drastically as apps grow. What works at small scale often breaks quietly later. :-) Why Context API becomes slow at scale Context updates re-render all consumers. That means: One state change → many components re-render Hard to control update boundaries Performance issues in frequently changing state Context is great for: Theme, auth, locale ❌ Not for high-frequency or complex state :-) Redux: Control & Predictability Redux centralizes state with explicit update flows. Pros Predictable state transitions Excellent debugging Scales well in large teams Cons Boilerplate More setup Easy to overuse for server state Best when control matters more than simplicity. :-) Zustand: Simplicity & Performance Zustand uses fine-grained subscriptions. Pros Minimal API Fewer re-renders No providers Easy mental model Cons Less opinionated Requires discipline at scale Best when simplicity and performance matter more than ceremony. TL;DR :- Context is for configuration. Redux is for complex, controlled state. Zustand is for lightweight, reactive state. Choosing the wrong tool works today… and becomes tomorrow’s performance bug. #ReactJS #JavaScript #StateManagement #ContextAPI #Redux #Zustand #FrontendArchitecture #WebDevelopment #FrontendEngineering

You can finally delete <Context.Provider> 👇 . For years, the Context API had a slightly annoying redundancy. We created a Context object, but 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 felt like implementation detail leaking into the JSX. If you forgot .Provider, React would throw a silent error or just not work. ✅ The Modern Way: Just render <UserContext>. The Context object itself is now a valid React component. Why this matters ❓: 📉 Less Noise: Cleaner JSX, especially when you have multiple nested providers. 🧠 Logical: It aligns with how we think: "Wrap this in the UserContext." ⚡ Codemod Available: The React team provides a script to automatically upgrade your entire codebase. 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>. #ReactJS #React19 #WebDevelopment #Frontend #JavaScript #CleanCode #SoftwareEngineering #TechTips #ReactTips #ReactHook #Hooks #FrontendDeveloper #DeveloperTips #React

You can finally delete <Context.Provider> 👇 . For years, the Context API had a slightly annoying redundancy. We created a Context object, but 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 felt like implementation detail leaking into the JSX. If you forgot .Provider, React would throw a silent error or just not work. ✅ The Modern Way: Just render <UserContext>. The Context object itself is now a valid React component. Why this matters ❓: 📉 Less Noise: Cleaner JSX, especially when you have multiple nested providers. 🧠 Logical: It aligns with how we think: "Wrap this in the UserContext." ⚡ Codemod Available: The React team provides a script to automatically upgrade your entire codebase. 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>. #ReactJS #React19 #WebDevelopment #Frontend #JavaScript #CleanCode #SoftwareEngineering #TechTips #ReactTips #ReactHook #Hooks #FrontendDeveloper #DeveloperTips #React

🤯 Why React State Doesn’t Update Immediately If you’ve ever written this 👇 setCount(count + 1); console.log(count); …and expected the updated value — but saw the old value instead 😵 Don’t worry — this is normal in React. 🧠 Simple reason React does not update state immediately. Instead: React plans the update React updates the UI later React decides the best time to re-render This helps React stay fast and efficient. 📌 Think of it like this Imagine you tell someone: “Increase the count by 1” React replies: “Okay 👍 I’ll do it when I refresh the screen.” So when you immediately check the value, React hasn’t updated it yet. That’s why you still see the old value. 🔍 What actually happens 1️⃣ You call setCount 2️⃣ React schedules the update 3️⃣ React re-renders the component 4️⃣ New state becomes available So console.log runs before React updates the state. ✅ The correct way When the new value depends on the old value, always use the functional update 👇 setCount(prev => prev + 1); This tells React: “Use the latest value — not the old one.” 🔁 Real example (very common bug) ❌ Wrong setCount(count + 1); setCount(count + 1); 👉 Result: +1 only Because both lines use the same old value. ✅ Correct setCount(prev => prev + 1); setCount(prev => prev + 1); 👉 Result: +2 Because React updates based on the latest state each time. 🎯 Interview Tip 💡 If an interviewer asks: “Why doesn’t React state update immediately?” ✅ Answer like this: “Because React updates state asynchronously for performance and batches updates. When the next state depends on the previous one, we should use functional updates.” #ReactJS #FrontendDeveloper #JavaScript #ReactState #ReactInterview #WebDevelopment #LearningReact

🚀 Say goodbye to <Context.Provider> redundancy in React! For years, working with the Context API felt a bit clunky. We had to wrap our components in .Provider every single time, easy to forget, messy to read. ⚛️ With React 19, that changes: ❌ Before: <UserContext.Provider> It worked, but it cluttered JSX and felt like an implementation detail. Forget it, and React would either fail silently or break. ✅ Now: <UserContext> The Context object itself is now a valid component. Cleaner, simpler, and more intuitive. Why it matters: 📉 Less Noise: Cleaner JSX, even with multiple nested contexts. 🧠 More Logical: Wrapping a component now reads exactly how we think: “This component uses UserContext.” ⚡ Easy Upgrade: React provides a codemod to update your codebase automatically. 💡 Bonus: <Context.Consumer> is mostly obsolete, useContext or hooks have you covered. Starting React 19, just render <SomeContext> directly, and your JSX becomes clearer than ever. #ReactJS #React19 #WebDevelopment #FrontendDevelopment #JavaScript #SoftwareEngineering

🚀 Say goodbye to <Context.Provider> redundancy in React! For years, working with the Context API felt a bit clunky. We had to wrap our components in .Provider every single time, easy to forget, messy to read. ⚛️ With React 19, that changes: ❌ Before: <UserContext.Provider> It worked, but it cluttered JSX and felt like an implementation detail. Forget it, and React would either fail silently or break. ✅ Now: <UserContext> The Context object itself is now a valid component. Cleaner, simpler, and more intuitive. Why it matters: 📉 Less Noise: Cleaner JSX, even with multiple nested contexts. 🧠 More Logical: Wrapping a component now reads exactly how we think: “This component uses UserContext.” ⚡ Easy Upgrade: React provides a codemod to update your codebase automatically. 💡 Bonus: <Context.Consumer> is mostly obsolete, useContext or hooks have you covered. Starting React 19, just render <SomeContext> directly, and your JSX becomes clearer than ever. #ReactJS #React19 #WebDevelopment #FrontendDevelopment #JavaScript #SoftwareEngineering

💡 Do you really understand useEffect in React? In React, not everything is about rendering. Fetching data from an API, manipulating the DOM, or using setTimeout are all side effects — and that’s exactly what useEffect is for. 👉 There are 3 main ways to use useEffect: 🔹 Without a dependency array Runs on every render 🔹 With an empty array [] Runs only once, when the component mounts Perfect for initial API calls 🔹 With dependencies [state] Runs only when that specific state changes Great for reacting to controlled updates (theme, language, data, etc.) ⚠️ Don’t forget about cleanup If you add listeners, intervals, or timeouts, clean them up to avoid memory leaks. ✨ Mastering useEffect is key to writing predictable, performant, and professional React code. #ReactJS #FrontendDevelopment #JavaScript #WebDev #Hooks #CleanCode #ProgrammingTips

Choosing the wrong state tool in React can make your code harder than it should be ⚖️ React gives us multiple ways to manage state, but useState and useReducer are not interchangeable. useState Best for simple state. const [count, setCount] = useState(0); Use it when: • State is a single value • Updates are straightforward • No complex logic involved useReducer Best for complex state logic. const [state, dispatch] = useReducer(reducer, initialState); Use it when: • State has multiple values • Updates depend on previous state • You want predictable state transitions 📌 A simple rule: Start with useState. Move to useReducer when your state logic starts to grow. Clean state management leads to cleaner components. #React #Frontend #JavaScript #WebDevelopment #StateManagement

Stale Closure in React: the silent bug that breaks logic 🤯 If you’ve ever seen a useEffect logging old state values even after updates — you’ve faced a stale closure. This happens because functions capture variables at render time, not at execution time. In React 18 and earlier, we usually fixed this with: - dependency arrays - refs - restructuring logic But React 19 introduces useEffectEvent, which finally gives us a clean, safe, and intentional solution. In this post: 1️⃣ I show the classic stale closure bug 2️⃣ A dependency-based fix (works, but not always ideal) 3️⃣ The modern React 19 solution using useEffectEvent If you understand this properly, you’ll avoid subtle production bugs and write future-proof React code. 👇 Code examples below (slide-wise) #React #JavaScript #Frontend #WebDevelopment #React19 #StaleClosure #Hooks