DEV Community: Prince Patel

The Infinite Re-render That Froze My App

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

It Started With a Frozen Screen...

Everything looked fine.
My React application compiled successfully, there were no syntax errors, and the UI loaded exactly as expected.Then I clicked a button.A few seconds later, the page became sluggish.

The CPU usage shot up.
The browser started lagging.
And then...
React crashed with:
Maximum update depth exceeded.

At first, I assumed it was a complex bug somewhere in my API or state management.
I couldn't have been more wrong.

The Investigation

I opened the browser's Developer Tools.
The Network tab looked suspicious.
The same API request was firing repeatedly.
Not twice.
Not ten times.
Hundreds of times.
Every response triggered another request.
Something inside my component kept telling React to render again... and again... and again.

The Culprit

After tracing the component, I found this innocent-looking code:

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

At first glance, it didn't seem wrong.
But here's what was happening:
The component rendered.
-useEffect executed.
-setUsers() updated the state.
-Updating the state triggered another render.

Since users changed, useEffect ran again.
Repeat forever.
It was an infinite rendering loop.

The Fix

The solution wasn't complicated.
I changed the dependency array so the effect only ran when it actually needed to.

useEffect(() => {
fetchUsers();
}, []);

In another part of the component, I also memoized values that were being recreated on every render using useMemo and wrapped callback functions with useCallback where appropriate.

These small changes completely eliminated the unnecessary renders.

Before vs After

-Before

Browser became unresponsive.
Hundreds of API calls.
High CPU usage.
React threw "Maximum update depth exceeded."
Poor user experience.

-After

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

Sometimes the smallest dependency array causes the biggest headaches.

What I Learned

This bug taught me several valuable lessons.
Don't update the same state that your effect depends on unless you truly intend to trigger another effect.
Always review your dependency arrays carefully.
Remember that every state update causes another render.
If an effect updates a dependency it listens to, ask yourself:
"Will this ever stop?"
That single question can save hours of debugging.

If Sentry Were Watching...

This issue would have been much easier to investigate with Sentry.
Features like:

Error Monitoring
Performance Monitoring
Session Replay

could quickly reveal excessive renders, repeated network requests, and performance bottlenecks, making the root cause much easier to identify.

Final Thoughts

This wasn't the most complicated bug I've ever encountered.
It wasn't caused by an obscure library or a hidden browser issue.
It came from a single useEffect dependency.
That's what makes React both powerful and challenging.
A tiny mistake can create an infinite rendering loop—but once you understand how React thinks, these bugs become much easier to spot.
Now, whenever I write a new useEffect, I pause for a moment and ask:
"Could this accidentally trigger itself?"
That habit has already saved me from repeating the same mistake.
Thanks for reading, and happy debugging!

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