DEV Community: Prince Patel

React State vs Server State: Why You Shouldn't Store Everything in useState

Prince Patel — Wed, 23 Sep 2026 13:24:10 +0000

I used to think fetching API data in React was pretty straightforward.

Fetch the data → put it in useState → render it.
And for a small application, it works perfectly fine.

const [users, setUsers] = useState([]);

useEffect(() => {
fetch("/api/users")
.then(res => res.json())
.then(data => setUsers(data));
}, []);

The problem starts when the application grows.

Suddenly, you need to handle:

Loading states
Errors
Refetching
Caching
Stale data
Retries
Multiple components using the same data
Keeping server data in sync

At that point, the question isn't really, "Can I use useState?"
Of course I can.

The better question is:

Who owns this state?
Client State vs Server State :

Client state is state owned by the UI.

Things like:

Is a modal open?
Which tab is selected?
What's currently typed in an input?
Which item is selected?

For example:

const [isModalOpen, setIsModalOpen] = useState(false);
const [selectedTab, setSelectedTab] = useState("profile");

useState is a great fit here because the component is responsible for that state.

Server state is different.

Think about:

Users
Products
Orders
Notifications
Comments
Dashboard data

This data comes from an external source.

Your React application is essentially consuming a snapshot of data that the server owns.
That means the data can change outside your component.
It can become stale, need to be refetched, or be shared across multiple components. You may also want caching and background updates.
That's where something like TanStack Query becomes useful.

Instead of manually managing:

const [users, setUsers] = useState([]);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);

you can let a server-state library handle much of that lifecycle:

const {
data: users = [],
isLoading,
error
} = useQuery({
queryKey: ["users"],
queryFn: getUsers
});

Now the responsibility isn't just "store this API response in state."
You're working with data that has a lifecycle:

fetch → cache → become stale → refetch → update

That's the part that useState doesn't try to solve.

So, should we stop using useState?
Definitely not.

I still use useState for UI state all the time.
The lesson is simply that not all state is the same.

A useful mental model is:

UI owns it → useState
Server owns it → consider a server-state solution

Once I started thinking about state this way, React state management became much easier to reason about.
It's not about replacing useState.
It's about using the right abstraction for the problem you're actually solving.

Have you had a similar experience where a simple useState + useEffect solution eventually became difficult to maintain?

The Infinite Re-render That Froze My App

Prince Patel — Sat, 01 Aug 2026 06:52:03 +0000

React’s “Maximum Update Depth Exceeded”: The `useEffect` Bug That Caused Hundreds of API Calls

One useEffect dependency caused my React application to make the same API request hundreds of times.

The browser became sluggish, CPU usage went up, and eventually React crashed with:

Maximum update depth exceeded.

At first, I thought the problem was somewhere in my API or state management.

It wasn't.

The problem was hiding inside a small useEffect.

What Happened?

Everything looked normal at first.

The application compiled successfully.
There were no syntax errors.
The UI loaded correctly.

Then I clicked a button.

A few seconds later, the application started slowing down.

I opened Chrome DevTools and checked the Network tab.

That's when I noticed something strange:

The same API request was being sent repeatedly.

Not twice.

Not ten times.

Hundreds of times.

Every response seemed to trigger another render, which triggered another request.

So I started tracing the component to find out what was causing the loop.

The Culprit: `useEffect`

I eventually found code similar to this:

const [users, setUsers] = useState([]);

useEffect(() => {
  fetchUsers().then((data) => {
    setUsers(data);
  });
}, [users]);

At first glance, the effect looks reasonable.

But look carefully at the dependency:

[users]

The effect depends on users.

But inside the effect, we're also updating users:

setUsers(data);

That creates a cycle.

Why Does It Loop?

Here's what happens:

Component renders
       ↓
useEffect runs
       ↓
API request starts
       ↓
Data comes back
       ↓
setUsers(data)
       ↓
users changes
       ↓
Component renders again
       ↓
useEffect runs again
       ↓
Another API request
       ↓
... repeat ...

Eventually, React throws:

Maximum update depth exceeded

The important thing to remember is:

If an effect updates a state value that the same effect depends on, you may have created a render loop.

The Fix

In this case, the effect only needed to fetch the users when the component mounted.

So the dependency array should not listen to users:

const [users, setUsers] = useState([]);

useEffect(() => {
  fetchUsers().then((data) => {
    setUsers(data);
  });
}, []);

Now the flow becomes:

Component renders
       ↓
useEffect runs once
       ↓
API request
       ↓
setUsers(data)
       ↓
Component renders
       ↓
useEffect does NOT run again

Result:

One request instead of hundreds.

The Dependency Array Mental Model

Whenever I write a new useEffect, I now think about it like this:

Dependency changes
       ↓
Effect runs
       ↓
Does the effect update that dependency?
       ↓
       YES
       ↓
Could the effect trigger itself again?
       ↓
       ⚠️

That simple check can prevent a lot of debugging pain.

The dependency array isn't just a list of values you happen to use.

It determines when React should run the effect again.

Common `useEffect` Mistake

A common pattern is:

useEffect(() => {
  setSomething(value);
}, [something]);

Whenever you see an effect structured like this, stop and ask:

"What happens after this state changes?"

If changing the state causes the effect to run again, you need to make sure the cycle has a valid stopping condition.

Before vs After

Before

Browser became unresponsive
Hundreds of API requests
High CPU usage
Repeated renders
Maximum update depth exceeded
Poor user experience

After

One API request
Stable rendering
Smooth navigation
Lower unnecessary CPU usage
Cleaner component logic

What I Learned

This bug reinforced a few React fundamentals for me:

1. Every state update can trigger another render.

Calling:

setUsers(data);

doesn't just change a variable. It causes React to render the component again.

2. Dependencies control when an effect runs.

A dependency changing can cause the effect to execute again.

3. Be careful when an effect changes one of its own dependencies.

That combination can easily create an infinite loop.

4. Don't add dependencies blindly.

The goal isn't to make the dependency array longer.

The goal is to correctly describe when the effect needs to run.

Could Monitoring Have Helped?

Performance and error-monitoring tools can make problems like this easier to investigate.

For example, monitoring can help identify:

Repeated errors
Excessive network activity
Performance degradation
Session behaviour before the crash

That can significantly reduce the time needed to find the root cause.

Final Thought

This wasn't caused by a complicated algorithm or an obscure library.

It came from a tiny dependency mistake:

[users]

That's what makes React bugs like this interesting.

A small change can create a surprisingly large performance problem.

Now, whenever I write a new useEffect, I ask myself one question:

"Could this effect accidentally trigger itself?"

That question has already saved me from repeating this mistake.

Have you ever encountered an infinite useEffect loop? What caused yours?

Fixing a Memory Leak in React by Cleaning Up useEffect

Prince Patel — Sat, 01 Aug 2026 06:20:17 +0000

Project Overview

The project is a React-based web application that fetches data from a REST API and displays it in a dynamic dashboard. Users can navigate between pages, search data, and interact with multiple components that rely on asynchronous API calls.

While testing the application, I noticed that navigating away from a page during an active API request occasionally caused React warnings and unnecessary memory usage. This issue affected the application's stability and could lead to performance degradation over time.

The problem was caused by an asynchronous operation continuing even after the component had been unmounted.

For example, an API request initiated inside useEffect would still complete after the user navigated away, attempting to update the component's state. React would warn that a state update was attempted on an unmounted component.

Before
useEffect(() => {
fetch("/api/users")
.then((res) => res.json())
.then((data) => setUsers(data));
}, []);

If the component unmounted before the request finished, the callback still attempted to update the state.

After

I solved the issue by using the AbortController API to cancel the request during cleanup.

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

fetch("/api/users", {
signal: controller.signal,
})
.then((res) => res.json())
.then((data) => setUsers(data))
.catch((err) => {
if (err.name !== "AbortError") {
console.error(err);
}
});

return () => controller.abort();
}, []);

This ensures that pending requests are cancelled when the component unmounts, preventing unnecessary state updates and avoiding memory leaks.

Code

Prince3963 (Patel Prince) / Repositories · GitHub

Prince3963 has 48 repositories available. Follow their code on GitHub.

github.com

My Improvements

This fix focused on improving both performance and application reliability.

What I improved
Prevented memory leaks caused by unfinished asynchronous requests.
Added proper cleanup logic inside useEffect.
Eliminated React warnings about updating unmounted components.
Reduced unnecessary memory consumption.
Improved the user experience during rapid page navigation.
Followed React best practices for handling asynchronous operations.
Technical Approach

Instead of allowing every request to complete regardless of component lifecycle, I introduced request cancellation using AbortController. This is a lightweight and native browser solution that integrates well with the Fetch API.

I also added proper error handling to ignore expected AbortError exceptions while still logging genuine network failures.

The resulting code is cleaner, safer, and easier to maintain.

Best Use of Sentry

Although this particular fix was implemented without extensive observability tooling, it would integrate well with Sentry's Error Monitoring and Performance Monitoring.

Sentry could help by:

Detecting repeated React warnings.
Tracking failed API requests.
Monitoring slow network operations.
Identifying components generating frequent runtime errors.
Providing stack traces to simplify debugging.

These insights would make it easier to identify similar issues in production before they impact users.

Best Use of Google AI

Google AI can significantly speed up debugging and code improvement by:

Explaining React lifecycle behavior.
Suggesting safer asynchronous patterns.
Recommending performance optimizations.
Reviewing cleanup logic for hooks.
Helping developers understand why memory leaks occur and how to prevent them.

Using AI as a development assistant can reduce debugging time while promoting best practices.

Final Thoughts

Memory leaks are often difficult to notice because an application may appear to work correctly until users begin navigating frequently or using it for extended periods.

A small cleanup function inside useEffect can prevent unnecessary memory usage, eliminate React warnings, and improve overall application stability.

This contribution reinforced an important React principle: every side effect should also have a cleanup strategy.

Thanks for reading, and happy debugging!

PassionForge AI

Prince Patel — Sat, 11 Jul 2026 06:54:53 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Want to Build

PassionForge AI is an AI-powered platform that I want to build to help people transform their passions into real projects, careers, or businesses.

Many people know what they love—whether it's coding, photography, music, sports, writing, fitness, or art—but they often don't know where to begin. PassionForge AI will act as a personal AI mentor, creating a customized roadmap based on each user's interests, experience level, available time, and long-term goals.

Instead of providing generic advice, the platform will generate a personalized action plan that helps users:

Discover the best learning path
Find the right AI tools for their journey
Build real-world projects
Stay motivated with milestones and progress tracking
Explore ways to share or monetize their passion

The goal isn't simply to recommend AI tools. I want PassionForge AI to help people take meaningful action toward something they genuinely care about.

Code

Frontend

React
TypeScript
Tailwind CSS

Backend

ASP.NET Core Web API (.NET)
Entity Framework Core
PostgreSQL

Authentication

JWT Authentication

AI

Google Gemini API
Claude
ChatGPT (Codex)

How I Want to Build It

I want to create something that fits the challenge theme in a practical and meaningful way.

Rather than building another AI chatbot, I want PassionForge AI to become a personalized mentor that guides users throughout their journey.

The application will begin by understanding the user's passion and collecting information such as:

Current skill level
Weekly time commitment
Long-term goal
Preferred learning style

Using Google Gemini, the platform will generate a personalized roadmap that includes learning recommendations, project ideas, suitable AI tools, and milestone-based guidance.

The backend will be developed using ASP.NET Core Web API with a clean layered architecture. PostgreSQL will be used to store user profiles, passions, personalized roadmaps, and progress data, while JWT Authentication will secure user sessions. The frontend will be built using React and Tailwind CSS to provide a modern, responsive, and intuitive user experience.

One of the most exciting challenges will be designing AI prompts that generate actionable guidance instead of generic motivational responses. My goal is to ensure the AI produces structured, practical, and realistic plans that users can confidently follow.

Prize Categories

Best Use of Google AI

Google Gemini will be the core intelligence behind PassionForge AI.

I also plan to leverage Claude and ChatGPT (Codex) during development to improve prompts, development workflow, and overall implementation.

Google Gemini will be responsible for:

Generating personalized passion roadmaps
Recommending relevant AI tools
Suggesting learning resources
Creating milestone-based action plans
Recommending project ideas based on user interests
Providing guidance tailored to each user's goals and experience

The AI won't simply be an additional feature—it will power the entire personalized experience.

Deployment

I want to deploy the application so it can be accessed from different devices and tested in real-world scenarios.

My deployment plan includes:

Deploying the frontend and backend to the cloud
Testing the application across multiple devices and browsers
Purchasing a custom domain for a professional experience
Ensuring a smooth and responsive user experience after deployment

Why I Want to Build This

Passion is where many great ideas begin, but countless people never take the first step because they don't know what to do next.

Through PassionForge AI, I want to bridge the gap between inspiration and execution.

Whether someone dreams of becoming a developer, photographer, creator, athlete, entrepreneur, or artist, I want this platform to provide a practical roadmap that helps them move forward—one meaningful step at a time.

My goal is to build a platform that inspires people to invest in what they truly love and gives them the confidence and guidance to turn their passion into something meaningful.

Repository Pattern Explained Without Confusion

Prince Patel — Sun, 28 Jun 2026 17:25:36 +0000

Have you ever written database queries directly inside your controllers and later wondered why your code became difficult to maintain?

I made the same mistake when I first started learning ASP.NET Core. At first, everything worked fine. But as my project grew, controllers became bloated, database logic was scattered everywhere, and making changes became frustrating.

That's when I discovered the Repository Pattern—a simple design pattern that separates data access from business logic, making applications cleaner, easier to maintain, and much easier to test.

In this article, I'll explain the Repository Pattern in the simplest way possible—with real examples, diagrams, and practical ASP.NET Core code.

What You'll Learn

By the end of this article, you'll understand:

What the Repository Pattern is
Why developers use it
Problems it solves
How it fits into an ASP.NET Core application
How to implement it step by step
Advantages and disadvantages
Common mistakes to avoid
Best practices

Let's get started.

The Problem

When beginners start building APIs, it's common to write code like this:

public class ProductController : ControllerBase
{
    private readonly AppDbContext _context;

    public ProductController(AppDbContext context)
    {
        _context = context;
    }

    [HttpGet]
    public IActionResult GetProducts()
    {
        return Ok(_context.Products.ToList());
    }
}

At first glance, this looks perfectly fine.

So what's wrong?

The controller is directly communicating with the database.

This creates several problems:

The controller now has two responsibilities.
Business logic and data access become mixed together.
Unit testing becomes difficult.
Any database-related changes require modifications inside the controller.
As your application grows, controllers become large and difficult to maintain.

In small projects this might not matter.

In large projects, it becomes a nightmare.

What is the Repository Pattern?

The Repository Pattern acts as a middle layer between your application and the database.

Instead of allowing controllers to communicate directly with Entity Framework, controllers interact with a Repository, and the repository handles all database operations.

This creates a clear separation of responsibilities.

A Simple Analogy

Imagine you're eating at a restaurant.

Customer → Controller
Waiter → Repository
Kitchen → Database

The customer never walks into the kitchen to cook food.

Instead, they tell the waiter what they want.

The waiter communicates with the kitchen and returns with the food.

The Repository works exactly the same way.

The controller simply asks the repository for data, and the repository communicates with the database.

Architecture

Client
   │
   ▼
Controller
   │
   ▼
Service
   │
   ▼
Repository
   │
   ▼
DbContext
   │
   ▼
Database

Each layer has a single responsibility:

Layer	Responsibility
Controller	Handle HTTP requests and responses
Service	Business logic
Repository	Database operations
DbContext	Communicate with Entity Framework
Database	Store application data

This separation makes the application much easier to maintain.

Step 1: Create the Repository Interface

The interface defines the operations our repository should support.

public interface IProductRepository
{
    Task<List<Product>> GetAllAsync();
    Task<Product?> GetByIdAsync(int id);
    Task AddAsync(Product product);
    Task UpdateAsync(Product product);
    Task DeleteAsync(int id);
}

Using an interface allows us to change the implementation later without affecting the controller.

Step 2: Implement the Repository

Now let's implement the interface.

public class ProductRepository : IProductRepository
{
    private readonly AppDbContext _context;

    public ProductRepository(AppDbContext context)
    {
        _context = context;
    }

    public async Task<List<Product>> GetAllAsync()
    {
        return await _context.Products.ToListAsync();
    }

    public async Task<Product?> GetByIdAsync(int id)
    {
        return await _context.Products.FindAsync(id);
    }

    public async Task AddAsync(Product product)
    {
        await _context.Products.AddAsync(product);
        await _context.SaveChangesAsync();
    }

    // UpdateAsync() and DeleteAsync() would follow the same pattern.
}

Notice that all database-related code now lives inside the repository instead of the controller.

Step 3: Register Dependency Injection

builder.Services.AddScoped<IProductRepository, ProductRepository>();

Now ASP.NET Core knows which implementation to provide whenever IProductRepository is requested.

Step 4: Use the Repository in the Controller

Now our controller becomes much cleaner.

public class ProductController : ControllerBase
{
    private readonly IProductRepository _repository;

    public ProductController(IProductRepository repository)
    {
        _repository = repository;
    }

    [HttpGet]
    public async Task<IActionResult> GetProducts()
    {
        return Ok(await _repository.GetAllAsync());
    }
}

The controller no longer needs to know anything about DbContext or Entity Framework.

Its only responsibility is handling HTTP requests.

Benefits

Using the Repository Pattern provides several advantages.

Cleaner code structure
Better separation of concerns
Easier unit testing
Reusable data access logic
Easier maintenance
Better scalability
Reduced code duplication

Common Mistakes

Avoid these common mistakes:

Putting business logic inside repositories
Returning IQueryable everywhere
Injecting both DbContext and the repository into the same controller
Creating one giant repository for every entity

Remember:

Repository = Data Access
Service = Business Logic
Controller = HTTP Requests

Best Practices

Keep repositories focused only on database operations.
Keep business logic inside the Service layer.
Use asynchronous methods whenever possible.
Program against interfaces instead of concrete classes.
Use Dependency Injection.
Keep repositories small and focused.

When Should You Use the Repository Pattern?

Use it when:

You're building medium or large applications.
Multiple developers are working on the project.
You want clean architecture.
You need unit testing.
You expect the project to grow.

For very small CRUD applications or quick prototypes, directly using DbContext may be sufficient.

Choose the level of abstraction that fits your project's complexity.

Conclusion

The Repository Pattern isn't about writing more code—it's about writing better-organized code.

By separating database operations from controllers, your application becomes cleaner, easier to test, and much easier to maintain as it grows.

If you're serious about becoming an ASP.NET Core developer, understanding the Repository Pattern is an important step toward writing production-ready applications.

What do you think?

Do you use the Repository Pattern in your ASP.NET Core projects?
Or do you prefer working directly with DbContext?
Let me know in the comments—I’d love to hear your thoughts.
If you found this article helpful, consider leaving a love and following me for more beginner-friendly ASP.NET Core tutorials.

Next in this series: Dependency Injection Explained Without Confusion

dotnet #aspnetcore #csharp #webdev

DEV Community: Prince Patel

React State vs Server State: Why You Shouldn't Store Everything in useState

The Infinite Re-render That Froze My App

React’s “Maximum Update Depth Exceeded”: The useEffect Bug That Caused Hundreds of API Calls

What Happened?

The Culprit: useEffect

Why Does It Loop?

The Fix

The Dependency Array Mental Model

Common useEffect Mistake

Before vs After

Before

After

What I Learned

Could Monitoring Have Helped?

Final Thought

Fixing a Memory Leak in React by Cleaning Up useEffect

Project Overview

Code

Prince3963 (Patel Prince) / Repositories · GitHub

My Improvements

Best Use of Sentry

Best Use of Google AI

Final Thoughts

PassionForge AI

This is a submission for Weekend Challenge: Passion Edition

What I Want to Build

Code

Frontend

Backend

Authentication

AI

How I Want to Build It

Prize Categories

Best Use of Google AI

Deployment

Why I Want to Build This

Repository Pattern Explained Without Confusion

What You'll Learn

The Problem

What is the Repository Pattern?

A Simple Analogy

Architecture

Step 1: Create the Repository Interface

Step 2: Implement the Repository

Step 3: Register Dependency Injection

Step 4: Use the Repository in the Controller

Benefits

Common Mistakes

Best Practices

When Should You Use the Repository Pattern?

Conclusion

What do you think?

dotnet #aspnetcore #csharp #webdev

React’s “Maximum Update Depth Exceeded”: The `useEffect` Bug That Caused Hundreds of API Calls

The Culprit: `useEffect`

Common `useEffect` Mistake