Forem: Oğuzhan Ağır

React Performance: Preventing Unnecessary Re-renders

Oğuzhan Ağır — Wed, 11 Mar 2026 21:47:24 +0000

The original and complete version of this article is available on the ASP.NET Zero blog:
https://aspnetzero.com/blog/react-performance-and-preventing-unnecessary-renders

React applications can sometimes feel slow even when everything appears to work correctly. The UI renders, no errors occur, yet interactions feel sluggish. Buttons respond with slight delays, scrolling may stutter, and typing can occasionally feel laggy.

In many cases, the underlying reason is unnecessary component re-renders.

React does not rebuild the entire DOM on every update. Instead, when a component renders:

• The component function executes again
• React generates a new virtual tree
• React compares it with the previous render
• Only the necessary DOM updates are applied

This means a re-render does not necessarily mean a DOM update. However, every render still executes the component function again, which may involve expensive calculations, large lists, or complex component trees.

A Common Cause of Performance Issues

One of the most common causes of unnecessary renders is placing state too high in the component tree.

const Page = () => {
  const [count, setCount] = useState(0);

  return (
    <>
      <button onClick={() => setCount(count + 1)}>
        {count}
      </button>
      <HeavyComponent />
    </>
  );
};

Even though HeavyComponent does not use the count state, it will still re-render whenever the parent component renders.

A better approach is state colocation, meaning state should live in the lowest possible component that actually needs it.

Memoization and Referential Stability

React also provides tools such as:

• React.memo
• useMemo
• useCallback

These tools help prevent unnecessary renders by stabilizing props and avoiding repeated calculations. However, they should be used carefully, because excessive memoization can add complexity without improving performance.

Rendering Large Lists

When working with very large lists, rendering every element can become expensive. In such cases, techniques like virtualization can significantly improve performance by rendering only the visible portion of the list.

Libraries such as:

• react-window
• react-virtuoso

allow React applications to handle thousands of rows efficiently.

Measure Before Optimizing

Performance optimization should always begin with measurement rather than assumptions. Tools like the React DevTools Profiler help identify which components render, why they render, and how long they take.

Without profiling, optimization often becomes guesswork.

Read the Full Article

This post only provides a brief overview of the topic.

The full article explains in detail:

• React re-render mechanics
• architectural performance principles
• Context API performance pitfalls
• referential stability problems
• real-world optimization strategies for large React applications

Read the complete guide here:
https://aspnetzero.com/blog/react-performance-and-preventing-unnecessary-renders

The True Face of Referential Equality and Optimizations in React

Oğuzhan Ağır — Fri, 06 Mar 2026 20:40:59 +0000

When performance issues arise in React applications, React.memo, useMemo, and useCallback are usually the first things that come to mind. In practice, however, adding these tools often merely complicates the code without delivering the expected performance boost.

The underlying reason isn't that React is inadequate, but rather a fundamental misunderstanding of referential equality within React's render model and how these optimization tools actually work.

React's Decision Mechanism: Value vs. Reference

When deciding whether to re-render a component, React doesn't check the contents of the data (structural equality). Instead, it checks if the data points to the same location in memory (referential equality). It uses a shallow comparison similar to JavaScript's Object.is() method.

const a = { value: 1 };
const b = { value: 1 };

console.log(a === b); // false

In the example above, even though objects a and b have identical content, they point to different memory locations. Therefore, React considers them completely different values. This becomes critical especially when objects, arrays, and functions are passed as props to child components.

The Shallow Comparison Preference

React.memo, PureComponent, and Hook dependency arrays intentionally perform a shallow comparison. If React were to deeply compare every property within objects during every render, the performance cost would be significantly higher.

const Child = React.memo(({ options }) => {
  /* ... */
});

const Parent = () => {
  // A new 'options' object is created in memory during every render.
  const options = { pageSize: 20 };

  return <Child options={options} />;
};

In this example, every time the Parent component renders, a new options object is created in memory. Even though the Child component is wrapped in React.memo, the optimization cannot kick in because the reference of the options prop has changed, causing the Child to re-render unnecessarily.

Impact on the Reconciliation Process

In React, rendering does not mean directly updating the DOM. During the render phase, React generates a new component tree (Fiber tree) and compares it with the previous one (Reconciliation).

If a component's state or prop references have changed, React re-renders that component and its entire subtree. Even if there are no actual changes to the DOM, constantly changing references force React to perform this comparison repeatedly, wasting CPU cycles.

Why useMemo and useCallback Fall Short

These two Hooks are designed to keep references stable (memoization), but when implemented incorrectly, they only add overhead to the application.

The Limits of useMemo: useMemo is used to cache expensive calculations or keep references stable. However, if a value in the dependency array changes its reference on every render, the calculation inside useMemo will re-run every time. In this case, not only does the optimization fail, but React is also burdened with the extra work of tracking these dependencies.
The Role of useCallback: useCallback caches function definitions. But if a function depends on a frequently updated state (e.g., state changing on every keystroke in a text input), this function will be recreated with every keystroke. Passing this function as a prop to child components will cause them to continuously re-render as well.

Every Render Creates Its Own Scope (Closures)

In React, every render creates its own lexical scope. This means that during each render, a "snapshot" of the current state and prop values is taken.

Functions within a component capture the values belonging to that specific render. When the state updates, the component re-renders, a new snapshot is taken, and naturally, brand-new functions working with these new values are created in memory. This is React's expected behavior.

Architectural Solutions Over Forced Optimization

Instead of trying to forcefully stabilize references using useMemo and useCallback, rethinking the component architecture is often a more permanent and cleaner solution.

Moving State Down: If a piece of state only affects a specific child component, move that state directly into the child rather than keeping it in the parent. This prevents the parent from rendering unnecessarily.
Lifting Content Up (Children Prop): By passing expensive components to a parent via the children prop, you can ensure that the child components are unaffected when the parent's state changes.
Using Primitive Values: Instead of passing an entire object to child components as a prop, pass only the necessary primitive values like string, number, or boolean. Primitives are always compared by value, not by reference.

React.memo, useMemo, and useCallback are not magic wands. These tools only provide benefits in applications where the architecture and data flow are properly structured. If you are experiencing performance issues, rather than immediately reaching for these Hooks, it is much better to ask architectural questions like, "Where should this component's state live?" or "Do I really need to pass this prop?"

When Are Custom Hooks an Advantage in React, and When Do They Become a Liability?

Oğuzhan Ağır — Fri, 06 Feb 2026 08:34:02 +0000

Custom hooks are one of React’s most powerful abstraction tools but they’re also one of the easiest ways to quietly make a codebase harder to understand.

In real projects, I’ve often seen hooks introduced with good intentions, only to later cause questions like:

What does this hook actually do?

Why is changing this so risky?

Why do I need to read three hooks to understand one component?

This article looks at when custom hooks genuinely improve readability and reuse, and when they become a liability due to premature or over generalized abstraction. It focuses on practical signals, concrete examples, and questions you can ask before extracting logic into a hook.

If you’ve ever wondered whether a hook is simplifying your component or just hiding complexity, you might find this useful:

👉 https://aspnetzero.com/blog/react-custom-hooks-pros-cons

An ASP.NET Core + React Template Worth Reviewing

Oğuzhan Ağır — Thu, 22 Jan 2026 12:06:05 +0000

For those looking for an example of how a starting structure can be set up for ASP.NET Core + React, sharing this as a reference.

There is a React based UI on the ASP.NET Zero side. It makes it possible to see how concerns such as login, authorization, tenant separation, basic administration pages, and localization are handled on the React side.

On the frontend, Vite, Ant Design, Redux Toolkit, and TypeScript are used. The backend follows a familiar ASP.NET Core structure.

For those who want to take a closer look, the article is here:
https://aspnetzero.com/blog/react-ui-has-arrived-in-aspnet-zero

ASP.NET Core Dependency Injection From Scopes & Lifetimes to .NET 9 Source Generators

Oğuzhan Ağır — Thu, 23 Oct 2025 06:19:24 +0000

Dependency Injection in ASP.NET Core is simple... until you hit a subtle memory leak or a captive dependency bug.

Are you positive you're not creating a "captive dependency"? Do you know the right way to use a Scoped service (like a DbContext) inside a Singleton background worker?

I've just published a guide that goes beyond the basics and dives into the advanced patterns and new features you need to know.

This isn't just AddTransient vs. AddScoped again. We cover:

The Captive Dependency trap (and how to fix it).
Using IServiceScopeFactory in IHostedService like a pro.
.NET 9 Source Generators for blazing fast startup & Native AOT.
Keyed Services ([FromKeyedServices("key")]) for runtime flexibility.
The Decorator Pattern for clean, cross-cutting concerns.
Proper async cleanup with IAsyncDisposable.

You can move beyond the basics and start writing robust, testable, and high performing DI compatible code. This guide shows you how.

👉 Read the Full Guide on ABP.io

What's your favorite Dependency Injection hack? Let me know in the comments! 👇

Building an In-Memory Background Job Queue in ASP.NET Core (Intro + Deep Dive Link)

Oğuzhan Ağır — Tue, 30 Sep 2025 11:51:53 +0000

If you've ever wondered how to run asynchronous, long running tasks without blocking your API responses and without pulling in external dependencies like Hangfire or RabbitMQ this might interest you.

In my latest article on ABP Community, I walk through how to build an in memory background job queue from scratch using only built in .NET tooling (IHostedService, System.Threading.Channels, dependency injection, etc.). It’s ideal for scenarios where you need lightweight queueing in a single application instance (with the usual caveats). 👇

What you’ll learn

How to define a IBackgroundTaskQueue interface
Implementing it using Channel<T>
Creating a BackgroundService that continuously dequeues and executes jobs
Wiring it into the ASP.NET Core DI container
Pitfalls and limitations of an in memory approach (e.g. job loss upon restart, scalability)
When to switch to more robust solutions (Hangfire, message brokers)

If you like hands on, from scratch tutorials, here’s the full article:
How to Build an In Memory Background Job Queue in ASP.NET Core from Scratch