DEV Community: Lakshmi Bhargavi Gajula

From Confused to Confident: How I Finally Mastered GitHub Copilot in Every Situation

Lakshmi Bhargavi Gajula — Sat, 13 Jun 2026 18:16:14 +0000

From Confused to Confident: How I Finally Mastered GitHub Copilot in Every Situation

I still remember the afternoon I rage-closed VS Code because Copilot kept suggesting the wrong function signatures — again. I had been treating it like a magic oracle, typing vague comments and expecting perfect code to rain down from the AI heavens. Spoiler: that's not how it works.

After weeks of trial, error, and a few embarrassing pull request reviews, I cracked the code (pun intended). Here's everything I wish someone had told me about using GitHub Copilot accurately — across Chat, Plan, and Agent modes.

🧠 First, Understand What Copilot Actually Is

Before diving into tips, let's reset expectations. GitHub Copilot is not a search engine. It's not Stack Overflow with a fancy UI. It's a context-aware AI assistant trained on massive amounts of code. That means:

The quality of your output depends directly on the quality of your input.
It works best when it has rich context — open files, good comments, clear naming.
It can be wrong. Confidently wrong. Always review what it generates.

With that mindset locked in, let's explore each mode.

💬 Copilot Chat: Your Pair Programmer in the Sidebar

The first time I opened Copilot Chat, I typed: "fix my code." It stared back at me, basically confused. Of course it was — I hadn't told it which code, what was broken, or what I expected.

Tips for Accurate Chat Usage

1. Be specific and contextual.

Instead of:

"Why isn't this working?"

Try:

"This useEffect hook in React runs on every render instead of only when userId changes. Here's the code: [paste snippet]. What's wrong?"

The more context you give, the more surgical the answer.

2. Use slash commands to guide intent.

Copilot Chat supports built-in commands that dramatically improve accuracy:

/explain   → Explains selected code in plain English
/fix       → Suggests a fix for a highlighted bug
/tests     → Generates unit tests for selected code
/doc       → Writes documentation for a function or class

These aren't just shortcuts — they set the intent so Copilot doesn't have to guess what you want.

3. Reference your files explicitly.

In VS Code, you can use #file:filename.js in the chat to attach a specific file as context. This is a game-changer when your bug spans multiple files.

4. Iterate like a conversation.

Don't expect perfection on the first response. Treat it like a real pair programmer:

"That's close, but can you refactor it to use async/await instead of .then()?"
"Can you make this TypeScript-friendly?"

🗺️ Copilot Plan: Think Before You Build

This is the mode most developers skip — and it's the one that saves the most time.

I once spent three hours building a feature, only to realize mid-implementation that my database schema made no sense for the use case. If I had planned it with Copilot first, I would have caught that in ten minutes.

What Is Plan Mode?

Plan mode (available in Copilot Chat via @workspace or structured prompting) lets you think through architecture, approach, and steps before writing a single line of code.

Tips for Accurate Plan Usage

1. Ask Copilot to outline an approach first.

"I want to build a real-time notification system using WebSockets in Node.js 
and React. Before writing any code, can you outline the architecture, 
key components, and potential pitfalls?"

This forces a structured response you can critique before investing time.

2. Use it for breaking down complex tasks.

"Break down the steps needed to migrate this REST API to GraphQL. 
List them in order with potential blockers for each step."

3. Validate the plan collaboratively.

Once Copilot gives you a plan, push back:

"Is there a simpler approach?"
"What would be the tradeoffs of using Redis here vs. in-memory storage?"

This dialogue sharpens the plan before a single keystroke hits your editor.

🤖 Copilot Agent: Let It Drive (With Your Hands on the Wheel)

Agent mode is where things get wild — and where the most mistakes happen if you're not careful.

I once let Copilot Agent run loose on a refactoring task with a vague prompt. It refactored alright — it refactored everything, including files I didn't want touched. Lesson learned.

What Is Agent Mode?

Copilot Agent (part of GitHub Copilot Workspace and the newer agentic features in VS Code) can autonomously complete multi-step tasks — creating files, running terminal commands, editing across your codebase, and more.

Tips for Accurate Agent Usage

1. Write precise, scoped prompts.

Vague prompt:

"Refactor the project."

Precise prompt:

"Refactor only the authService.ts file to replace callback-based functions with async/await. Do not modify any other files."

Scope your instructions like you're writing a ticket for a junior developer. Specific. Bounded. Clear.

2. Review every step before confirming.

Copilot Agent will often show you a plan of actions before executing. Read it. Every line. It takes 30 seconds and can save you an hour of reverting changes.

3. Use it for repetitive, well-defined tasks.

Agent mode shines brightest on tasks like:

Generating boilerplate across multiple files
Writing and running test suites
Scaffolding a new feature following an existing pattern in the codebase

4. Keep your git history clean.

Before running Agent on anything significant, commit your current state. If something goes sideways, git reset is your best friend.

# Always do this before letting the agent loose
git add .
git commit -m "checkpoint before copilot agent refactor"

🔑 Universal Tips That Apply to Every Mode

No matter which mode you're in, these principles hold:

Name things clearly. Good variable and function names give Copilot massive context clues.
Write comments before code. A comment like // Fetch user data and cache it for 5 minutes gives Copilot a spec to work from.
Don't blindly accept suggestions. Tab-complete is tempting. Review first, accept second.
Keep your files focused. Smaller, single-responsibility files produce better suggestions than 800-line monoliths.
Restart and refresh context if suggestions start going off the rails — sometimes closing and reopening a file resets things.

🏁 The Takeaway

GitHub Copilot went from feeling like a broken toy to being my most-used development tool — and the only thing that changed was how I used it.

The secret isn't some hidden setting or magic prompt. It's treating Copilot like a brilliant but context-dependent collaborator. Give it clear goals, good context, and boundaries — and it will genuinely accelerate your workflow.

Start small: next time you open Chat, try a slash command. Next time you start a feature, ask Copilot to plan it first. And when you're ready for Agent mode, keep one hand on the git history.

You've got a powerful co-pilot now. Time to actually fly.

Have a Copilot tip that changed your workflow? Drop it in the comments — I'd love to add more tools to the toolkit. 🚀

Stop Burning Through Claude Tokens: Practical Tips Every Developer Should Know

Lakshmi Bhargavi Gajula — Sat, 13 Jun 2026 18:13:14 +0000

Stop Burning Through Claude Tokens: Practical Tips Every Developer Should Know

If you've integrated Claude into your workflow or your app, you've probably had that moment — the bill arrives (or the rate limit hits), and you think: where did all those tokens go? I've been there. And after spending an embarrassing amount of time optimizing prompts, restructuring conversations, and reading through Anthropic's documentation, I have some hard-won opinions to share.

This isn't a dry technical rundown. These are real lessons from real (sometimes painful) experience. Let's get into it.

🧠 First, Understand What You're Actually Paying For

Before you can reduce token usage, you need to understand the two-sided nature of token billing:

Input tokens: Everything you send to Claude — your system prompt, the conversation history, the user message.
Output tokens: Everything Claude generates back.

Here's the thing most developers underestimate: your system prompt and conversation history are re-sent on every single API call. That silent, invisible re-transmission is often the biggest culprit behind bloated token usage, especially in multi-turn applications.

✂️ Tip #1: Trim Your System Prompt Ruthlessly

System prompts are powerful, but they're also easy to let balloon out of control. I've seen system prompts that read like legal contracts — paragraphs of edge-case handling, personality descriptions, and disclaimers that Claude probably doesn't need.

Be surgical about it:

Remove redundant instructions. If you say "be concise" three times, once is enough.
Cut examples unless they're truly necessary for format enforcement.
Avoid explaining why Claude should do something unless it genuinely affects the output quality.

A well-written system prompt should be the minimum viable instruction set. Treat it like code — refactor it regularly.

# Before (verbose)
You are a helpful assistant. You should always be polite and professional.
Never be rude to users. Make sure your responses are accurate and helpful.
Always try to answer the user's question. Be concise when possible.

# After (lean)
You are a concise, professional assistant. Answer questions accurately and briefly.

That tiny cleanup can save hundreds of tokens per conversation when multiplied across thousands of calls.

🗂️ Tip #2: Manage Conversation History Strategically

This one trips up a lot of developers building chat-based applications. By default, you're probably passing the entire conversation history to Claude on every turn. For long conversations, this gets expensive fast.

Strategies to handle this:

Sliding window: Only pass the last N messages instead of the full history. Works well for most conversational use cases.
Summarization: Periodically ask Claude to summarize the conversation so far, then replace the raw history with that summary. You keep context without the token overhead.
Relevant retrieval: For knowledge-heavy apps, use vector search to pull only the relevant past messages rather than the whole thread.

There's no one-size-fits-all answer here — it depends on your use case. But ignoring history management entirely is almost always a mistake.

📏 Tip #3: Ask for Shorter Outputs Explicitly

Claude is trained to be thorough and helpful, which is great — until you're paying for 800 tokens when 200 would have done the job. Claude won't automatically be terse unless you tell it to be.

Try being explicit:

"Answer in 2-3 sentences."
"Respond with only the code, no explanation."
"Give me a bullet list, max 5 items."

This feels obvious, but it's surprising how many prompts just ask a question and hope for a brief answer. Claude interprets open-ended questions as an invitation to be comprehensive. Set expectations clearly.

⚠️ Tip #4: Watch Out for the Context Window Trap

Here's something to be careful about: just because Claude has a large context window doesn't mean you should use all of it carelessly. Stuffing the context with huge documents, long code files, or massive conversation histories might work, but it's often wasteful.

Before dumping a 10,000-token document into your prompt, ask yourself:

Does Claude actually need all of this information?
Can I extract the relevant section instead?
Could I use a retrieval strategy instead of brute-force context stuffing?

Big context windows are a capability, not an excuse to skip thoughtful prompt design.

🔄 Tip #5: Batch When You Can

If you're running repetitive tasks — classifying a list of items, summarizing multiple documents, extracting structured data from records — consider batching them into a single prompt rather than making individual API calls.

# Instead of this (3 separate calls)
Classify the sentiment of: "I love this product!"
Classify the sentiment of: "This is terrible."
Classify the sentiment of: "It's okay I guess."

# Do this (1 call)
Classify the sentiment of each sentence below. Reply with a JSON array.
1. "I love this product!"
2. "This is terrible."
3. "It's okay I guess."

Batching reduces per-call overhead from system prompts and saves on round-trip latency too. Win-win.

🚩 Things to Be Careful About

Beyond token usage, there are a few broader habits worth watching:

Don't Over-rely on Claude for Simple Tasks

If you're using Claude to do string formatting, basic math, or simple lookups — you're probably over-engineering it. Use Claude where reasoning, language understanding, or generation actually matters.

Prompt Injection is a Real Risk

If you're building an app that feeds user-provided content directly into Claude's context, be aware of prompt injection attacks. Users can craft inputs designed to override your system prompt or manipulate Claude's behavior. Always sanitize and think carefully about what user content ends up in your prompts.

Don't Assume Consistency Without Testing

Claude is not a deterministic function. The same prompt can produce slightly different results, especially at higher temperature settings. If consistency matters in your app (structured data extraction, for example), test extensively and consider using structured output formats or validation layers.

Caching is Your Friend

If you're using the API and making repeated calls with identical or near-identical system prompts and context, look into prompt caching (available via Anthropic's API). It can dramatically reduce costs for repetitive workloads.

🎯 Final Thoughts

Using Claude effectively isn't just about getting good outputs — it's about being intentional with every token you send and receive. The developers who get the most out of Claude (at the lowest cost) are the ones who treat prompting like engineering: iterative, measured, and always looking for inefficiencies to cut.

Here's my honest take: most token waste is preventable. Bloated system prompts, unmanaged conversation history, and vague output instructions account for the majority of unnecessary spending I've seen. Fix those three things first, and you'll probably see a significant drop in usage before you need to do anything more sophisticated.

Start small, measure your token counts, and iterate. Claude is a genuinely powerful tool — treat it like one.

Power Apps Components Explained: Build Reusable UI Like a Pro

Lakshmi Bhargavi Gajula — Sat, 13 Jun 2026 18:10:00 +0000

Power Apps Components Explained: Build Reusable UI Like a Pro

Imagine building a form in Power Apps, perfecting the styling, adding validation logic, and then realizing you need the exact same form in five other screens. You copy it. Then a design change comes in, and you have to update all five copies manually. Sound familiar? That's the problem Power Apps Components solve — and once you understand them, you'll wonder how you ever built apps without them.

In this post, we'll break down what components are, how they work, and how to build one from scratch. Whether you're coming from traditional software development or exploring the low-code space for the first time, this guide has you covered.

What Are Components in Power Apps?

Components in Power Apps are reusable UI building blocks — think of them like custom controls or widgets. They're similar in concept to components in React or Angular: you define them once, and you can drop them into any screen (or even share them across apps).

Key characteristics of Power Apps Components:

Encapsulated logic and UI — the component manages its own behavior internally.
Custom properties — you can define inputs and outputs to communicate with the parent app.
Reusable across screens — place the same component on multiple screens without duplicating logic.
Component Libraries — share components across multiple apps in your organization.

Components vs. Screens vs. Controls

Before diving deeper, let's clarify the hierarchy:

Concept	Description
Screen	A full page/view in your app
Control	A built-in element (Button, TextInput, Gallery, etc.)
Component	A custom, reusable group of controls with its own properties

Components sit between controls and screens. They're composed of built-in controls but behave like a single, self-contained unit.

Creating Your First Component

Let's build a simple Header Bar Component that accepts a title and a background color as inputs.

Step 1: Enable Components (if needed)

In older environments, you may need to enable the Components feature:

Go to File > Settings > Advanced Settings.
Toggle on Components.

In most modern Power Apps Studio, this is enabled by default.

Step 2: Create a New Component

Open Power Apps Studio and open (or create) a Canvas App.
In the left panel, click the Tree View icon.
Click on Components tab at the top of the Tree View.
Click + New Component.

You'll see a blank canvas — this is your component's design surface.

Step 3: Add Custom Input Properties

Components communicate with the outside world through custom properties.

With your component selected, click New custom property in the right panel.
Create a property called HeaderTitle:
- Display name: HeaderTitle
- Property type: Input
- Data type: Text
- Default value: "My App"
Create another property called BackgroundColor:
- Display name: BackgroundColor
- Property type: Input
- Data type: Color
- Default value: RGBA(0, 120, 212, 1)

Step 4: Design the Component

Now add controls inside the component:

Insert a Rectangle control and set its properties:

Fill: HeaderBar.BackgroundColor
Width: Parent.Width
Height: 60
X: 0
Y: 0

Insert a Label control on top of the rectangle:

Text: HeaderBar.HeaderTitle
Color: White
FontWeight: Bold
X: 16
Y: 0
Height: 60

Note: Inside a component, you reference your custom input properties using the component's name followed by the property name (e.g., HeaderBar.HeaderTitle).

Using the Component in Your App

Now that the component is built, let's use it on a screen.

Go back to the Screens tab in Tree View.
Select a screen.
Click Insert > Custom — your component will appear in the list.
Insert it onto the screen.

You'll immediately see it render. Now customize it via the properties panel on the right:

HeaderTitle: "Dashboard"
BackgroundColor: RGBA(50, 50, 50, 1)

Every instance of the component can have different values — just like passing props in React.

Output Properties: Getting Data Back Out

Components aren't just for display. You can also define Output properties to send data back to the parent screen.

Example use case: A custom date picker component that exposes the selected date.

Create a custom property:
- Display name: SelectedDate
- Property type: Output
- Data type: DateTime
Inside the component, bind a DatePicker control's value to this output:

// In the component, set the Output property formula:
SelectedDate = DatePickerControl.SelectedDate

On your screen, you can now reference it like:

Text: MyDatePickerComponent.SelectedDate

This creates a clean, predictable data flow between your component and the screen.

Component Libraries: Sharing Across Apps

The real power unlocks when you use Component Libraries — a dedicated environment asset that lets multiple apps consume the same components.

How to Create a Component Library

Go to make.powerapps.com.
Click + Create > Component Library.
Build your components inside the library.
Publish the library.

How to Use a Component Library in an App

In Power Apps Studio, go to Insert > Get more components.
Browse to your Component Library.
Import the component — it now appears under Library Components in the Insert menu.

When you update the library and publish, apps using it will receive a notification to update — similar to a package version update in npm.

Best Practices for Power Apps Components

Here are some developer-friendly tips to keep your component architecture clean:

Name components clearly — use PascalCase like HeaderBar, NavMenu, SearchCard.
Keep components focused — one component, one responsibility.
Avoid deeply nested components — Power Apps has a nesting limit and performance can degrade.
Document custom properties — use the Description field when creating properties to help teammates.
Use Component Libraries for organization-wide standards — maintain a design system.
Test components in isolation before embedding them in complex screens.

Limitations to Be Aware Of

Power Apps components are powerful but have some gotchas:

No behavioral properties by default (though this can be enabled in some environments) — passing functions as properties is limited compared to code-based frameworks.
Component nesting has limits — you can't infinitely nest components.
Context variables and collections defined outside a component aren't automatically accessible inside it. You need to explicitly pass them via input properties.
Component Library updates are not automatic — app makers must opt-in to accept updates.

Conclusion

Power Apps Components bring a developer-friendly, modular mindset to the low-code world. By encapsulating UI and logic into reusable, property-driven units, you can:

Eliminate duplication across screens and apps.
Enforce consistency in UI design.
Speed up development by reusing proven building blocks.
Simplify maintenance — fix once, update everywhere.

If you're building anything beyond a simple one-screen app, components should be part of your Power Apps toolkit. Start small — extract something you've already duplicated into a component — and you'll immediately feel the difference.

Happy building! 🚀

A11y Testing: The Missing Piece in Your QA Workflow

Lakshmi Bhargavi Gajula — Sat, 13 Jun 2026 18:07:08 +0000

A11y Testing: The Missing Piece in Your QA Workflow

Let me ask you something: when was the last time you thought about accessibility testing in your project? If your answer is "never" or "I meant to get around to that," you're definitely not alone. Most of us are pretty good at writing unit tests, maybe some integration tests — but a11y (accessibility) tests? That's the one that tends to fall through the cracks.

Today I want to share what I learned about a11y testing — what it is, why it matters more than you probably think, and how you can actually start doing it without turning your whole workflow upside down.

What Even Is A11y Testing?

First things first — "a11y" is a numeronym for accessibility. The "11" represents the 11 letters between the "a" and the "y". Nerdy? Yes. Useful shorthand? Absolutely.

Accessibility testing is the practice of checking whether your web application (or any software, really) can be used by people with disabilities. That includes people who:

Use screen readers (like NVDA or VoiceOver)
Navigate with a keyboard instead of a mouse
Have low vision and rely on high contrast or zoomed interfaces
Have cognitive or motor disabilities

The goal is to make sure your app follows standards — primarily the WCAG (Web Content Accessibility Guidelines) — so that everyone can use what you've built.

Why Should Developers Care?

Here's the honest answer: because it's the right thing to do and it's increasingly the smart business move.

~1 in 4 adults in the US has some form of disability (CDC data)
Inaccessible apps can create legal liability — lawsuits around web accessibility have been rising steadily
Good accessibility practices often improve SEO and overall UX for everyone
It's way cheaper to build it right from the start than to retrofit it later

And beyond the numbers: imagine building something you're proud of that a chunk of your users simply can't use. That's a problem worth solving.

Types of A11y Tests

Not all accessibility testing looks the same. There are basically three flavors:

1. Automated Testing

Tools that scan your code or rendered DOM and flag common accessibility violations automatically. Think of it as a linter, but for accessibility.

Popular tools:

axe-core — the most widely used accessibility engine
jest-axe — integrates axe into Jest tests
@testing-library/jest-dom — helpful matchers for accessible queries
Lighthouse (built into Chrome DevTools)

Here's a quick example of using jest-axe:

import React from 'react';
import { render } from '@testing-library/react';
import { axe, toHaveNoViolations } from 'jest-axe';

expect.extend(toHaveNoViolations);

it('should have no accessibility violations', async () => {
  const { container } = render(<MyButton label="Click me" />);
  const results = await axe(container);
  expect(results).toHaveNoViolations();
});

That's it. Seriously. You add that test, run your suite, and you'll get a detailed report if anything fails accessibility checks.

2. Manual Testing

Automated tools are great, but they only catch around 30-40% of accessibility issues. The rest require a human.

Manual testing means things like:

Tabbing through your UI with just a keyboard
Running a screen reader (NVDA on Windows, VoiceOver on Mac) and actually listening to your page
Checking color contrast ratios manually
Testing with browser zoom set to 200%

It's a bit more effort, but it's genuinely eye-opening. You'll probably discover UI quirks you never noticed before.

3. User Testing

The gold standard. Actually getting feedback from users who have disabilities and rely on assistive technology day-to-day. This isn't always feasible for every team, but if you can do it — do it.

Getting Started: Low-Hanging Fruit

You don't have to overhaul everything overnight. Here are some quick wins you can implement today:

Use semantic HTML. This one is free and incredibly impactful.

<!-- Bad -->
<div onclick="handleClick()">Submit</div>

<!-- Good -->
<button type="submit">Submit</button>

Screen readers know what a <button> is. A <div> with a click handler? Not so much.

Add alt text to images.

<!-- Bad -->
<img src="profile.jpg" />

<!-- Good -->
<img src="profile.jpg" alt="Profile photo of Jane Doe" />

Make sure form inputs have labels.

<!-- Bad -->
<input type="email" placeholder="Enter email" />

<!-- Good -->
<label for="email">Email address</label>
<input id="email" type="email" />

Don't rely on color alone to communicate information. Add icons, text, or patterns as a backup.

Integrating A11y Tests Into Your CI Pipeline

Once you've written a few a11y tests, you'll want to make sure they run automatically so regressions don't sneak in. Most CI setups (GitHub Actions, GitLab CI, CircleCI) will just pick them up as part of your regular test run if you're using Jest.

You can also add Lighthouse CI for automated audits on every pull request:

# .github/workflows/lighthouse.yml
name: Lighthouse CI
on: [push]
jobs:
  lhci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run Lighthouse CI
        uses: treosh/lighthouse-ci-action@v10
        with:
          urls: |
            http://localhost:3000
          budgetPath: ./budget.json

This way, accessibility scores become part of your pull request feedback loop — just like test coverage.

Common A11y Mistakes Developers Make

Before I wrap up, here's a quick hit list of the most common slip-ups:

❌ Missing or generic alt text (e.g., alt="image")
❌ Low color contrast between text and background
❌ Interactive elements that aren't keyboard-focusable
❌ No aria-label on icon-only buttons
❌ Modals that trap focus or don't return focus on close
❌ Auto-playing media without controls
❌ Forms that only show errors in red (no text description)

Many of these are easy fixes once you know to look for them.

Wrapping Up

A11y testing doesn't have to be this massive, intimidating undertaking. Start small — drop jest-axe into one component test, run your page through Lighthouse, tab through your nav bar. You'll be surprised what you find, and you'll start building better habits from there.

The web is for everyone. As developers, we have more power than almost anyone to make that actually true. Accessibility testing is one of the most practical ways to act on that.

Key takeaways:

Automated tools like axe-core and jest-axe make a11y testing approachable
Automated tests only catch ~30-40% of issues — manual testing fills the gap
Semantic HTML is your best friend and costs you nothing
Bake a11y checks into your CI pipeline so you catch regressions early

Now go make something everyone can use. 🙌

Stop Memory Leaks in Their Tracks: React useEffect Cleanup Explained

Lakshmi Bhargavi Gajula — Sat, 13 Jun 2026 17:59:17 +0000

Stop Memory Leaks in Their Tracks: React useEffect Cleanup Explained

If you've spent any time with React, you've probably seen this warning pop up in your console:

"Warning: Can't perform a React state update on an unmounted component."

Yeah, that one. It's a classic memory leak caused by async operations inside useEffect — and it's way more common than you'd think. Let's break down what's actually happening and how to fix it cleanly.

What's the Problem?

When you kick off an async operation (like a fetch call) inside useEffect, there's a race condition waiting to happen. If the component unmounts before the async call finishes, React will still try to update state on something that no longer exists in the DOM.

Here's a simple example of the problematic pattern:

useEffect(() => {
  fetch('/api/data')
    .then(res => res.json())
    .then(data => {
      setData(data); // 💥 component might already be gone!
    });
}, []);

No cleanup = potential memory leak.

The Fix: Return a Cleanup Function

useEffect lets you return a cleanup function that runs when the component unmounts (or before the effect re-runs). The trick with async calls is to use an abort flag or the built-in AbortController.

Option 1: Boolean Flag

Simple and straightforward:

useEffect(() => {
  let isMounted = true;

  fetch('/api/data')
    .then(res => res.json())
    .then(data => {
      if (isMounted) {
        setData(data); // ✅ only update if still mounted
      }
    });

  return () => {
    isMounted = false; // cleanup!
  };
}, []);

Option 2: AbortController (the Modern Way)

This one actually cancels the fetch request, which is even better:

useEffect(() => {
  const controller = new AbortController();

  fetch('/api/data', { signal: controller.signal })
    .then(res => res.json())
    .then(data => setData(data))
    .catch(err => {
      if (err.name === 'AbortError') return; // ignore abort errors
      console.error(err);
    });

  return () => {
    controller.abort(); // cancel the request on cleanup
  };
}, []);

This is the preferred approach because it actually stops the network request rather than just ignoring the result.

Quick Rules to Live By

Always return a cleanup function from useEffect when dealing with async operations, subscriptions, or timers.
Use AbortController for fetch calls when possible.
Use a boolean flag as a fallback for non-cancellable async operations.
Watch your dependency array — missing deps can cause stale closures and unexpected behavior.

Why Does This Actually Matter?

Beyond silencing console warnings, proper cleanup:

Prevents unnecessary re-renders that tank performance
Avoids setting state on unmounted components, which can cause subtle bugs
Cancels in-flight network requests, saving bandwidth

It's one of those things that seems minor until it causes a weird bug in production at 2am.

Wrapping Up

The useEffect cleanup function is your best friend when working with async code in React. Whether you go with the AbortController approach or a simple boolean flag, the key takeaway is this: always think about what happens when your component disappears before your async work is done.

Get into the habit of writing your cleanup from the start, and you'll save yourself a lot of headaches down the road. Your future self will thank you. 🙌