React 19: Ditch useEffect for Declarative Data Fetching

Built a tracking map component that doesn’t break when data is messy In real life, location data isn’t always perfect , APIs fail, coordinates come in late, or values are invalid. So I built a React + Leaflet Tracking Map that: ~ Validates latitude & longitude before rendering ~ Prevents crashes from bad location data ~ Shows a clear fallback when location is unavailable Instead of a broken map, users get a reliable experience. Small frontend decisions like this make products feel stable, trustworthy, and production-ready. #FrontendDevelopment #ReactJS #JavaScript #UXEngineering #CleanCode #WebDevelopment

A post about React after a long time: 🚀 Why useState feels "slow" and Zustand feels like magic ? Ever noticed that when you call setState, your data isn’t actually updated until the next render? If you console.log it immediately after, you’re looking at the previous data. On the other hand, If you’ve used Zustand, you’ve probably noticed something different: it feels immediate. This happens because the execution model is fundamentally different. ⏱️ The useState :- React handles state updates asynchronously (Not actually async but it schedules update so it feels like async). When you update state, you aren't changing a variable; you are scheduling a re-render. You are trapped in a "closure" of the current render until the whole component cycles again. It is something like this: "I’ve noted your request. I'll show you the new value in a moment." ⚡ The Zustand :- Zustand lives outside the React render cycle. When you trigger an action, the store updates synchronously. The data changes now, and React is notified to catch up afterward. it is something like this: "Consider it done. I'll let the UI know we've already moved on." #ReactJS #Zustand #WebDevelopment #Frontend #JavaScript #CodingTips #Typescript

🚦 𝗛𝗮𝗻𝗱𝗹𝗶𝗻𝗴 𝗟𝗼𝗮𝗱𝗶𝗻𝗴, 𝗘𝗿𝗿𝗼𝗿 & 𝗦𝘂𝗰𝗰𝗲𝘀𝘀 𝗦𝘁𝗮𝘁𝗲𝘀 𝗶𝗻 𝗥𝗲𝗮𝗰𝘁 𝗔𝗣𝗜 𝗖𝗮𝗹𝗹𝘀 When working with APIs in React, fetching data is just 𝗵𝗮𝗹𝗳 𝘁𝗵𝗲 𝗷𝗼𝗯. A real-world app must clearly handle 𝘄𝗵𝗮𝘁 𝘁𝗵𝗲 𝘂𝘀𝗲𝗿 𝘀𝗲𝗲𝘀 𝗮𝘁 𝗲𝘃𝗲𝗿𝘆 𝘀𝘁𝗮𝗴𝗲 👇 🔄 Loading ❌ Error ✅ Success That’s why managing these states is 𝘀𝘂𝗽𝗲𝗿 𝗶𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁 for good UX and interviews. 🧠 𝗧𝗵𝗲 𝟯 𝗦𝘁𝗮𝘁𝗲𝘀 𝗘𝘃𝗲𝗿𝘆 𝗔𝗣𝗜 𝗖𝗮𝗹𝗹 𝗦𝗵𝗼𝘂𝗹𝗱 𝗛𝗮𝗻𝗱𝗹𝗲 1️⃣ 𝗟𝗼𝗮𝗱𝗶𝗻𝗴 𝗦𝘁𝗮𝘁𝗲 Show a loader or skeleton while data is being fetched ➡️ Prevents blank screens & confusion 2️⃣ 𝗘𝗿𝗿𝗼𝗿 𝗦𝘁𝗮𝘁𝗲 Handle network/server failures gracefully ➡️ Show a meaningful message instead of crashing the UI 3️⃣ 𝗦𝘂𝗰𝗰𝗲𝘀𝘀 𝗦𝘁𝗮𝘁𝗲 Render the actual data only when everything goes right ➡️ Clean & predictable UI 🛠️ 𝗘𝘅𝗮𝗺𝗽𝗹𝗲 (𝘄𝗶𝘁𝗵 𝘂𝘀𝗲𝗙𝗲𝘁𝗰𝗵 𝗖𝘂𝘀𝘁𝗼𝗺 𝗛𝗼𝗼𝗸) 📸 I’ve attached a code screenshot showing how these states are handled in a real React component. ✅ 📌 𝗜𝗻 𝗺𝘆 𝗽𝗿𝗲𝘃𝗶𝗼𝘂𝘀 𝗽𝗼𝘀𝘁𝘀, 𝗜 𝗰𝗼𝘃𝗲𝗿𝗲𝗱: • useEffect for API calls • Cleanup & AbortController • Reusable useFetch custom hook This post completes the 𝗳𝘂𝗹𝗹 𝗔𝗣𝗜-𝗵𝗮𝗻𝗱𝗹𝗶𝗻𝗴 𝗽𝗶𝗰𝘁𝘂𝗿𝗲 🧩 👉 Next, I’ll cover 𝗽𝗮𝗴𝗶𝗻𝗮𝘁𝗶𝗼𝗻 / 𝗿𝗲𝘁𝗿𝘆 𝗹𝗼𝗴𝗶𝗰 / 𝗰𝗮𝗰𝗵𝗶𝗻𝗴 in React APIs. Let me know what you want to see next 👇 #ReactJS #FrontendDevelopment #ReactHooks #JavaScript #WebDevelopment #InterviewPrep

React 19 just killed the useEffect data fetching headache! 🤯 For years, fetching data required a mess of useState, useEffect, and complex dependency arrays to avoid infinite loops and UI flickers. React 19 changes the game with the use() hook. The "Before" vs. "After": Before: Data fetching happened after rendering; you managed states and effects manually. Now (React 19): Data fetching happens during rendering. UI and data stay perfectly in sync. 🚀 Key Benefits of the use() Revolution: Zero Boilerplate: No more useEffect or local state just to store API results. No More Flickering: Eliminates the "loading → data" transition flicker. Built-in Error Handling: If a Promise fails, React automatically forwards it to the nearest ErrorBoundary—no more try/catch messes. Automatic Refetching: Changing an input (like a userId) cancels the old Promise and runs a new one automatically. React 19 turns asynchronous data into a first-class part of rendering. It’s less code, less setup, and more predictable behavior. What’s your favorite React 19 feature so far? Let’s discuss below! 👇 #ReactJS #React19 #FrontendDevelopment #JavaScript #WebDev #CodingLife

💡 𝗛𝗼𝘄 𝗜 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 𝗗𝗮𝘁𝗮 𝗙𝗲𝘁𝗰𝗵𝗶𝗻𝗴 𝗶𝗻 𝗠𝘆 𝗥𝗲𝗮𝗰𝘁 𝗣𝗿𝗼𝗷𝗲𝗰𝘁𝘀 𝗡𝗼𝘄 Earlier, I used to fetch data directly inside components. Everything in one place: API call. State. Loading. Error handling. UI rendering. It worked. But as features increased… components became messy. That’s when I changed how I structure things. 🚫 𝗕𝗲𝗳𝗼𝗿𝗲 Component → fetch → setState → render Big file. Mixed responsibilities. Hard to reuse. ✅ 𝗡𝗼𝘄 𝗜 𝗦𝗲𝗽𝗮𝗿𝗮𝘁𝗲 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝗶𝗲𝘀 I divide things into 3 clear layers: • API Layer (pure data fetching) • Custom Hook (data logic) • UI Component (only rendering) 🧠 𝗪𝗵𝘆 𝗧𝗵𝗶𝘀 𝗖𝗵𝗮𝗻𝗴𝗲𝗱 𝗠𝘆 𝗖𝗼𝗱𝗲 𝗤𝘂𝗮𝗹𝗶𝘁𝘆 ✔ Components became smaller ✔ Logic became reusable ✔ Easier to test ✔ Easier to scale ✔ Cleaner mental model Now when I build something, I ask: • Does this belong to UI? • Or is this data logic? • Or is this just an API function? That small shift improved how I design React apps. Frontend is not just about making things work. It’s about organizing them so they can grow. 👇 𝗦𝗶𝗺𝗽𝗹𝗲 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 𝗜 𝗙𝗼𝗹𝗹𝗼𝘄 I’ve attached a screenshot below showing how I separate: 📁 API folder 📁 Hooks folder 📁 Components folder This simple structure made my projects much easier to maintain. How do you structure data fetching in your React projects? 👀 #ReactJS #FrontendDevelopment #JavaScript #WebDevelopment #CleanCode #LearningInPublic

🚀 React Hooks & Rendering — A Clear Mental Model (For My Future Self Too) 🪝 What are React Hooks? Hooks are helpers that let a function component: remember data react to changes 🧠 Core React Hooks (WHAT + WHY) 🔹 useState — data that affects the UI Why it exists: React re-runs components often. Without state, values would reset every time. Use when: The user should see the change. 🔹 useEffect — side work after render Why it exists: Some work should happen after the UI is painted, not during it. Used for: API calls timers 🔹 useRef — remember without re-render Why it exists: Sometimes React needs to remember something without updating the UI. Two main uses: DOM access → focus input, scroll, measure Silent storage → timer IDs, previous values, flags 🔹 useContext — shared/global data Why it exists: To avoid passing props through many layers. Used for: logged-in user theme 🔹 useMemo — avoid heavy recalculations Why it exists: React re-runs components often → slow calculations can repeat unnecessarily. Use when: calculation is expensive 🔹 useCallback — stable functions Why it exists: Functions are recreated on every render. Used mainly when: passing callbacks to optimized child components 🌍 Rendering Types (WHY they exist) 🔹 CSR — Client Side Rendering What: Browser builds the UI Best for: dashboards, internal tools 🔹 SSR — Server Side Rendering What: Server sends ready HTML Why: Search engines need content 🔹 SSG — Static Site Generation What: Page built once at build time Why: Some content rarely changes Hope it helps someone else too. #React #JavaScript #Frontend #NextJS #WebDevelopment #LearningInPublic

🚀 React Hooks & Rendering — A Clear Mental Model (For My Future Self Too) 🪝 What are React Hooks? Hooks are helpers that let a function component: remember data react to changes 🧠 Core React Hooks (WHAT + WHY) 🔹 useState — data that affects the UI Why it exists: React re-runs components often. Without state, values would reset every time. Use when: The user should see the change. 🔹 useEffect — side work after render Why it exists: Some work should happen after the UI is painted, not during it. Used for: API calls timers 🔹 useRef — remember without re-render Why it exists: Sometimes React needs to remember something without updating the UI. Two main uses: DOM access → focus input, scroll, measure Silent storage → timer IDs, previous values, flags 🔹 useContext — shared/global data Why it exists: To avoid passing props through many layers. Used for: logged-in user theme 🔹 useMemo — avoid heavy recalculations Why it exists: React re-runs components often → slow calculations can repeat unnecessarily. Use when: calculation is expensive 🔹 useCallback — stable functions Why it exists: Functions are recreated on every render. Used mainly when: passing callbacks to optimized child components 🌍 Rendering Types (WHY they exist) 🔹 CSR — Client Side Rendering What: Browser builds the UI Best for: dashboards, internal tools 🔹 SSR — Server Side Rendering What: Server sends ready HTML Why: Search engines need content 🔹 SSG — Static Site Generation What: Page built once at build time Why: Some content rarely changes Hope it helps someone else too. #React #JavaScript #Frontend #NextJS #WebDevelopment #LearningInPublic

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

𝗘𝘃𝗲𝗿 𝘄𝗼𝗻𝗱𝗲𝗿𝗲𝗱 𝘄𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝗯𝗲𝗵𝗶𝗻𝗱 𝘁𝗵𝗲 𝘀𝗰𝗲𝗻𝗲𝘀 𝘄𝗵𝗲𝗻 𝘆𝗼𝘂 𝗰𝗹𝗶𝗰𝗸 𝗮 <𝗟𝗶𝗻𝗸> 𝗶𝗻 𝗡𝗲𝘅𝘁.𝗷𝘀? 🚀 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

In React, most “state bugs” are caused by state living in the wrong place 😅 Here’s how I decide between usign UI state vs URL state vs server state, without creating a spaghetti code 🍝🇮🇹 1) Local UI state (React useState) Use it when it’s temporary and component-scoped. For typing into an input ⌨️, open/closed modal 🪟, active tab 🗂️, toggle switches ✅. If the user refreshes and it resets and nobody cries, it belongs here. 🔗 2) URL state (route params / query params) Use it when the state should be shareable and navigable: if copy link 📎, bookmark ⭐, Back/Forward ⬅️➡️ should restore the view -> that's the usecase. Search query 🔎, filters 🧰, sorting ↕️, pagination 📄, selected item id 🆔, when it changes what the page “is”, it probably belongs in the URL🌐 3) Remote data state (async fetched data + cache) Use it when the truth lives outside the UI and comes over the network 🌐 Examples: lists/details 📋, permissions 🔐, feature flags ⚙️, anything shared across multiple screens. The “state” here is the client-side handling of it: cache, retries, refetch, stale-time, and invalidation 🔁🧠 React Query/SWR just standardize that so you don’t reinvent it with useEffect + useState everywhere. 🚫 Big rule stays valid: don’t copy fetched data into local React state unless you’re editing it ✍️ — otherwise you create two sources of truth and stale UI is born 😭 My quick rule of thumb: - UI behavior → React state ✅ - View definition/navigation → URL state 🔗 - Backend is the source of truth → remote state 🌐 #React #Frontend #WebDevelopment #JavaScript #TypeScript #StateManagement #ReactQuery #SWR #UX #SoftwareEngineering #WebApp #Developer #ProductEngineering #CleanCode