Avoiding Network Race Conditions with AbortController

Day 92 of 2026 🧠 While everyone is arguing over Vercel's controversial new edge-compute pricing model dropped this morning, I’m focused on code that doesn't rack up a $10,000 server bill. I used to think modern JavaScript was completely memory-leak proof. I was wrong. Status: The Memory Sweep 🧹 I built a real-time dashboard that looked flawless for the first 10 minutes. But if a user left the tab open during their lunch break, their browser would freeze, the memory usage would spike to 2GB, and the app would crash. The garbage collector couldn't save me because I was holding onto data forever. I deployed the "Memory Sweep" Protocol: ⏱️ 1. The Uncleared Interval I used `setInterval` to fetch new data every 5 seconds. The Fix: When the user navigates away from that component, the interval keeps firing in the background forever. Always return a cleanup function (`clearInterval`) inside your `useEffect` or lifecycle unmount to destroy the timer. 👂 2. The Ghost Listeners I attached an event listener (`window.addEventListener('scroll', handleScroll)`) to trigger animations. The Fix: If you don't explicitly call `removeEventListener` when the component unmounts, the browser creates a duplicate listener every single time the user visits the page. Hundreds of ghost listeners will crash the tab. 🧟 3. Zombie Closures I stored large datasets in global variables outside my functions. The Fix: Functions in JavaScript retain access to their outer scope (closures). If a temporary function captures a massive 50MB array and never gets dereferenced, that 50MB is permanently trapped in RAM. Keep data scope as localized as possible. ----- Resource 📚 👉 Chrome DevTools Memory Inspector: Stop guessing why your app is slow. Take a verifiable "Heap Snapshot" before and after a user action. This built-in tool literally highlights the exact detached DOM nodes and arrays causing your memory leaks. (Creator: Paul Irish) ----- 👇 Devs, what is the sneakiest performance killer? A: Uncleared intervals and timeouts B: Duplicate event listeners attached to the window C: Massive un-optimized images Powered by: 🧠 Mindset: Performance Engineering ⚡ Protocol: The Memory Sweep #WebDevelopment #JavaScript #ReactJS #SoftwareEngineering #Founders #BuildInPublic #Day92 : Avinash

Most React developers use data fetching libraries. Very few actually understand what’s happening under the hood. So I built something to fix that. 🚀 React Fetch Playground A visual lab to see how data fetching really works. 🔗 https://lnkd.in/gsahNcJi --- 💭 You’ve probably used things like: - caching - staleTime - background refetch - retries - optimistic updates But have you ever seen them happen? This tool makes it visible 👇 --- 🧠 What makes it different Instead of docs or theory, you get a real-time visual timeline: → request starts → data loads → cache becomes stale → background refetch kicks in All happening live. --- ⚡ Play with it like a lab - Switch between fetch / axios / custom hooks / TanStack Query - Simulate failures and retries - Control stale time and refetch intervals - Inspect cache, query state, and network behavior It’s basically DevTools for learning data fetching. --- 🔥 Why this matters (especially for senior FE roles) Understanding this deeply helps you: - avoid unnecessary re-renders - design better caching strategies - improve perceived performance - debug production issues faster This is the difference between using a library and thinking like a system designer. --- 📦 What’s next - Extracting reusable hooks as a package - Plugin system for other data libraries - More advanced visualizations (cache graphs, render impact) --- If you're preparing for frontend interviews or working on large-scale apps, this might be useful. Would love your thoughts 👇 #React #FrontendEngineering #JavaScript #WebPerformance #SystemDesign #OpenSource #TanStackQuery #DevTools

🚀 React 18 vs React 19 — The Evolution of Data Fetching (Old vs New Way). 🔯 React has consistently improved the developer experience, and data fetching is one of the best examples of that evolution. If you've worked with React 18, you're probably familiar with this pattern 👇 👉 useState + useEffect + loading + error handling. 1️⃣ Managing multiple states (data, loading, error) 2️⃣ Handling side effects manually 3️⃣ Writing repetitive and verbose code 🔯 React 18 (Traditional Approach) 1️⃣ Data is fetched after the component mounts 2️⃣ UI renders first, then updates with data 3️⃣ Developers must manually handle: 1) Loading state. 2) Error state. 3) Data rendering. 📉 Downsides: 1) More code to write. 2) Reduced readability. 3) Repeated logic across components. 🔯 React 19 (Modern Approach with use() + Suspense) 🟢 React 19 introduces a much cleaner and more declarative way to handle async data. 👉 Key idea: Let React handle asynchronous logic. 1) You create a Promise for your data. 2) The use() hook reads that Promise directly. 3) If data is not ready → React automatically suspends the component. 4) Suspense displays a fallback UI (e.g., Loading...). 📉 Benefits: 1) No need for manual loading state. 2) No useEffect required. 3) Cleaner and more readable code. 4) Built-in async handling. 🧠 Important Note 👉 The use() + Suspense pattern in React 19 is especially powerful when used with: 1) Server Components. 2) Streaming / SSR. 3) Data-intensive. application 💡 Conclusion React 18 laid a strong foundation, but React 19 takes it to the next level: 👉 Less code. 👉 Better performance patterns. 👉 Cleaner mental model. ✅ But that doesn't mean useEffect is gone. You STILL need useEffect for: ⏳ Timer. 🔔 Event Listener's. 🔌 WebSocket Connections. 📊 Analytics Tracking. 🎧 Subscriptions. 🧹Clean-Up Logic. 💬 Have you tried this in your project? 💬 React 18 or 19 — what are you using? #ReactJS #FrontendDevelopment #WebDevelopment #JavaScript #React18 #React19 #CodingLife #SoftwareDeveloper #ReactHooks #ModernReact #DeveloperJourney #TechContent

🟨 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗗𝗮𝘆 𝟱𝟴: 𝗗𝗮𝘁𝗮 𝗡𝗼𝗿𝗺𝗮𝗹𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗶𝗻 𝗥𝗲𝗮𝗰𝘁 (𝗪𝗵𝘆 𝗡𝗲𝘀𝘁𝗲𝗱 𝗦𝘁𝗮𝘁𝗲 𝗗𝗼𝗲𝘀𝗻’𝘁 𝗦𝗰𝗮𝗹𝗲) Ever built a drag & drop UI or complex state… and updates started getting messy? 🤔 🔹 𝗪𝗵𝗲𝗿𝗲 𝗧𝗵𝗶𝘀 𝗛𝗮𝗽𝗽𝗲𝗻𝘀 APIs usually return nested data 👇 But in React, we often transform it into a normalized structure for easier updates & better performance. 🔹 𝗧𝗵𝗲 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 (𝗡𝗲𝘀𝘁𝗲𝗱 𝗦𝘁𝗮𝘁𝗲) const data = [ { id: "todo", cards: [ { id: 1, title: "Fix bug" }, { id: 2, title: "Update UI" } ] }, { id: "progress", cards: [ { id: 3, title: "API work" } ] } ]; 👉 Moving a card = moving full object 😵 👉 Updating = deep nested changes ❌ 👉 Causes unnecessary re-renders in React 🔹 𝗧𝗵𝗲 𝗙𝗶𝘅 (𝗡𝗼𝗿𝗺𝗮𝗹𝗶𝘇𝗮𝘁𝗶𝗼𝗻) const data = { columns: { todo: { id: "todo", cardIds: [1, 2] }, progress: { id: "progress", cardIds: [3] } }, cards: { 1: { id: 1, title: "Fix bug" }, 2: { id: 2, title: "Update UI" }, 3: { id: 3, title: "API work" } } }; 👉 Columns store only IDs 👉 Cards stored once (single source of truth) 🔹 𝗪𝗵𝗮𝘁 𝗖𝗵𝗮𝗻𝗴𝗲𝗱 (𝗥𝗲𝗮𝗰𝘁 𝗣𝗲𝗿𝘀𝗽𝗲𝗰𝘁𝗶𝘃𝗲) Before: • Deep state updates • Re-renders large parts of UI • Hard to maintain After: • Update small pieces of state ✅ • Minimal re-renders (better performance) ⚡ • Cleaner, predictable updates 🔹 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆 👉 In React, treat state like a database • Store entities once • Reference them using IDs 👉 Drag & Drop = move IDs, not objects 💬 GitHub link in comments. #JavaScript #React #Frontend #Day58 #100DaysOfCode

Do yourself a favor and run this against anything you code with AI-assistance if you favor Next. Modify for your preferred language. Adhere to these strict standards: 1. Accuracy & Hallucination Prevention: - Version Verification: Only use libraries and features compatible with Next.js 16 and Node.js 24+. If a feature or API is deprecated or experimental, state it clearly. - Never suggest a library or NPM package that does not exist. If you are unsure of an API's current schema, ask me to provide the latest documentation or schema file. 2. Architecture & DRY Principles: - Do not duplicate code across files. Use Higher-Order Components (HOCs), custom Hooks, or centralized Utility Classes in src/lib/ or src/utils/. - Prioritize the simplest solution that solves the problem. Before writing a complex 50-line function, check if a native JavaScript/Node.js method or a standard Next.js pattern exists. - Design for maintainability. Keep components small and logic decoupled from UI. 3. Security & Production-Readiness: - Always validate incoming data (Webhooks, Form inputs) using Zod. - Never hardcode keys. Always use process.env and provide a template for a .env.example file. - Avoid dangerouslySetInnerHTML, eval(), or unescaped database queries. 4. "Vibe-Code" Remediation: - Before providing a solution, mentally "lint" the code for over-engineering. If the solution is becoming too complex for an internal tool, suggest a leaner alternative. - All code must be written in Strict TypeScript. Avoid the any type at all costs; define proper Interfaces or Types for all API responses. 5. Performance & State Management Strategy: - Favor URL State (search params) for filtering, pagination, and tabs. This allows for deep-linking and eliminates the need for complex client-side store synchronization. - Only use useState or useReducer for immediate UI interactions (e.g., toggling a modal). For global state, use React Server Components (RSC) to fetch data and Server Actions to mutate it, leveraging revalidatePath or revalidateTag to keep the UI fresh. 6. Data Fetching Efficiency: - Use Promise.all() when fetching from multiple APIs to avoid "waterfall" delays. - Implement loading.tsx and Suspense boundaries to stream heavy data components so the page remains interactive. - Ensure all images or dashboard exports are optimized using next/image. - Tree-shake third-party SDKs; only import the specific functions needed from libraries. - Use the Next.js cache function for expensive data transformations and the unstable_cache for third-party API results that don't change frequently.

In this post, I focused on visualizing how data moves within a React application using a Data Flow Diagram (DFD). Understanding data flow allows developers to: • Build more organized and scalable applications • Avoid unnecessary complexity and bugs • Clearly separate logic from UI • Improve maintainability and readability This approach helped me move beyond writing components to truly understanding how data drives the entire application. #React #Frontend #WebDevelopment #JavaScript #SoftwareArchitecture #CleanCode

I inherited a codebase built on Supabase Edge Functions. Here's exactly why I had to move off them when it came time to scale. Edge Functions are Deno-based isolates. That comes with constraints that aren't obvious until you hit them in practice, and they're even less obvious when you're picking up someone else's architectural decisions. 1. Memory ceiling Supabase Edge Functions cap at ~150MB. That sounds fine until you're running DuckDB-WASM (~30MB) inside one, then fetching and processing a file from Storage on top of that. The headroom disappears fast and there's no way to configure it. 2. The Deno runtime is not Node.js Most npm packages assume a Node.js environment. In Deno you're importing via esm.sh, dealing with compatibility shims, and discovering at runtime that a package has Node-specific dependencies that silently break. Every new dependency becomes a research task before it becomes a tool. 3. Long-running processes don't belong in serverless isolates Edge Functions are designed for short, stateless request/response cycles. If you need a persistent DuckDB connection, warm with a file potentially cached between requests, you're fighting the platform. Every invocation starts cold. The connection you carefully initialised is gone. 4. The wrong execution model for the work Serverless billing is per invocation and duration. For analytical workloads that involve fetching large files and running complex queries, that model gets expensive quickly and unpredictably. A persistent Hono service on Fly.io costs a fixed amount per month regardless of query complexity. The replacement: a dedicated Hono service on Fly.io/Railway running via @hono/node-server. Persistent process, persistent DuckDB connection, no memory ceiling, no Deno import gymnastics, predictable cost. The same framework also handles the client-facing API layer with typesafe routes via @hono/zod-openapi and hono/client, so both services speak the same language. The lesson: Edge Functions are excellent for what they're designed for. Lightweight, stateless, globally distributed request handling. The moment you need persistent state, heavy compute, or memory-intensive workloads, you've outgrown the model. When you inherit a codebase, you inherit its tradeoffs too. The original choice made sense at the time. Recognising when it stops making sense is the job. Supabase itself is not the problem. The Edge Function runtime just isn't the right tool for every job. #webdevelopment #softwarearchitecture #typescript #hono #buildinpublic

The "Ghost in the API": How I fixed a major rendering lag 👻 While working on a complex user dashboard at Codes Thinker, I encountered a frustrating performance bottleneck. Every time a user triggered a data fetch, the entire UI would "freeze" for a split second before updating. Even with a fast backend API, the user experience felt "heavy" and unprofessional. The Challenge: We were fetching large, nested JSON objects directly inside a parent component. Every time the API responded, the entire component tree re-rendered, causing a visible performance lag during data transformation. The Solution: React Query: I implemented React Query to handle caching. This ensured that if a user requested the same data twice, the result was instant. Data Transformation: Instead of passing the raw "heavy" object to components, I mapped the data into a lighter format immediately after fetching. Optimistic UI: I used Tailwind CSS to create smooth skeleton loaders, making the app feel faster while the data was still loading. The Result: The rendering lag disappeared, and the user experience became fluid. Sometimes, being a Senior Frontend Developer is about knowing when not to fetch data as much as how to fetch it. Have you ever faced a stubborn API lag? How did you tackle it? Let’s share some dev stories! 👇 #RESTAPI #NextJS #PerformanceOptimization #MERNStack #WebDevelopment #CleanCode #ReactJS #TailwindCSS

Just published a deep-dive on Angular Signal Forms vs Reactive Forms on Medium. Angular 21 shipped Signal Forms as an experimental feature — and it's not just a new API, it's a different mental model. The article covers: - The actual syntax from @angular/forms/signals - How the new schema-based validation works - Change detection differences vs Zone.js - Submission patterns and reacting to field changes - Honest take on when to migrate and when to stay with Reactive Forms https://lnkd.in/dne9gZMi #Angular #Signals #TypeScript #Frontend 

𝐘𝐨𝐮𝐫 `useEffect` 𝐢𝐬 𝐥𝐲𝐢𝐧𝐠 𝐭𝐨 𝐲𝐨𝐮 (𝐨𝐫 𝐦𝐚𝐲𝐛𝐞 𝐲𝐨𝐮'𝐫𝐞 𝐥𝐲𝐢𝐧𝐠 𝐭𝐨 𝐢𝐭). Ever wonder why your `useEffect` hook fires endlessly, or seemingly ignores state updates? The culprit is often more subtle than a missing dependency: it's how JavaScript handles equality for non-primitive types in your dependency array. When you put an object, array, or function directly into `useEffect`'s dependency array, React performs a shallow comparison. If that object/array is re-created on every render (even if its contents are the same), `useEffect` sees a "new" dependency and re-runs. This is a classic source of infinite loops or performance bottlenecks. **Example:** ```jsx // Problematic: obj is new on every render const MyComponent = ({ data }) => { const obj = { id: data.id, name: data.name }; useEffect(() => { // This runs on every render if obj is not memoized console.log('Doing something with obj', obj); }, [obj]); // <--- Shallow comparison sees a new obj reference // ... } ``` **Better approaches:** 1. **Destructure primitives:** If you only need specific primitive values from an object, pass those directly. ```jsx useEffect(() => { console.log('Doing something with id and name', data.id, data.name); }, [data.id, data.name]); // <--- Primitives are compared by value ``` 2. **`useMemo` for stable objects/arrays:** If you absolutely need the whole object, ensure it's memoized. ```jsx const memoizedObj = useMemo(() => ({ id: data.id, name: data.name }), [data.id, data.name]); useEffect(() => { console.log('Doing something with memoizedObj', memoizedObj); }, [memoizedObj]); ``` 3. **`useCallback` for stable functions:** Always wrap functions defined inside components (and passed as props or dependencies) with `useCallback`. Understanding this shallow comparison nuance is key to writing robust and performant React components. It's often where the toughest `useEffect` bugs hide! How do you debug tricky `useEffect` dependencies? Share your tips! #React #JavaScript #Frontend #WebDevelopment #TypeScript