DEV Community: victor mwangi

Stop Using useEffect for Data Fetching: Understanding TanStack Query

victor mwangi — Wed, 27 May 2026 16:28:02 +0000

If you are still fetching data inside a useEffect hook, manually managing loading states, and storing server responses inside local component state, your frontend architecture is carrying unnecessary complexity.

Managing asynchronous API data — also called Server State — is one of the hardest problems in frontend development. Trying to handle it with traditional client-side state tools like Redux, Zustand, or plain React state often leads to repetitive, fragile, and difficult-to-maintain codebases.

That is where TanStack Query changes everything.

It is not just a data-fetching library. It acts as:

An intelligent cache
A server-state manager
A synchronization layer between your frontend and backend
A background updater for stale data
Let’s break down how it actually works.

Client State vs Server State

Before understanding TanStack Query, you need to separate two completely different categories of state.

1. Client State

This is synchronous state that exists entirely inside the browser.

Examples:

Modal visibility
Theme toggles
Sidebar state
Form inputs

This data is fully controlled by the frontend.

2. Server State

This is asynchronous state that lives remotely on a backend server or database.

Examples:

Product lists
User profiles
Notifications
Dashboard analytics
Orders from an API

Server state has unique challenges:

You do not own the data
Multiple users can modify it
It can become outdated instantly
It requires async network requests
It needs synchronization

Using useState + useEffect forces server state to behave like client state.

That creates problems like:

Duplicate requests
Boilerplate loading logic
Manual error handling
Race conditions
No caching
Difficult synchronization

TanStack Query solves these automatically.

Declarative Data Fetching with useQuery

TanStack Query replaces imperative fetching with a declarative approach.

The core building blocks are:

Query Key
Query Function

Example:

_**

import { useQuery } from '@tanstack/react-query';

function ProductList() {
  const { data, isLoading, isError, error } = useQuery({
    queryKey: ['products'],
    queryFn: async () => {
      const res = await fetch('https://api.yourdomain.com/products');

      if (!res.ok) {
        throw new Error('Failed to fetch products');
      }

      return res.json();
    },
  });

  if (isLoading) {
    return <div>Loading products...</div>;
  }

  if (isError) {
    return <div>Error: {error.message}</div>;
  }

  return (
    <ul>
      {data.map((product) => (
        <li key={product.id}>{product.name}</li>
      ))}
    </ul>
  );
}_

**
Why This Is Powerful

Instead of manually controlling the fetch lifecycle, you simply describe:

“This component depends on the products query.”

TanStack Query handles everything else automatically.

Network Request Deduplication

Imagine three different components all requesting the same product list:

Sidebar
Dashboard
Analytics widget

Without TanStack Query:

3 components
3 fetch calls
3 HTTP requests

With TanStack Query:

queryKey: ['products']

TanStack Query recognizes the identical query key and:

Sends only ONE network request
Shares the response across all components
Prevents network waterfalls

This significantly improves performance.

Understanding the Cache Architecture

TanStack Query uses a strategy called:

Stale-While-Revalidate

The workflow looks like this:

Serve cached data immediately
Fetch fresh data in the background
Update the UI automatically if data changed

This creates extremely fast-feeling applications because users instantly see cached content instead of loading spinners.

Client State vs Server State

Before understanding TanStack Query, you need to separate two completely different categories of state.

Client State

This is synchronous state that exists entirely inside the browser.

Examples:

Modal visibility
Theme toggles
Sidebar state
Form inputs

This data is fully controlled by the frontend.

Server State

This is asynchronous state that lives remotely on a backend server or database.

Examples:

Product lists
User profiles
Notifications
Dashboard analytics
Orders from an API

Server state has unique challenges:

You do not own the data
Multiple users can modify it
It can become outdated instantly
It requires async network requests
It needs synchronization

Using useState + useEffect forces server state to behave like client state.

That creates problems like:

Duplicate requests
Boilerplate loading logic
Manual error handling
Race conditions
No caching
Difficult synchronization

TanStack Query solves these automatically.

Declarative Data Fetching with useQuery

TanStack Query replaces imperative fetching with a declarative approach.

The core building blocks are:

Query Key
Query Function

Example:

import { useQuery } from '@tanstack/react-query';

function ProductList() {
  const { data, isLoading, isError, error } = useQuery({
    queryKey: ['products'],
    queryFn: async () => {
      const res = await fetch('https://api.yourdomain.com/products');

      if (!res.ok) {
        throw new Error('Failed to fetch products');
      }

      return res.json();
    },
  });

  if (isLoading) {
    return <div>Loading products...</div>;
  }

  if (isError) {
    return <div>Error: {error.message}</div>;
  }

  return (
    <ul>
      {data.map((product) => (
        <li key={product.id}>{product.name}</li>
      ))}
    </ul>
  );
}

_
Why This Is Powerful

Instead of manually controlling the fetch lifecycle, you simply describe:

“This component depends on the products query.”

TanStack Query handles everything else automatically.

Network Request Deduplication

Imagine three different components all requesting the same product list:

Sidebar
Dashboard
Analytics widget

Without TanStack Query:

3 components
3 fetch calls
3 HTTP requests

With TanStack Query:

queryKey: ['products']

TanStack Query recognizes the identical query key and:

Sends only ONE network request
Shares the response across all components
Prevents network waterfalls

This significantly improves performance.

Understanding the Cache Architecture

TanStack Query uses a strategy called:

Stale-While-Revalidate

The workflow looks like this:

Serve cached data immediately
Fetch fresh data in the background
Update the UI automatically if data changed

This creates extremely fast-feeling applications because users instantly see cached content instead of loading spinners.
Understanding staleTime

Default:

staleTime: 0

Meaning:

Data becomes stale immediately after fetching.

Example optimization:

staleTime: 1000 * 60 * 5

This means:

Data is considered fresh for 5 minutes
No refetch happens during that period
Components reuse cached memory

Best for:

Country lists
User settings
Static configurations
Understanding gcTime (Garbage Collection)

Previously called cacheTime.

Default:

gcTime: 1000 * 60 * 5

Meaning:

When no component uses a query anymore:

The query becomes inactive
A garbage collection timer starts
Cache is deleted after 5 minutes

This prevents memory leaks.

Automatic Background Refetching

TanStack Query automatically keeps your application synchronized.

It refetches data when:

1. Components Mount Again

When a component using the query reappears.

2. Window Focus Changes

If the user switches tabs and comes back, the data revalidates automatically.

3. Network Reconnects

If the internet disconnects and reconnects, TanStack Query immediately synchronizes stale data.

4. Polling Intervals

Example:

refetchInterval: 10000

This refetches data every 10 seconds.

Useful for:

Real-time dashboards
Notifications
Live analytics
Mutating Data with useMutation

Fetching data is only half the story.

What happens after:

POST requests
PUT updates
DELETE operations

The browser cache immediately becomes outdated.

Example:

import {
  useMutation,
  useQueryClient,
} from '@tanstack/react-query';

const queryClient = useQueryClient();

const addProductMutation = useMutation({
  mutationFn: async (newProduct) => {
    const res = await fetch(
      'https://api.yourdomain.com/products',
      {
        method: 'POST',
        body: JSON.stringify(newProduct),
      }
    );

    return res.json();
  },

  onSuccess: () => {
    queryClient.invalidateQueries({
      queryKey: ['products'],
    });
  },
});
Cache Invalidation

Instead of manually updating arrays in state:

setProducts(...)

You invalidate the query:

queryClient.invalidateQueries({
  queryKey: ['products'],
});

TanStack Query then:

Marks the cache as stale
Automatically refetches fresh data
Synchronizes the UI with the database

This removes fragile state management logic entirely.

Using TanStack Query DevTools

Debugging async cache systems with console.log becomes painful quickly.

Install the DevTools:

npm install @tanstack/react-query-devtools

Setup:

import {
  QueryClient,
  QueryClientProvider,
} from '@tanstack/react-query';

import {
  ReactQueryDevtools,
} from '@tanstack/react-query-devtools';

const queryClient = new QueryClient();

export default function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <MainApplication />

      <ReactQueryDevtools
        initialIsOpen={false}
      />
    </QueryClientProvider>
  );
}_

Query Lifecycle States

Inside the DevTools panel, queries appear in different lifecycle states:

State Meaning
Fresh Data is still trusted
Stale Data exists but needs revalidation
Fetching Active network request
Inactive No component currently uses the query

This gives you full visibility into your async cache architecture.

Mastering Dependency Injection in .NET: A Software Engineer's Secret Weapon

victor mwangi — Wed, 27 May 2026 15:39:10 +0000

Imagine you are building a modern car. Instead of welding the engine directly to the chassis, you bolt it in. Why? Because if the engine breaks—or if you want to upgrade from a gas engine to an electric one—you don’t want to tear the whole car apart. You just unbolt the old one and slot the new one in.

In software engineering, Dependency Injection (DI) is that bolt.

If you are building applications in .NET, DI isn’t just a "nice-to-have" design pattern; it’s a core part of the framework. Let’s break down what DI is, why you need it, and how to master it in .NET.

What on Earth is Dependency Injection?

**
Before we talk about injection, let’s talk about dependencies. If Class A uses Class B to get its job done, Class A depends on Class B. Class B is a dependency.

Without DI, Class A creates Class B itself. Look at this tightly coupled mess:

_C#
public class Car
{
private Engine _engine;

public Car()
{
    // The car is trapped! It can only ever use this specific V8Engine.
    this._engine = new V8Engine(); 
}

}_
With Dependency Injection, we invert that control (hence Inversion of Control, or IoC). Instead of the Car creating the Engine, we "inject" the engine through the constructor:

_C#
public class Car
{
private readonly IEngine _engine;

// The car doesn't care what kind of engine it gets, as long as it implements IEngine
public Car(IEngine engine)
{
    _engine = engine;
}

}_
**

Why Should You Care? (The Benefits)

**Maintainability: If you need to change how Engine works, you don't risk breaking Car.

Testability: This is the big one. When writing unit tests for Car, you don't want to spin up a real database or hit a real API. With DI, you can inject a MockEngine and test the Car in isolation.

Flexibility: Want to swap your SQL database for MongoDB? Just change the registration in one central place, and the rest of your app keeps running seamlessly.

Service Lifetimes in .NET: The Big Three
The built-in .NET IoC container manages the creation and disposal of your dependencies. When you register a service, you have to tell .NET how long that service should live.

Choosing the wrong lifetime is the #1 cause of bugs in .NET DI. Here is the breakdown:

1. Transient (AddTransient)
How it works: A brand-new instance is created every single time it is requested.

Best used for: Lightweight, stateless services (like a quick formatting helper or a validation service).

2. Scoped (AddScoped)
How it works: An instance is created once per HTTP request (in web apps). All components handling that specific web request will share that same instance.

Best used for: Services that hold state for a single request, like your Entity Framework Core DbContext.

3. Singleton (AddSingleton)
How it works: An instance is created the first time it’s requested and lives forever until the application shuts down. Every subsequent request uses that exact same instance.

Best used for: Caching services, configuration settings, or anything that is expensive to create and needs to be shared globally.

⚠️ Danger Zone Warning: Never inject a Scoped service into a Singleton service. Because the Singleton lives forever, the Scoped service will get trapped inside it forever, effectively turning it into a Singleton. This is called a Captive Dependency, and it causes massive database connection bugs!

Wire It Up: A Real-World .NET Example
Let's look at how to actually implement this in a modern .NET Web API or Minimal API (Program.cs).

Step 1: Define the Contract and Implementation
_C#
public interface IEmailService
{
void SendEmail(string to, string subject);
}

public class SendGridEmailService : IEmailService
{
public void SendEmail(string to, string subject)
{
Console.WriteLine($"Email sent to {to} via SendGrid!");
}
}_
Step 2: Register it in Program.cs
Open your Program.cs file. This is where the magic happens. We register our IEmailService with the service collection.

_C#
var builder = WebApplication.CreateBuilder(args);

// Register your dependency here!
builder.Services.AddScoped();

var app = builder.Build();_
Step 3: Inject and Use It
Now, .NET will automatically look at the constructor of your Controllers or Minimal API endpoints, see that it requires an IEmailService, and pass it in.

_C#
app.MapPost("/register", (string email, IEmailService emailService) =>
{
// .NET automatically provided 'emailService' for us!
emailService.SendEmail(email, "Welcome to our App!");
return Results.Ok("User registered successfully");
});

app.Run();_
Wrapping Up
Dependency Injection isn't just an academic concept; it's the glue that keeps professional .NET applications clean, testable, and scalable. By shifting the responsibility of object creation from your classes to the .NET framework, you write code that is ready for change.

Next time you write a class, don't reach for the new keyword right away. Ask yourself: "Should this be injected instead?"

What are your thoughts on .NET's built-in DI container? Have you ever run into a captive dependency nightmare? Let's chat in the comments below!

Happy coding! 🚀