Modern React: When to Use useEffect and What Replaces It

In React 19, stop managing your server State like it’s client State In React, not all "state" is created equal. Mixing them up leads to redundant API calls, stale data and a bloated codebase. Here is how to draw the line: Client-side state (UI-related data, lives entirely in the browser) Examples: Form inputs, toggles, modal visibility and theme switch. Goal: Fast, synchronous updates to the UI. Tools: React Context, Zustand or Redux. Server-side state (data that comes from an API or backend) Examples: User profiles, product lists, and analytics. Goal: Caching, synchronization, background updates and handling loading/error states. Tools: - TanStack Query: The gold standard for remote data. It handles caching and deduplication out of the box with zero boilerplate. - RTK Query: The logical choice if you’re already in the Redux Toolkit ecosystem. - createAsyncThunk: Best for custom async workflows where you need manual control over how the response affects multiple state slices. Pitfall: you manage caching and loading logic manually. Common scenarios: 1) UI/Local Behavior - Zustand / Context 2) Heavy API usage (No Redux) - TanStack Query 3) Heavy API usage (Using Redux) - RTK Query 4) Complex, custom async logic - createAsyncThunk If you find yourself manually writing isLoading and isError booleans for every API call, it’s time to switch to a dedicated data-fetching library. Thanks to JavaScript Mastery, Hitesh Choudhary, RoadsideCoder.com, Traversy Media, Web Dev Simplified for sharing such valuable content for Frontend production-grade applications. #ReactJS #React19 #ReactHooks #TanStackQuery #ReduxToolkit #ReduxThunk #ReactContext #WebDevelopment #JavaScript

💾 LocalStorage & SessionStorage in JavaScript – Store Data Without a Database Did you know your browser can store data even after refresh — without any backend? JavaScript provides two powerful storage options: localStorage → persists even after browser restart sessionStorage → clears when the tab is closed Perfect for saving user preferences, tokens, UI state, etc. 🧠 When Should You Use Browser Storage? Remember logged-in user (non-sensitive data) Save theme (dark/light mode) Store cart items temporarily Prevent unnecessary API calls 🚀 Why This Matters No server needed for small persistence Improves performance & UX Easy state management for frontend apps ⚠️ Best Practice Never store: ->Passwords ->Sensitive tokens ->Confidential user data Browser storage is not secure — it’s just convenient. #JavaScript #LocalStorage #SessionStorage #Frontend #WebDevelopment #Coding #InterviewPrep

React Just Got Way Cleaner If you’ve worked with React for a while, you know how messy data fetching used to feel. useEffect + useState, extra boilerplate, and manual loading/error handling — not fun. This new approach feels refreshingly simple 🔥 React Data Fetching: Then vs Now Before: - useState - useEffect - manual loading & error handling Now: -use(fetchUser()) — that’s it. Example : function User() {  const [user, setUser] = useState(null);  fetchUser().then(setUser);  if (!user) return <p>Loading...</p>;  return <div>{user.name}</div>; } TO function User() {  const user = use(fetchUser());  return <div>{user.name}</div>; } Declarative, readable, and much easier to reason about. React’s evolution is clearly leaning toward better developer experience, and I’m loving it. Cleaner code, fewer bugs, faster development 💯 What do you think — is this the future of data fetching in React? Drop your thoughts below and let’s learn from each other 👇 #ReactJS #JavaScript #Frontend #WebDevelopment #CleanCode #DeveloperExperience #ReactTips

⚡ 𝗥𝗲𝗮𝗰𝘁 𝗖𝗮𝗰𝗵𝗶𝗻𝗴 𝗔𝗣𝗜 𝗗𝗮𝘁𝗮 (𝗥𝗲𝗮𝗹-𝗪𝗼𝗿𝗹𝗱 𝗣𝗮𝘁𝘁𝗲𝗿𝗻) In my last few posts, I shared about: • Pagination • Retry logic • Infinite Scroll Today I want to talk about one thing I recently focused on while building React apps 👇 𝗖𝗮𝗰𝗵𝗶𝗻𝗴 𝗔𝗣𝗜 𝗱𝗮𝘁𝗮 ❓ 𝗪𝗵𝘆 𝗶𝘀 𝗰𝗮𝗰𝗵𝗶𝗻𝗴 𝗶𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁? When we don’t use caching: – The same API gets called again and again – Network calls increase – UI feels slower than it should ✅ 𝗦𝗼 𝘄𝗵𝗮𝘁 𝗶𝘀 𝗔𝗣𝗜 𝗰𝗮𝗰𝗵𝗶𝗻𝗴? In simple words: We store the API response somewhere and reuse it instead of calling the API every time. This helps in: • Faster UI • Better performance • Smoother user experience 🧠 𝗕𝗮𝘀𝗶𝗰 𝗶𝗱𝗲𝗮 𝗜 𝗳𝗼𝗹𝗹𝗼𝘄𝗲𝗱 1️⃣ Call the API 2️⃣ Store the response (state / ref / object) 3️⃣ Next time, check if data already exists 4️⃣ If yes → use it 5️⃣ If not → call the API again 🔄 𝗖𝗮𝗰𝗵𝗶𝗻𝗴 𝗶𝘀 𝗿𝗲𝗮𝗹𝗹𝘆 𝘂𝘀𝗲𝗳𝘂𝗹 𝗶𝗻 𝗰𝗮𝘀𝗲𝘀 𝗹𝗶𝗸𝗲 ✔️ Pagination ✔️ Infinite scroll ✔️ Navigating back and forth ✔️ Avoiding duplicate API calls This small change makes a 𝗯𝗶𝗴 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲 𝗶𝗻 𝗿𝗲𝗮𝗹-𝘄𝗼𝗿𝗹𝗱 𝗮𝗽𝗽𝘀. 📸 I’ve attached a small code snippet showing: • Simple in-memory caching • Avoiding repeated API calls 👉 𝗡𝗲𝘅𝘁 𝘁𝗼𝗽𝗶𝗰𝘀 𝗜’𝗺 𝗽𝗹𝗮𝗻𝗻𝗶𝗻𝗴: • Pagination vs Infinite Scroll (interview point of view) • Intro to React Query (why it’s used in real projects) Would love to know — 𝘄𝗵𝗮𝘁 𝘀𝗵𝗼𝘂𝗹𝗱 𝗜 𝘀𝗵𝗮𝗿𝗲 𝗻𝗲𝘅𝘁? 👇 #ReactJS #FrontendDevelopment #ReactHooks #JavaScript #LearningInPublic #WebDevelopment

𝗘𝘃𝗲𝗿 𝘄𝗼𝗻𝗱𝗲𝗿𝗲𝗱 𝘄𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝗯𝗲𝗵𝗶𝗻𝗱 𝘁𝗵𝗲 𝘀𝗰𝗲𝗻𝗲𝘀 𝘄𝗵𝗲𝗻 𝘆𝗼𝘂 𝗰𝗹𝗶𝗰𝗸 𝗮 <𝗟𝗶𝗻𝗸> 𝗶𝗻 𝗡𝗲𝘅𝘁.𝗷𝘀? 🚀 It’s not just a simple redirect. It’s a sophisticated orchestration between the Client and the Server. Here’s a deep dive into the Next.js "Magic": 1️⃣ The Silent Trigger (Client-Side Navigation) 🖱️ When you click a <Link href="/blog/123">, Next.js prevents a full browser reload. Instead, it triggers an internal router that sends a "hit" to the server. But wait—there’s no fetch in your code, right? Next.js does it automatically by requesting an RSC Payload (Remote Server Component data). 2️⃣ The Manifest File: The Address Book 📖 How does the server know to execute app/blog/[id]/page.tsx and not some other file? During the build process, Next.js generates a Manifest File. It’s a mapping system that says: "If a request comes for /blog/any-id, wake up this specific Page function." 3️⃣ Injecting Params into the Server Engine 💉 Next.js parses the URL, extracts the dynamic segment (123), and injects it as a params object into your BlogPage component. Since this happens on the Server, your component can securely access .env variables or databases without exposing them to the client. 4️⃣ The Async Dance & Loading States ⏳ Since the BlogPage is an async function, the server waits for the data (e.g., postService.getBlogById(id)). In the meantime, Next.js keeps the UI responsive by instantly showing the loading.tsx UI to the user. No blank screens, just smooth streaming. 5️⃣ Seamless Deliver 📦 Once the data is ready, the server renders the HTML and "streams" it back to the browser. The client-side React then "hydrates" the page, making interactive elements like links and buttons live. 🎯The takeaway? Next.js abstracts away the complex network requests and routing logic, allowing us to write code that feels local but runs globally. #NextJS #WebDevelopment #ReactJS #FullStack #SoftwareArchitecture #JavaScript #CodingTips

𝙍𝙚𝙖𝙘𝙩 𝙌𝙪𝙚𝙧𝙮 𝘾𝙝𝙖𝙣𝙜𝙚𝙙 𝙃𝙤𝙬 𝙄 𝙃𝙖𝙣𝙙𝙡𝙚 𝘼𝙋𝙄𝙨 Before React Query, data fetching usually meant: -useEffect -loading states -error states -manual refetching -weird bugs when components re-render -A lot of boilerplate. A lot of headache. 𝙒𝙝𝙖𝙩 𝙢𝙖𝙠𝙚𝙨 𝙍𝙚𝙖𝙘𝙩 𝙌𝙪𝙚𝙧𝙮 𝙖 𝙡𝙞𝙛𝙚𝙨𝙖𝙫𝙚𝙧: -Automatic caching -Built-in loading & error states -Smart refetching -Cleaner components -Less bugs, more peace You stop fighting state management and start focusing on building features. Once you use React Query properly, going back feels painful. If you’re working with APIs in React and not using it yet you’re making life harder than it needs to be. #React #ReactQuery #Frontend #WebDevelopment #DeveloperExperience #JavaScript

🚀 Day 8: React Server Components - The Server-Side Revolution As we kick off Week 2 of our 30 day series, we are diving deep into the tech stack that is defining 2026: React 19 and Next.js 15. The biggest shift? The move toward React Server Components (RSC). In my work architecting enterprise-level AI tools and financial dashboards, RSC has moved from a "cool feature" to a non-negotiable standard for high-performance applications. Why RSC is a game-changer for Senior Engineers: • Zero Bundle Size Impact: We can now keep complex logic and large dependencies on the server, ensuring our client-side bundle stays lean. +1 • Data Fetching at the Source: Fetching data directly on the server reduces the "waterfall" effect, which is crucial when targeting a 15% reduction in page load times. • Security by Design: Keeping sensitive API keys and business logic off the client-side is essential for the financial and AI sectors I work in. +1 • SEO & Initial Render: Delivering pre-rendered HTML improves both user engagement and search visibility—metrics I’ve used to boost website traffic by 25% in past projects. Mastering RSC isn't just about learning a new syntax; it’s about a fundamental shift in how we think about the Front-End Architecture. Are you fully on board with the Server Component revolution, or are you still sticking to Client-Side everything? #ReactJS #NextJS #ReactServerComponents #WebPerformance #FrontEndArchitecture #TypeScript #SoftwareEngineering #30DaysOfTech #WebDev #FullStack #SoftwareArchitect #TechLeadership #JavaScript #CodingLife #CareerGrowth #Innovation #AI #FinTech

𝟑 𝒇𝒓𝒐𝒏𝒕𝒆𝒏𝒅 𝒕𝒊𝒑𝒔 𝒕𝒉𝒂𝒕 𝒒𝒖𝒊𝒆𝒕𝒍𝒚 𝒇𝒊𝒙 𝒎𝒐𝒔𝒕 𝑼𝑰 𝒃𝒖𝒈𝒔 --- 1️⃣ 𝐑𝐞𝐚𝐜𝐭 𝐭𝐨 𝐨𝐮𝐭𝐜𝐨𝐦𝐞𝐬, 𝐧𝐨𝐭 𝐫𝐞𝐪𝐮𝐞𝐬𝐭𝐬 The UI shouldn’t care that a request was sent. It should care whether it succeeded, failed, or returned nothing. 2️⃣ 𝐓𝐫𝐞𝐚𝐭 𝐀𝐏𝐈 𝐫𝐞𝐬𝐩𝐨𝐧𝐬𝐞𝐬 𝐚𝐬 𝐔𝐈 𝐬𝐭𝐚𝐭𝐞𝐬 Data isn’t just data. Each response defines what the user should see next. 3️⃣ 𝐏𝐫𝐞𝐟𝐞𝐫 𝐨𝐧𝐞 𝐜𝐥𝐞𝐚𝐫 𝐬𝐭𝐚𝐭𝐮𝐬 𝐨𝐯𝐞𝐫 𝐦𝐮𝐥𝐭𝐢𝐩𝐥𝐞 𝐛𝐨𝐨𝐥𝐞𝐚𝐧𝐬  loading | success | empty | error is easier to reason about than five flags fighting each other. These aren’t performance tricks. ➥ They’re clarity tricks. Clean frontend code starts with predictable data contracts... ➨ not more hooks or libraries. 𝐏𝐒: This thinking lives at the frontend–backend boundary, which is where most real-world UI bugs actually come from. Follow — Fatima Hamid for simple, practical lessons that grow with you —from basics to advanced. . . . . ➥ Tags: Mian Ahmad Basit #ReactPracticalProject #learningReact #ReactSeries #CodingJourney #ReactDevelopment #WomenInTech #ReactJS #NodeJS #webdeveloper #FrontendDevelopment #JavaScript #FatimaHamid #webdesigner #MERNstackdeveloper #DevLife #Linkedin #softwaredevelopment #TechCommunity #fullstackdeveloper #MongoDB #Express

⚡ Stop using .filter() and .map() together. Focus on iteration efficiency. I've seen this pattern in 100+ React codebases this year: const users = data .filter(user => user.active) .map(user => <UserCard {...user} />); Looks clean. Feels right. But here's the problem? Your code loops through that array TWICE. Your browser processes it twice. That's wasted computation. ━━━━━━━━━━━━━━━━━━━━━━━━━ The Issue: ❌ Two iterations over same array ❌ Creates intermediate arrays in memory ❌ Slows down large datasets ❌ Unnecessary extra passes ━━━━━━━━━━━━━━━━━━━━━━━━━ The Better Way: ✅ Use reduce() → Single loop ✅ One pass through data ✅ Better performance on large datasets ✅ Better edge case handling ━━━━━━━━━━━━━━━━━━━━━━━━━ Why This Matters: • Performance: Only loops once • Efficiency: Processes data in single iteration • Scalability: Handles 10K+ items smoothly • Optimization: No wasted computation Master the basics before reaching for optimization libraries. ━━━━━━━━━━━━━━━━━━━━━━━━━ 💬 Question for you: Do you prefer readability (.filter().map()) or performance (reduce())? Is there a middle ground I'm missing? Let's debate in the comments. 👇 #JavaScript #ReactJS #WebDevelopment #CodingTips #Performance #FrontendDevelopment #BestPractices #Coding #TechTips #DeveloperCommunity

✋ Stop using useEffect for data fetching in React 19. For years, useEffect was our "everything tool." We used it for data fetching, synchronization, and state management. But it came with a cost: race conditions, boilerplate, and the "flicker" of empty loading states. In 2026, if you are still writing useEffect(() => { fetchData() }, []), you are working against the library, not with it. 💡 What changed? React 19, combined with the new use API and Server Components, has moved the industry toward Declarative Data Fetching. 1️⃣ The use Hook 🚀 You can now call the use() hook directly in your component to handle a Promise. No more useState(null) or setIsLoading(true). React handles the "pending" state for you via Suspense. 2️⃣ Server Components (RSC) 🏗️ Why fetch on the client at all? With Server Components, you can await your data directly in the component. The data stays on the server, and the client receives a fully populated UI. 3️⃣ Transition & Action Hooks ⚡ With useActionState and useFormStatus, the complex logic of managing "pending" states during form submissions is now built in. No more manual effect-based cleanup. 📉 Why this is better: Less Code: Say goodbye to setLoading, setError, and setData state triplets. Better UX: Suspense boundaries allow for smoother loading skeletons without layout shifts. Zero Race Conditions: React manages the lifecycle of the request, so you don't have to manually abort fetch calls. 🧱 The Bottom Line: useEffect should be your last resort, reserved only for synchronizing with external systems (like a non-React widget or a browser API). For everything else, the new hooks and patterns are faster, cleaner, and more robust. Are you still a useEffect fan, or have you embraced the use hook and Suspense? Let’s discuss in the comments! 👇 Follow me on LinkedIn: https://lnkd.in/e_thXEXu Visit my profile: https://mtehseen.com/ #ReactJS #React19 #WebDevelopment #Frontend #JavaScript #CleanCode #ReactHooks #WebDev #SoftwareEngineering #CodingTips #FrontendDeveloper