DEV Community: Alejandro

Part 2: Angular Bundle Size Is Only One Part of Performance

Alejandro — Mon, 20 Jul 2026 13:20:53 +0000

Part 2 of the Angular in Production series
One of the first things people usually check when an Angular application feels slow is the bundle size. That makes sense. If the browser has to download several megabytes of JavaScript before the application can become interactive, the initial experience will probably suffer.

So developers start looking at:

bundle analyzers
lazy-loaded routes
tree shaking
third-party dependencies
unused code
build configuration

These are all important, but reducing the JavaScript bundle is only one part of improving performance. A smaller bundle can make an application load faster. It does not automatically make the application fast once it is running. That distinction is easy to miss.

Loading Performance and Runtime Performance Are Different Problems

Imagine an Angular application with a 3 MB initial JavaScript bundle. The application takes several seconds to become interactive. After optimizing the bundle, the initial JavaScript is reduced to 1 MB.

The first load improves significantly. But after the application starts, opening a large table still freezes the browser for two seconds. The bundle optimization worked, it just didn't solve the second problem. The application had two different performance bottlenecks. One was related to loading and the other was related to runtime work.

I try to think about performance in separate stages:

User opens the application --> Browser downloads resources --> Browser parses and executes JavaScript --> Angular bootstraps --> Application renders --> User interacts with the application

Each stage can have a different bottleneck. Optimizing on stage does not necessarily improve the others.

A smaller Bundle Still Has to Be Executed

Reducing bundle size is valuable, but the number of bytes downloaded is not the only thing that matters.

The browser also has to:

download the JavaScript
parse it
compile it
execute it
create the initial application
render the result

This means that two bundles with similar sizes can still behave differently. For example:

Application A
1.5 MB JavaScript
Simple initialization
Minimal startup work

And:

Application B
1.5 MB JavaScript
Heavy initialization
Multiple API requests
Large amount of synchronous work

They have a similar bundle size. The user experience can still be very different. This is why I try not to use bundle size as a single definition of frontend performance. It is an important metric. It is just not the entire picture.

The Initial Bundle Should contain What the User Needs First

One of the most efffetive ways to improve the initial experience is to avoid loading code before it is needed. Consider an application with routes like:

/dashboard
/orders
/reports
/admin
/settings

A user visiting /dashboard probably doesn't need the entire reporting system and administration panel immediately. Loading all of those features upfront means the browser has to download code for functionality the user may never use.

Lazy loading gives the application a better boundary:

const routes: Routes = [
    {
        path: 'dashboard',
        loadChildren: () =>
            import('./dashboard/dashboard.routes')
                .then(m => m.DASHBOARD_ROUTES)
    },
    {
        path: 'reports',
        loadChildren: () =>
            import('./reports/reports.routes')
                .then(m => m.REPORTS_ROUTES)
    }
];

Now the reporting code can be loaded when the user actually navigates to that part of the application.
The idea is simple: The initial bundle should contain what is needed to start the application, not necessarily everything the application can do.
This becomes increasingly important as an application grows.

Dependencies Can Quietly Become a Performance Problem

One of the easiest ways to increase bundle size is to add another dependency. At the time, the decision often looks completely reasonable.

You need a date utility --> you install a library
You need a chart --> you install another library
You need a component --> you install another package

plaintext
None of these decisions seems particulary important in isolation. Eventually, however, the application contains a large collection of dependencies. Some of them might be used everywhere. Others might only be used by one feature and others might only be used by one feature. Some might have been added years ago and barely used anymore.
For example:

import * as utils from 'large-utility-library';

plaintext
may bring a very different amount of code into the application than importing only what is actually needed:

import {formatDate} from 'large-utility-library/date';

plaintext
The exact behaviour depends on the package and the build tooling, so I wouldn't assume that every import style automatically produces a problem. But I do think dependencies deserve periodic review. A package is not free just because installing it takes one command. I can affect:

bundle size
build time
startup time
maintenance
security updates
future migrations

Third-Party Code Is Still Part of Your Performace Budget

A common mistaje is to think only about the code written inside the application. But the browser doesn't care who wrote the code. Your code and third-party code are still part of the same application. A library might provide useful functionality while also adding significant JavaScript to the initial load.

For example:

Your application + UI library + Chart library + Editor + Analytics + Date library --> Initial JavaScript

plaintext
Sometimes the library is absolutely worth the cost. A complex feature can be much cheaper to maintain by using an established library instead of implementing everything yourself. The question isn't if you can remove every dependency. That would usually be unrealistic. The better question is if this dependency need to be part of the initial experience.

A rich text editor used only on an admin page probably shouldn't necessarily be downloaded by every user visiting the public application. A charting library used only on one route might be a good candidate for lazy loading. The optimization is not always removing the dependency. Sometimes it is moving it to the point where it is actually needed.

Lazy Loading Can Also Be Applied to Features

Route-level lazy loading is usually the first place people look. But the same principle can apply inside a feature. For example, imagine a dashboard with several expensive sections:

Dashboard
├-- Summary
├-- Activity
├-- Analytics
└-- Export tools

plaintext
The user may only need the summary immediately. Loading evert chart, export utility and analytics module before the user interacts with them can increase the cost of the initial page. In come cases, loading heavy functionality on demand makes more sense.
The implementation depends on the feature and the Angular version, but the architectural idea is the same:

Load the application --> Load the current feature --> Load expensive functionality --> Only when needed

plaintext
This is especially useful for features such as:

data visualization
rich text editors
PDF generation
large admin tools
complex configuration interfaces

The user shouldn't necessarily pay the performance cost of functionality they ever use.

But Lazy Loading Is Not Automatically Better

There is also a point where lazy loading can become excessive. If an application splits every small component into a separate chunk, the result may become difficult to reason about. The browser may need to make many additional requests. The application may spend mor time coordinating chunks than it would have spent loading a slightly larger initial bundle.

This is why I don't think the goal should be to make the initial bundle as small as possible. But the better goal is making the initial bundle appropriate for the first experience. A small bundle that requires many additional requests before the user can actually use the application may not be better than a slightly larger bundle that starts immediately. Performance is about the entire experience, not a single number from a build report.

The Next Bottleneck Is Often JavaScript Execution

Even after reducing the amount of JavaScript downloaded, the application can still feel slow. At this point the problem may be the amount of work the browser has to perform after the code arrives. For example:

@Component({ 
    template: `
        <div *ngFor="let product of products">
            {{ calculatePrice(product) }}
        </div>
    `
})
export class ProductListComponent {
    calculatePrice(product: Product) {
        return product.price*product.quantity;
    }
}

plaintext
For small list, this may not matter, but for a large list, repeated calculation during rendering can become expensive. The problem here isn't the size of the bundle but the amount of work being performed during runtime. This is where bundle optimization ends and application performance begins.

Runtime Performance Starts After the Bundle Has Loaded

When people talk about frontend performance, i'ts easy to focus on everything that happens before the application becomes interactive. But once the JavaScript has been downloaded and Angular has bootstrapped the application, a completely different set of problems can appear.

This is where the application spends most of its lifetime. The user navigates between routes and tables update, forms change, charts render, dialogs open and close, search result are filtered and if those interactions feel slow, reducing the bundle size won't help anymore. The problem is no longer how much code the browser downloaded. The problem is how much work the application is doing while it runs.

Rendering the Same Work Over and Over

One of the most common sources of runtime performance issues is repeated work. Take this simple component:

@Component({ 
    selector: 'app-products',
    template: `
        <div *ngFor="let product of products">
            {{ calculatePrice(product) }}
        </div>
    `
})
export class ProductsComponent {
    products: Product[] = [];
    calculatePrice(product: Product){
        return product.price*product.quantity;
    }
}

typescript
There's nothing technically wrong but if the list contains several thousand products and Angular evaluates that function repeatedly during change detection, the cost starts to add up. The calculation itself isn't expensive. Repeating it hundreds or thousands of times is. In cases like this, I usually try to move the work closer to where the data is created instead of where it's rendered.

products = apiProducts.map(product => ({
    ...product,
    totalPrice: product.price*product.quantity
}));

typescript
Now the template becomes much simpler:

<div *ngFor="let product of products">
    {{ product.totalPrice }}
</div>

plaintext
Now, the browser spends less time recalculating values that haven't changed.

A Fast Route Can Still Feel Slow

Sometimes the route itself loads quickly. The API responds almost instantly and the bundle is already cached. Navigation completes in a fraction of a second. And yet the page still feels sluggish. This usually means the bottleneck isn't the network anymore. It's rendering. For example, rendering a large table:

<tr *ngFor="let order of orders">
    ...
</tr>

typescript
If orders contains ten thousand elements, Angular isn't necessarily the problem. The browser now has to create, paint and maintain ten thousand DOM nodes. No framework can completely avoid that cost.

This is why techniques like pagination or virtual scrolling often have a much larger impact than trying to optimize change detection. The fastest DOM node is the one that doesn't exist.

Change Detection Shouldn't Become the Scapegoat

Angular's change detection often gets blamed whenever an application becomes slow. Sometimes that's fair. Most of the time, though, it's simply exposing expensive code that already exists. Consider this example:

<div *ngFor="let user of users">
    {{ fullName(user) }}
</div>

typescript
The problem isn't that Angular is caling fullName(). The real question is why does rendering this component require recalculating the same value over and over.
Changing the component to OnPush may reduce how often Angular checks it. It doesn't remove unnecessary work.

Whenever I profile an application, I try to optimize the work itself before changing the detection strategy. If the application performs less work, every change detection cycle neturally becomes cheaper.

Network Performance Is Also Part of Frontend Performance

Another thing that's easy to overlook is duplicated network requests. I've seen applications where several components independently request exactly the same data.

this.http.get('/api/profile');

Then another component that is the same and another and another. Each request may be relatively fast. Together they create unnecessary network traffic, duplicated parsing and additional rendering work.

Caching or sharing data often provides a larger performance improvement than shaving another fifty kilobytes off the JavaScript bundle. Performance isn't just about the browser. It's also about avoiding unnecessary work across the entire application.

My Personal Rule

One idea I come back to repeatedly is that performance works like a budget. Every decision consumes a small part of it. That means another dependency, animation, HTTP request, another large component, subscription and another expensive calcutation. And none of these choices seems particularly important on its own. But after hundreds of similar decisions, the application starts feeling heavier. That's why I rarely ask if the optimization is worth it and i ask instead if the additional work makes worth making every user pay for it. Sometimes the answer is absolutely yes and others it's clear that the work could happen later or not at all.

Conclusion

Bundle size is one of the easiest performance to measure. It's visible in every build, easy to compare between commits and satisfying to reduce but it's only the beginning. Users don't experience performance as a bundle size. That experience depends on much more than the amount of JavaScript downloaded. It depeds on:

how much work happens during rendering
how often expensive calculations are repeated
how many unnecessary network requests are made
how much DOM the browser has to manage
how much code is loaded before it's actually needed

Optimizing Angular applications isn't about chasing a single number. It's about reducing unnecessary work throughout the application's lifetime.

Sometimes that means making the bundle smaller, others it means rendering less and others moving calculations. Sometimes it simply means asking whether the application is doing work that nobody benefits form.

Next Article in This Series

Part 3: The Angular Change Detection Mistakes That Make Large Apps Feel Slow

Previous Article in This Series

Part 1: Why Angular Applications Get Slower as They Grow

Thanks for reading! If your Angular application has accumulated performance or maintainability problems over time, this is the kind of work I help teams with: debugging existing codebases, improving performance and refactoring incrementally. You have a link to my upWork in my Dev profile.

Part 1: Why Angular Applications Get Slower as They Grow

Alejandro — Thu, 16 Jul 2026 14:50:26 +0000

Part 1 of the Angular in Production series

Most Angular application don't become slow because someone madre one catastrophic mistake. Usually, the application starts normally. When you start, there are a few components, a few routes, some API calls, a couple of forms and everything feels fast enough. But then the application grows and more features are added, more dependencies are installed, more components start sharing data, more business logic moves into services and more API calls happen in the background. Eventually, someone notices that the application doesn't feel as responsive as it used to. The initial load takes longer, navigating between pages feels slower and some screens freeze briefly. A table that used to render instantly now takes noticeable time.

The first instinc is usually to look for one specific problem. Maybe Angular is running change detection too often or maybe the bundle is too large or there are too many subscription or a component needs OnPush. Sometimes that's correct but in larger applications, performance problems are usually the result of several small decisions accumulating over time.

Performance Problems Usually Accumulate

One of the things I've learned working with frontend applications is that performance problems rarely appear at the same time as the code that caused them. A component might be perfectly acceptable when it renders 20 items. But the same component might become a problem when it renders 10,000. A service might make one API request during a page load. After several features start depending on it, the same service might trigger five requests for the same data. A dependency might add 50KB to the application.

That doesn't matter much by itself but after several similar decisions, the initial JavaScript bundle becomes signifantly larger. The code didn't necessarily become bad overnight. The application simply grew beyond the assumptions that were made when the original code was written. This is why optimizing a large Angular application is often less about finding a single "magic fix" and more about understanding where the application is spending its time.

The Application Has More Than One Performance Problem

When someone says that the Angular app is slow, that can mean several completely different things. For example:

the first page takes too long to load
navigation feels slow
typing in a form is laggy
a table takes several seconds to render
API requests are duplicated
the browser uses too much memory
the application freezes during a particular interaction

These problems don't necessarily have the same cause. A slow initial load is usually a different problem from a slow table, and that is different from a memory leak and different from an API request that takes five seconds. I know this sounds obvious, but it's easy to forget when performance work starts with assumptions instead of measurements.

The First Thing I Check Is Usually Not Angular

When an application feels slow, my first instinct nowadays is not to immediately change the Angular code. I want to know where the time is going first.

This is why I don't like generic performance advice such as "Just use OnPush" or "Add lazy loading" or "Use signals". Those can all be useful but applying them without knowing the bottleneck is mostly guesswork.

A Large Bundle Is Not Always a Runtime Problem

One of the easiest performance problems to understand is the initial JavaScript bundle.
Imagine an application that downloads:

main.js           3.2 MB
vendor.js         1.8 MB
styles.css        400 KB

The user needs to download, parse and execute all of that before the application becomes fully usable. That obviously create a bad initial experience. But reducing the bundle size won't necessarily fix a slow interaction after the application has loaded.
For example, this component might still be slow:

@Component({ 
    selector: 'app-orders',
    template:`
        <div *ngFor="let order of orders">
            {{ calculateTotal(order) }}
        </div>
    `
})
export class OrdersComponent{
    orders=[];
    calculateTotal(order: Order){
        return order.items.reduce(
            (total, item) => total + item.price * item.quantity,
            0
        );
    }
}

Even if the application has a tiny initial bundle, repeatedly doing expensive work during rendering can still make the interface feel slow. This is one of the reasons I try to separate two questions: how quickly can the application start and how efficiently does it behave once it is running. they are related but they are not the same problem.

Components Often Become the Place Where Everything Meets

Another common pattern appears as an application grows. A component starts small.

export class OrdersComponent {
    orders: Order[] = [];
}

Then more features get added.

export classe OrdersComponent{
    orders: Order[] = [];

    filters= {};
    selected Order?: Order;

    isLoading= false;
    showModal= false;

    loadOrders() {}
    applyFilters() {}
    exportOrders() {}
    deleteOrder() {}
    calculateTotals() {}
    updatePagination() {}
}

Eventually the component becomes responsible for:

loading data
transforming API responses
managing filters
handling forms
controlling modals
calculating business logic
managing pagination
displaying the UI

At that point, performance and maintainability problems often start appearing together. The component has too many responsibilities. A change in one area can affect anther and it becomes harder to understand what causes a render or which operation its expensive. And it becomes harder to optimize anything without worrying about breaking something else. I don't think the solution is to split every component into the smallest possible pieces that often creates a different kind of complexity.

The more question to ask yourself is if this component still have a clear responsibility and if the answer is no, performance work becomes much harder because the boundaries of the application are already unclear.

The Same Data Is Often Loaded More Than Once

One of the most common problems I see in growing applications is duplicated work.
For example:

ngOnInit() {
    this.userService.getCurrentUser()
        .subscribe(user => {
            this.user = user;
        });
}

More than one component does this same thing and each component is independently asking for the same information. The application may end up making several requests for data that hasn't changed. This is not necessarily a problem when there are only two components but as the application grows, the number of requests can increase without anyone explicitly deciding that it should.
A shared data layer can help:

@Injectable({ 
    providedIn: 'root'
})
export class UserService  {
    private user$ = this.http
        .get<User>(`/api/user')
        .pipe(
           shareReplay({bufferSize: 1, refCount: true})
        );
    getCurrentUser(){
        return this.user$;
    }
}

Now multiple consumers can share the same request and cached result. The exact solution depends on the application. Sometimes a simple service is enough, others a query library is more appropiate and others the data should be loaded at the route level.

The important part is recognizing that every component independently loading the same data is often a sign that the application has no clear ownership of that data.

Performance Problems Are Often Architeture Problems

This is probably the main reason I don't like treating Angular performance as a collection of isolated tricks.
A slow application can be caused by:

too much JavaScript
expensive rendering
unnecessary change detection
duplicated API calls
large components
unbounded lists
memory leaks
unnecessary state synchronization

Those problems often have something in common. The application is doing work in places where it doesn't need to. Sometimes that means a component is recalculating something. Sometimes it means the same data is being fetched multiple times. Sometimes ut neabs the browser is loading code for a feature the user hasn't opened yet and others it means a subscription remains active long after the component that created it has disappeared. The solution is rarely to optimize everything. Usually, the biggest improvement comes from finding the work that matters most and removing or delaying it.

Start With the Biggest Bottleneck

When i start investigating a slow Angular application, I try not to optimize everything at once. That usually creates a lot of work without necessarily improving the user experience. Instead, I try to answer a simpler question: what is the application spending msot of its time doing?

For an initial load, that might be downloading and executing too much JavaScript. For a slow screen, it might be rendering thousands of DOM nodes. For a lagy interaction, it might be expensive work happening repeatedly during change detection. For a page that becomes slower over time, it might be a memory leak. The solution depends on the bottleneck.

Initial Load: Ship Less Code

If the problem is the initial bundle, the first things I usually look at are:

lazy-loaded routes
large third-party dependencies
code that is loaded before it is needed
duplicated libraries
unnecessarily large assets

For example, a feature that is only used by a small percentage of users probably shouldn't be part of the initial application bundle.

const routes: Routes = [
    {
        path: 'reports',
        loadChildren: () =>
            import('./reports/reports.routes')
                .then(m => m.REPORTS_ROUTES)
    }
];

The user doesn't need to download the reporting feature before they have even opened it. The important point is that bundle optimization is only one part of the larger performance picture.

Rendering: Don't Make the Browser Do Unnecessary Work

Large collections are another common source of problems. Rendering thousands of elements at once can be expensive regardless of how well the rest of the application is structured.

<div *ngFor="let item of items">
    {{item.bane}}
</div>

If items contains a few dozen elements, this is usually fine. If it contains thousands, the browser has to create and manage thousands of DOM nodes. At that point, pagination or virtual scrolling may be a better solution than trying to optimize the loop itself. The goal isn't always to make Angular render more efficiently. Sometimes the best optimization is simply not rendering things that the user cannot see.

Change Detection: Avoid Repeating Expensive Work

Another area I pay attention to is what happens during change detection. Code like this can become expensive:

<div>
    {{calculateTotal(order)}}
</div>

If calculateTotal performs non-trivial work and is called repeatedly, the application may spend a surprising amount of time recalculating the same value. Moving the calculation to a more appropriate place can help:

orders= orders.map(order => ({
    ...order,
    total: calculateTotal(order)
}));

Or, depending on the situation, using a more appropriate change detection strategy can reduce unnecessary work. But again, I wouldn't start by changing every component to OnPush without understanding the data flow. A performance optimization should solve a measured problem, not just follow a checklist.

Memory Problems Are Usually Les Obvious

Some performance probloems don't appear immediately. An application can feel perfectly fine when the user first opens it but after navigating through the application for several minutes, however, memory usage can continue increasing. One possible cause is a subscription that remains active after its component has been destroyed. Modern Angular provides tools that make cleanup easier:

import {takeUntilDestroyed} fronm '@angular/core/rxjs-interop'; 
constructor(){
    this.service.events$
        .pipe(takeUntilDestroyed())
        .subscribe(event => {
            // handle event
        });
}

The specific solution depends on the situation, but the general problem is the same: A component should not continue doing work after it no longer exists. This is one of the reasons performance testing should include more than the initial page load.

Measure Before Changing the Architecture

The larger an Angular application becomes, the more tempting it is to start making large architectural changes.

Rewrite the state management. Replace the component structure. Migrate everything to a new pattern. Rewrite the API layer. Sometimes those changes are necessary but they can also create a lot of risk without addresing the actual bottleneck.

A more useful process is usually:

Measure --> Find the biggest bottleneck --> Change one thing --> Measure again --> Keep or revert the change

This might mean checking:

bundle analysis
browser performace profiles
network requests
memory usage
rendering behavior

The important part is having evidence before and after the change.

Conclusion

Angular applications rarely become slow because of one bad decision. They become slow because the application keeps growing thile the assumptions behind the original architecture stay the same.

A component that was perfectly reasonable at the beggining may become too expensive once it renders thousands of items. A service that made one API call may eventually be used by ten different components. A dependency that seemed insignificant may become part of a large initial bundle. A subscription that seemed harmless may remain alive long after its component has disappeared.

This is why I don't think performance optimization should start with a list of Angular features to enable. The first step is understanding what the application is actually doing. Then the optimization becomes much more specific:

load less code
render less
avoid repeating expensive work
eliminate duplicated requests
clean up resources
improve the boundaries between parts of the application

The biggest improvements often come from removing unneessary work rather than making the existing work slightly faster.

Next Article in This Series

Part 2: Angular Bundle Size Is Only One Part of Performance

Part 5: Stop Using Effects for State Resets

Alejandro — Thu, 16 Jul 2026 11:42:31 +0000

Part 5 and last of the Modern React Patterns series

Throughout this series, we've looked at several situations where useEffect is often used to coordinate state that didn't actually need coordinating. Derived values were recalculated inside Effects instead of during rendering. Server data was fetched inside Effects instead of being managed by a data-fetching layer. Props were copied into local state and then synchronized manually. User actions were converted into state changes just to trigger an Effect. The patern in this article is slightly different. This time, the state itself may be perfectly valid. The problem is that we're trying to reset it manually when the component's context changes. That's where I often see code like this:

useEffect(() => {
    setSelectedItem(null);
}, [userId]);

useEffect(() => {
    setStep(0);
}, [productId]);

useEffect(() => {
    setFormData(initialData);
}, [initialData]);

All of these can be correct in some situations. But quite often, the component doesn't need to reset its state. It needs to be treated as a new component.

The State Belongs to the Component Instance

Let's start with a simple example. Imagine a chat application. The same message composer is used for different conversations:

function ChatPage([conversationId}){
    return(
        <MessageComposer
            conversationId={conversationId}
        />
    );
}

Inside the composer, we have local state:

function MessageComposer({conversationId}){
    const[message, setMessage] = useState("");
    return(
        <textarea
            value={message}
            onChange={(event) => {
                setMessage(event.target.value);
            }}
        />
    );
}

The user types a message and then they switch to another conversation. Next, the new conversation should have a new empty composer.
A common solution is to reset the state when the ID changes:

function MessageComposer({conversationId}) {
    const [message, setMessage] = useState("");
    useEffect(() => {
        setMessage("");
    }, [conversationId]);
    return (
        <textarea
            value={message}
            onChange={(event) => {
                setMessage(event.target.value);
            }}
        />
    );
}

Again, it works, but the component is still the same React instance. We're keeping it alive and manually trying to make it behave like a new one. There's often a simpler way.

Use key When the Component Represents a New Entity

Instead of resseting the component internally, we can tell React that the identity has changed.

function ChatPage({conversationId}){
    return (
        <MessageComposer
            key={conversationId}
            conversationId={conversationId}
        />
    );
}

Now, when conversationId changes, React sees a different key. The previous MessageComposer is removed and a new one is created. Its state start from the initial value again.

function MessageComposer ({conversationId}){
    const[message, setMessage] = useState("");
    return(
        <textarea
            value={message}
            onChange={(event)} => {
                setMessage(event.target.value);
            }}
        />
    );
}

There's no Effect, no manual reset or synchronization logic. The component simply starts with a new state because it represents a new entity. This is one of those React features that I completely underestimated when I was learning the framework. I used to think of key mainly as something required when rendering lists. But keys are also how React determines thew identity of components. That makes them useful far beyond arrays.

A Key Is About Identity, Not Just Lists

When React renders a component, it doesn't only look at the component type. It also considers its position in the tree and its key. For example:

<Chat conversationId="one" />

and then:

<Chat conversationId="two" />

are still the same component type in the same position.
React can preserve its state. But:

<Chat
    key="one"
    conversationId="one"
/>

Followed by:

<Chat
    key="two"
    conversationId="two"
/>

represents a different identity. React can now discard the previous state and create a fresh instance. That's exactly what we want when the state belongs to a specific entity. The conversation has changed and the form should be new.

Forms Are a Good Example

This becomes especially useful with forms.
Imagine an edit page:

function UserPage({user}){
    return <Userform user){user} />;
}

The form has local state:

function UserForm({user}){
    const [name, setName] = useState(user.name);
    const [email, setEmail] = useState(user.email);
    return(
        <>
            <input
                value={name}
                onChange={(event)} => {
                    setEmail(event.target.value);
                }}
            />
        </>
    );
}

This is a reasonable design; the form owns a draft and the draft is allowed to differ form the server data. That's exactly the distinction we discussed in the previous article. The problem appears when we navigate from one user to another.
Without a key:

<UserForm user={user} />

React may preserve the existing state. The component is still in the same position in the tree. So the form that was editing User A may continue to contain User A's local draft even though the user prop now represents User B.
A common fix is:

useEffect(() => {
    setName(user.name);
    setEmail(user.email);
}, [user]);

But now we're back to synchronizing prop into state and the problems start appearing again. A user might be editing a form when a background refetch happens. The action goes like this:

The server object changes --> the effect runs --> The local draft gets overwritten

The reset logic has now become part of the component's behaviour. Instead, when the form represents a completely different user, I usually prefer:

<UserForm
    key={user.id}
    user={user}
/>

Now the state naturally belongs to the user being edited and then the user changes, the form is recreated.

This Is Different Form Resetting a Form After Saving

It's important not to overapply this pattern. There is a difference between "the user changed, so this is a new form" and "the user submitted the form, so I want to clear it".
The first is an identity change and a key may be a good solution and the second one is an event ans that usually belongs i the submit handler:

async function handleSubmit(event){
    event.preventDefault();
    await saveUser(formData);
    setName("");
    setEmail("");
}

The fact that both situations involve "resetting state" doesn't mean they should be solved the same way.
The important question is what caused the reset.

Resseting State Can Be a Sign of a Component Boundary Problem

Sometimes the problem isn't that the state needs to be reset, the problem is that the component owns too much state.
For example:

function ProductPage({productId}){
    const [selectedColor, setSelectedColor] = useState(null);
    const [selectedSize, setSelectedSize] = useState(null);
    const [quantity, setQuantity] = useState(1);
    useEffect(() => {
        setSelectedColor(null);
        setSelectedSize(null);
        setQuantity(1);
    }, [productId]);
    return(
        // ...
    );
}

This works, but the Effect is responsible for manually resetting every piece of local state whenever the product changes. As the component grows, the reset list grows with it. A new piece of state gets added. Someone forgets to add it to the Effect and now the new product open with state from the previous product. This is the kind of code that often works perfectly until the component becomes large enough. At that point, the reset Effect becomes a maintenance problem.

When key Is the Right Tool

The most useful I've found to think about this is simple: If the component represents a different entity, changing the key is often the cleanest way to reset its local state. For example:

<ProductEditor
    key={productId}
    productId={productId}
/>

When productId changes, the editor is no longer editing the same thing. A new component instance makes sense.
The same idea works for:

switching between users
changing conversations
navigating between documents
opening a form for a different record
changing the current step of an independent workflow

In all of these cases, the state belongs to the entity being displayed. A new entity should usually get a new state-

When You Should Not Use key

This doesn't mean that key should become a replacement for every reset Effect. Sometimes the component is still the same component and the state be preserved.
For example:

<Tabs>
    <Profile />
    <Settings />
</Tabs>

If the user switches between tabs, you might intentionally want each tab to preserve its state. In that case, destroying and recreating the component would be the wrong behavior. The same applies when only part of the state needs to change. If the user selects a new filter but you want to preserve their sort order, pagination or other local preferences, remounting the entire component may reset too much. This is why I don't think of key as a generic "reset button". It is primarily about identity.

My Personal Rule

The question it's not if you can use a key to reset this component, i'ts if this represent a different instance of the same thing. And if the answers is yes, key is often a good fit.

The Pattern I Try to Avoid

The pattern I now question is this:

function Component({id}){
    const [state, setState] = useState(initialState);
    useEffect(() => {
        setState(initialState);
    }, [id]);
    // ...
}

Before keeping the Effect, I ask whether the component should simple be recreated:

<Component
    key={id}
    id={id}
/>

Sometimes the answer is yes and sometimes it isn't. The important part is understanding why the state is being reset instead of automatically reaching for and Effect.

In general terms: use state for information that should persist within a component instance and use key when the component should become a new instance.

Conclusion

After working on larger React applications, I've become much more suspicious of Effects whose only purpose is to reset local state. Not because they are always wrong but because they often indicate that React's component identity isn't matching the way we think about the data. If a component moves from editing User A to editing User B, those are often two different component instances from a state perspective.

If a form changes from Product A to Product B, its draft probably shouldn't be manually synchronized with an Effect. An if a component is still representing the same entity, then its state probably shouldn't be reset just because some unrelated prop changed. And that leads us to the general rule I said before.

Finally

Across these five artiles, we've looked at some of the most common situations where useEffect is used as a general-purpose tool:

derived values that can be calculated during render
data fetching that belongs in a data-fetching layer
props that don't need to be synchronized into state
user actins that belong in event handlers
state resets that can often be handled through component identity

The common thread isn't that useEffect is bad. It's that Effects should have a clear reason to exist.

Previous Articles in This Series

Part 1: Why I Rarely Use useEffect Anymore (and what I use instead)
Part 2: Stop Fetching Data Inside useEffect (what modern React apps do instead)
Part 3: Stop Syncing Props Into State
Part 4: Event handlers are usually the better place for side effect

Thanks for reading!! If you're looking for help with an existing project or need someone to solve a tricky frontend/backend issue, you can also find my freelance profiles through my Dev.to profile.

Part 4: Event handlers are usually the better place for side effect

Alejandro — Thu, 16 Jul 2026 08:53:31 +0000

Part 4 of the Modern React Patterns series

In the previous articles we've been removing useEffects that existed only because React was being asked to synchronize things it already knows how to synchronize. Firstg we looked at derive state, then data fetching and then synchronizing props into state. This time the problem is slightly different. The useEffect isn't synchronizing data anymore. Instead, it's being used to react to something the user just did. Over the years I've noticed this is another pattern that slowly disappears as React developers gain experience. Not because useEffect is wrong. But because event handlers are usually a much more natural place for that logic.

A Pattern That Looks Perfectly Reasonable

Imagine a form with a Save button.
One implementation might look like this:

function UserForm() {
    const [shouldSave, setShouldSave] = useState(false);
    useEffect(() => {
        if (!shouldSave) return;
        save User();
        setShouldSave(false);
    }, [shouldSave]);
    return(
        <button onClick={() => setShouldSave(true)}>
            Save
        </button>
    );
}

There's nothing obviously wrong here. Clicking the button changes some state. The Effect notices that change. The save operation runs. It works. I've seeen this pattern in production more times than I can count. In fact, I used to write code like this myself because it felt like I was "keeping side effects inside useEffect", which sounded like good React practice. The problem is that this Effect isn't synchronizing with an external system. It's simply reacting to an event that we already know happened.

The Event Already Happened

When someone clicks the button, React already gives us the perfect place to respond. The click handler. Instead of storing a flag that says "someone clicked Save", we can simply save immediately.

function UserForm(){
    const handleSave = async() => {
        await saveUser();
    };
    return(
        <button onClick={handleSave}>
            Save
        </button>
    );
}

The component suddenly becomes easier to read. There isn't any intermediate state or another render whose only purpose is triggering an Effect. The action happens exactly where the event occurs.
Nowadays, whenever I review code and find boolean flags like shouldSave, shouldDelete or shouldSubmit, it's usually one of the first things I look at. very often they're only there to wake up an Effect.

Boolean Flags Usually Hide Event Logic

After seeing this pattern enough times, I started noticing the same variable names appearing over and over again.

const [shouldFetch, setShouldFetch] = useState(false);
const [shouldDelete, setShouldDelete] = useState(false);
const [shouldSubmit, setShouldSubmit] = useState(false);
const [shouldExport, setShouldExport] = useState(false);

Most of these aren't really pieces of state. They're event pretending to be state. That's an important distinction. State describeshow the UI looks right now and events describe something that happened. A button click isn't application state, it's simply an interaction. When we convert events into state, we usually end up writing an Effect whose only responsibility is translating that state back into the original action.
In other words, this is the process:

User clicks --> State changes --> Component renders again --> Effect runs --> Actual work starts

That's a surprisingly long journey for something that could have happened directly inside the click handler.

Effects Are About Synchronization

One idea that completely changed the way I use useEffect came directly from the React documentation. Effects exist to synchronize your component with something outside React. That could be:

opening a WebSocket
subscribing to browser events
integrating a third-party library
controlling a video player
updating the document title

Those are external systems, a button click, saving a form or deleting a record isn't. Those actions originate inside React and there's no synchronization involved. Once I started thinking about Effects this way, I noticed I was deleting far more of them than adding new ones.

Extra State Usually Means Extra Complexity

Let's imagine the save operation becomes slightly more complicated. We want to show a loading spinner. With the previous approach, we now have several moving parts.

const [shouldSave, setShouldSave] = useState(false);
const [loading, setLoading] = useState(false);
useEffect(() => {
    if(!shouldSave) return;
    async function save(){
        setLoading(true);
        await saveUser();
        setLoading(false);
        setShouldSave(false);
    }
    save();
}, [shouldSave]);

Nothing here is technically incorrect but notice how much machinery appeared around what was originally just "save when the user clicks". Compare it with keeping everything inside the event handler.

const [loading, setLoading] = useState(false);
const handleSave= async () => {
    setLoading(true);
    try{
        await saveUser();
    } finally {
        setLoading(false);
    }
};

Personally, I find this version much easier to follow. Everything related to saving lives in one place. The button starts the action, the handler performs the action and the loading state belongs to the action. There aren't multiple renders whose only purpose is coordinating when work should begin.

React Doesn't Need a Trigger Variable

One thing I notice quite often is that developers coming from other frameworks tend to think they need a variable that "activates" some behavior. React usually doesn't. If the user clicks something, React already tells us exactly where that happened. If a request should start after submitting a form, React already tells us which function handles the submit.

Adding another state variable often doesn't make the logic clearer. It simply delays the real work until after another render. That doesn't sound like much, but once components grow, these little patterns accumulate surprisingly quickly. One Effect becomes three. Then five and eventually the component spends more time coordinating itself than implementing the actual business logic.

When an Effect Is Actually the Right Choice

The point of this article isn't that every side effect should move into an event handler. That would be just another rule to follow without understanding the reason behind it. There are plenty of situations where an Effect is exactly the right tool.

The difference is what caused the work to happen. If the work started because the user clicked a button, the event handler is usually the right place. And if the work needs to happen because something outside the component changed, an Effect may be the right solution.

External Changes Are Different

Imagine a component that connects to a WebSocket.

useEffect(() => {
    const socket = new WebSocket(url);
    socket.onmessage = (event) => {
        setMessage(event.data);
    };
    return () => {
        socket.close();
    };
}, [url]);

This is a good use of useEffect. The WebSocket is an external system. React needs to synchronize with it. When url changes, the connection needs to be recreated. When the component unmounts, the connection needs to be cleaned up. The Effect describes that lifecycle clearly. The same idea applies to browser event listeners:

useEffect(() => {
    const handleResize = () => {
        setWindowWidth(window.innerWidth);
    };
    window.addEventListener("resize", handleResize);
    return () =>{
        window.removeEventListener("resize", handleResize);
    };
}, []);

The component is synchronizing with something outside React. That's what Effects are good at.

The Difference Is the Cause

Compare these two examples.

User clicks a button

<button onClick = {handleSave}>
    Save
</button>

The event handler should usually perform the save.

A WebSocket sends a message

useEffect(() => {
    socket.onmessage = handleMessage;
    return () => {
        socket.close();
    };
}, [socket]);

The Effect is appropriate because the event comes from an external system. The code may look similar because both situations involve something happening. But the source of the event is different and that's the distinction I find most useful.

My Personal Rule

A useful rule I now try follow is that if something happened, handle the event. If something is now true, represent it as state.
For example:

// Event
onClick={handleSave}

is different from:

// State
const [isSaving, setIsSaving] = useState(false);

The click happened once. isSaving describes the current state of the application. Those shouldn't be trated as the same thing. When an event becomes a boolean flag just tot trigger an Effect, the code is usually becoming more complicated than necessary.

When I find myself writing something like this:

const [shouldDoSomething, setShouldDoSomething] = useState (false);
useEffect(() => {
    if (shouldDoSomething){
        doSomething();
    }
}, [shouldDoSomething]);

I stop and ask mysellf what caused this work to happen.
If the answer is that the user clicked a button, then the code probably belongs here:

const handleClick = () => {
    doSomething();
};

If the answer is a WebSocket message arrived, the url changed, a third-party library changed or the browser fired an event, then an Effect might be exactly what the component needs. This small distinction has made a big difference in the way I structure React components.

Conclusion

I don't think useEffect is difficult because the API itself is complicated. The difficult part is deciding whether the code actually belongs there.

For a long time, I treated Effects as a general-purpose place for anything that wasn't rendering UI. That usually led to state flags, dependency arrays, extra renders and components that were difficult to follow.
Now I try to start from the cause instead. If the user did something, I usually handle it in an event handler and if an external system changed, I consider an Effect. That doesn't eliminate every Effect form a React application. It just means that the ones that remain usually have a clearer reason for existing.

Next Article in This Series

Part 5: Stop Using Effects for State Resets

Previous Articles in This Series

Part 1: Why I Rarely Use useEffect Anymore (and what I use instead)
Part 2: Stop Fetching Data Inside useEffect (what modern React apps do instead)
Part 3: Stop Syncing Props Into State

Thanks for reading!! If you're looking for help with an existing project or need someone to solve a tricky frontend/backend issue, you can also find my freelance profiles through my Dev.to profile.

Part 3: Stop Syncing Props Into State

Alejandro — Wed, 15 Jul 2026 12:00:53 +0000

Part 3 of the Modern React Patterns series

In the previous article (Part 2: Stop Fetching Data Inside useEffect (what modern React apps do instead)) we talked about one of the biggest reasons why React applications end up full of unnecessary Effects: fetching server data inside useEffect.
This time I want to cover another pattern that I still find suprisingly often during code reviews, even in mature codebases. Synchronizing props into local state, at first, it doesn't even look like a mistake. Actually, it feels like the obvious thing to do lije a parent passes some data, the child stores it in its own state and whenever the parent changes, the child updates its copy. Except that, in most cases, React never needed that second copy to exist.

The Pattern Everyone Writes at Some Point

If you've been writing React for a while, you've probably written something like this:

function UserProfile({user}){
    const [name, setname] = useState("");
    useEffect(() => {
        setName(user.name);
    }, [user]);
    return(
        <input
            value={name}
            onChange={(e) => setname(e.target.value)}
        />
    );
}

I've written code like this many times. I've also reviewed dozens of components doing exactly the same thing. The interesting part is that it usually works; nothing crashes, there are no console warnings, the UI behaves correctly during development, and that's why this pattern survives for so long. The problem don't usually appear until the component grows.

Why It Feels Like the Right Solution

When you're new to React, this pattern makes perfect sense. You receive some data, you keep it in state and when the prop changes, you synchronize it. Coming from other UI frameworks, this mental model feels completely natural. The problem is that React already re-renders your component every time its props change. That mean the prop is alrady synchronized. By copying it into state, you've created two values that are supposed to represent exactly the same thing. Now React has to keep both in sync. Not because React needs it, but because we introduced the duplication ourselves.

Two Sources of Truth

One of the easiest ways to make a React component harder to reason about is introducing multiple sources of truth. Imagine this simpler example:

function UserCard({user}){
    const [displayName, setDisplayName] = useState("");
    useEffect(() => {
        setDisplayName(user.name);
    }, [user]);
    return <h2>{displayName}</h2>;
}

There are now two values representing the user's name.

user.name
displayName

Ideally they should always contain exactly the same value. The problem is that react doesn't know that, they're just two independent pieces of data and every time one changes, something has to update the other. That's exactly what the Effect is doing. The funny thing is that the Effect isn't adding any business logic. It's simply compensating for the fact that we duplicated state. Whenever I review code nowadays, I try spot these situations quickly because they're ofter a sign that the component is becoming more complex than it needs to be.

The Bugs Usually don't Appear Immediately

This is probably the biggest reason why this pattern is so common. The first version works pèrfectly and then somebody adds a feature.
Maybe the input becomes editable.

<input
    value={displayName}
    onChange={(e)=> setDisplayName(e.target.value)}
/>

Still fine but a few weeks later another developer instroduces automatic refetching or optimistic updates or polling or live updates through WebSockets. Suddenly the Effect starts running much more often. Now imagine the user is typing while new data arrives from the server. Should the Effect overwrite what the user is writing? Should it ignore the update or should it merge both values?. At this point there isn't an obvious answer anymore. Not because React is difficult but because the component now owns two independent copies of the some data.

The Component Is Solving the Wrong Problem

One thing I've noticed after working on larger React application is that many Effets don't exist because the business logic is complicated. They exist because the component is trying to synchronize data that didn't need to be duplicated in the first place. That's an important distinction.
The business rule here isn't complicated: "show the user's name". That's it. The complexity comes from maintaining two values that should never diverge. Once I started looking at Effects this way, I found myself deleting far more of them than writing new ones.

Most Components Don't Need Local State

If the component only needs to display the data it receives, the simplest solution is usually the correct one.

function UserCard({user}){
    return(
        <>
            <h2>{user.name}</h2>
            <p>{user.email}</p>
        </>
    );
}

There's no local state or synchronization or Effect. Every render simply reflects whatever the parent passed down. That's already how React works. Very often, adding local state doesn't make the component more flexible. It simply gives React another value that now has to stay synchronized.

Derived Values Don't Need State Either

Antoher variation of the same problem looks like this:

const [isAdmin, setIsAdmin] = useState(false);
useEffect(() => {
    setIsAdmin(user.role === "admin");
}, [user]);

Again, there are now two sources of truth. But the second one doesn't even add new information, i'ts entirely derived from the first. Whenever I see this pattern nowadays, I usually replace it with a simple variable.

const isAdmin = user.role === "admin";

There's no Effect or state updates or extra render, just a value calculated during rendering. It's a tiny change, but after removing enough Effects like this, components become noticeably easier to understand.

Forms Are Usually the Exeption

Whenever someone says "don't sync props into state", the first example that comes up is forms. And that's fair. Forms are probably the most common case where creating local state is the right decision. imagine an edit profile page, the server sends this object:

{
    id: 1,
    name: "John",
    email: "john@example.com"
}

The user changes the name to Johnny, but hasn't clicked Save yet. At the moment there are actually two different pieces of information:

the persisted user coming from the server
the draft the user is editing

Those are not the same thing anymore. The mistake isn't copying the prop into state, but trying to keep both synchronized forever. Those values have different responsibilities. One represents the current server state and the other represents temporary UI state. Once you look at it that way, the problem becomes much clearer.

Initialize State once Instead of Synchronizing It Forever

One thing I see surprisingly ofter is this:

function UserForm({user}){
    const [name, setName] = useState("");
    useEffect(() => {
        setName(user.name):
    }, [user]);
    ...
}

The intention is understandable. Whenever a new user arrives, update the form. The problem is that every update to user resets the input
If the parent refetches data while the user is typing, their changes disappear. Instead, ask yourself a different question. Something like if you need to keep the form synchronized or do you need an initial value. Those are completely different requirements

Let React Reset the Component

One of my favorite solutions is also one of the simplest. Instead of synchronizing state yourself, let React mount a fresh component.

<UserForm
    key={user.id}
    user={user}
/>

Now the component behaves naturally. The process looks like this:

Open User A --> A new form is created --> Open User B --> React destroys the old form and creaters another one

As you can see, there's no synchronization Effect or manual reset or duplicated logic.
Using key intentionally like this is something I almost never did when I started with React, but nowadays it's often my first option.

Sometimes Local State Is the Right Tool

Reading this article, it might sound like local state is something to avoid. But that's not the point at all. Local state is great, it's duplicated state that's usually the problem. If the local state represents something different form the incoming prop, then everything is perfectly fine.
Some examples are:

editable forms
wizard steps
drag-and-drop interactions
temporary filters
undo/redo history
optimistic UI

All of these create state that intentionally diverges from the original prop. That's completely different from mirroring a prop just because we think we need to.

My Personal Rule

Nowadays, whenever I catch myself writing this:

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

I stop for a second.
Then I ask myself one question:
Why does this component need its own copy of this value?
Sometimes there's a good answer but most of the times there isn't. Usually I realize that the component only needs to read the prop. Or maybe the value can be derived during rendering or perhaps React can reset the component naturally by changing its key. That one question has probably saved me from writing dozens of unnecessary Effects.

Alternatives Before Reaching for useEffect

When I review React code now, these are usually the alternatives I consider first:
If the value can be calculated, derive it during render.

const isAdmin = user.role === "admin";

If the component only displays data, read it directly from props.

<h2>{user.name}</h2>

If the component needs a fresh state for a different entity, remount it with a different key.

<UserForm
    key={user.id}
    user={user}
/>

And if the component genuinely needs a draft that diverges from the original data, then local state is absolutely the right choice. The important part is understanding why that local state exists.

Conclusion

Looking back, I don't think synchronizing props into state is a beginner mistake. I've seen it in production code written by experienced developers. Mostly because it works, until it doesn't. The issue isn't the Effect itself, it's that the Effect is often hiding a deeper problem, the component owns data it never needed to own. One thing I've learned over the years is that React code becomes much easier to reason about when every pierce of data has a single owner. As soon as multiple copies appear, synchronizition logic follws. And synchronizition logic almost always ends up inside a useEffect. Whenever I find myself writing an Effect that copies a prop into state, I now assume it's unnecessary until I can prove otherwise. Most of the time, deleting the Effect actually makes the component simpler.

Next Article in This Series

Part 4: Event handlers are usually the better place for side effect
Part 5: Stop Using Effects for State Resets

Previous Articles in This Series

Part 1: Why I Rarely Use useEffect Anymore (and what I use instead)
Part 2: Stop Fetching Data Inside useEffect (what modern React apps do instead)

Thanks for reading!! If you're looking for help with an existing project or need someone to solve a tricky frontend/backend issue, you can also find my freelance profiles through my Dev.to profile.

Part 2: Stop Fetching Data Inside useEffect (what modern React apps do instead)

Alejandro — Wed, 15 Jul 2026 08:33:13 +0000

Part 2 of the Modern React Patterns series

In the previous article (Part 1: Why I Rarely Use useEffect Anymore (and what I use instead)) we looked at one of the most common reasons developers overuse useEffect: deriving state that React can already calculate during rendering.
This time I'd like to talk about another pattern that I see in almost every React codebase I've worked on: fetching data inside useEffect.
Just like derived state, this isn't technically wrong. In fact, it was the standard recommendation for years. Most of us learned React by writing data fetching exactly this way. The problem is that what starts as a perfectly reasonable solution, often becomes increasingly difficult to maintain as an application grows.

The Way We Learned

If you've been writing React for a while, you've probably written something very similar to this.

function UsersPage() {
    const [users, setUsers] = useState([]);
    useEffect(() => {
        fetch("/api/users")
            .then(res=> res.json())
            .then(setUsers);
    }, []);
    return <UsersList users={users} />;
}

There's nothing fundamentally wrong with this component, but the request is made when the component mounts so the response is stored in state and the UI updates automatically. This works perfectly for a small application, but production applications rarely stays this simple.

The Complexity Doesn't Appear Immediately

One reason this pattern became so popular i that the first implementation is incredibly small. You write ten lines of code, the data appears on the screeen and you move on to the next feature. A few weeks later somebody asks for a loading spinner and then the backend starts returning validation errors so you need to retry failed requests.
Eventually somebody reports that users sometimes navigate away before the request finishes and little by little, the component starts accumulating responsibilities that have nothing to do with rendering. This is an example of problems that I've seen and lived, all this story, in code language, ends up in something like this:

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

useEffect(() => {
    const controller = new AbortController();
    fetch("/api/users", {
        signal: controller.signal,
    })
        .then(res = > {
            if (!res.ok){
                throw new Error("Request failed");
            }
            return res.json();
        })
        .then(setUsers)
        .catch(err => {
            if (err.name !== "AbortError"){
                setError(err);
            }
        })
        .finally(() => {
            setLoading(false);
        });
    return() => controller.abort();
}, []);

This alone isn't particularly complicated but the issue is that almost every API request in your application starts looking exactly like this.

Same Pattern Everywhere

This is usually the point where the maintenance cost begins to show. Every page has a loading state, error state, request cancellation, retry logc and a duplicated fetch code.
If your application has twenty different API endpoints, you'll probably have twenty very similar Effects. At first this feels harmless because each component only knows about its own request. Over time you realize you're solving the same problems over and over again. The code isn't becoming more complex because your business logic is difficult, but because every component is independently trying to solve data synchronization.

Shared Data Exposes the Problem

Imagine your application has an authenticated user. The navigation bar, the profile page and also the settings page needs it. A common implementation looks something like this:

useEffect(() => {
    fetch("/api/me")
        .then(res=> res.json())
        .then(setUser);
}, []);

The component works, the next component copies the same Effect and then another one. Eventually three differents parts of the application are requesting exactly the same resource, even if the requests are fast, they're still duplicated work. More importantly, every component now owns its own loading state, its own error handling and its own copy of the fetched data; keeping everything synchronized becomes surprisingly difficult.

Server State Behavior

This was probably the biggest shift in the way I think about React applications. For a long time I assumed I was managing React state but in reality I was managing server state. Those are completely different problems. React state belongs to your application and server state belongs somewhere else. I can become stale.
Several components can depend on it simultaneously. It might already exist in memory but it may need background refreshes, retries after network failures and an optimistic updates after a mutation.
None of those concerns are really about rendering components. They're about synchronizing your application with an external system.

That's Why Dedicated Libraries Exist

Once I understood that distinction, my approach changed completely. Instead of treating every API call as another useEffect, I started using tools that are specifically designed for server state. For example, the following code:

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

useEffect(() => {
    fetch("/api/users")
        .then(res=> res.json())
        .then(setUsers)
        .catch(setError)
        .finally(() => setLoading(false));
}, []);

can become this other code:

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

The shorter syntax isn't the interesting part, but is everything that disappears. All the problems: Caching, deduplication, background refetching, retries, request cancellation and stale data management, have been solved by libraries such as TanStack Query. Instead of rebuilding thhose features in every component, you can focus on your application's actual behavior.

Use of useEffect

useEffect is not wrong at all. I still fetch data inside an Effect from time to time. If I'm building an internal tool with one request, a quick prototype or a page that will probably never grow beyond a few hundred lines of code. In this cases adding another dependency often isn't worth it. The problem it's not using useEffect, is continuing to scale the same pattern after the application has clearly outgrown it.

My Personal Rule

Nowadays I try to separate two completely different situations. If I'm synchronizing React with something external (a WebSocket connection, a timer, a browser event, a third-party SDK, etc.), useEffect is almost always the correct tool. But if I'm fetching data that lives on a server, I immediately think about server-state management instead.
Making than distinction has dramatically reduced the number of Effects I write. More importantly, it has made my components much easier to read. Most of them are now focused almost entirely on rendering UI instead of coordinating network requests.

Conclusion

One thing I've noticed over the years is that developers rarely overuse useEffect because they misunderstand React. Most of us simply learned React at a time when fetching data inside Effects was considered the normal approach. The ecosystem evolved, our applications became larger, libraries specialized in solving server-state problems became mature and our habits, however, often stayed the same.
Looking back, reducing the amount of data fetching I perform inside useEffect has probably been one of the biggest improvements I've made to the way I structure React applications.

Next Articles in This Series

Part 3: Stop Syncing Props Into State
Part 4: Event handlers are usually the better place for side effect
Part 5: Stop Using Effects for State Resets

Previous Article in This Series

Part 1: Why I Rarely Use useEffect Anymore (and what I use instead)

Thanks for reading!! If you're looking for help with an existing project or need someone to solve a tricky frontend/backend issue, you can also find my freelance profiles through my Dev.to profile.

Part 1: Why I Rarely Use useEffect Anymore (and what I use instead)

Alejandro — Wed, 15 Jul 2026 07:26:46 +0000

When I started learning React, I thought useEffect was the solution to almost everything. To derive state, to fetch data, to synchronize props or calculate a value, the answer for all this was useEffect.
After working on larger applications, i realized most of those effects weren't needed at all.
Today, I probably write 80% fewer useEffects than I did a few years ago. Not because it's a bad hook but because most problems have simpler solutions.
This article is the first part of my Modern React Patterns series, where I go over patterns that worked fine in small demos but became painful in production.

What useEffect Is Actually For

The React documentation describes effects as a way to synchronize your component with external systems.
That means things like:

network requests
WebSockets
timers
browser APIs
subscriptions
third-party libraries

If your effect isn't interacting with something outside React, there's a good chance you don't need one.

1. Don't Use useEffect For

One of the most common examples I still see is this:

const [fullName, setFullName]=useState("");
useEffect(() => {
    setFullName(`${firstName} ${lastName}`);
}, [firstName, lastName]);

It works but React now renders twice. The process that now is doing is the following:
render --> effect runs --> state changes --> render again
and there's no reason for that.

Instead i do this:

const fullName=`${firstName} ${lastName}`;

2. Don't Synchronize Props Into State

const [user, setUser] = useState(props.user);
useEffect(() => {
    setuser(props.user);
}, [props.user]);

Most of the times this creates two sources of truth. Eventually one of them gets updated and the other doesn't. Unless you intentionally want a local editable copy, just use the prop directly. It's much simpler

function prodile({user}){
    return <h2>{user.name}</h2>;
}

3. Don't Calculate Values Inside an Effect

I've seen code like this many times.

const[filteredUsers, setFilteredUsers]=useStat([]);

useEffect(() => {
    setFilteredUsers(
        users.filter(user=> user.active)
    );
}, [users]);

That's unnecessary state, i'ts way better:

const filteredUsers=users.filter(
    user=> user.active
);

If the computation is actually expensive:

const filteredUsers=useMemo(() => {
    return users.filter(user=> user.active):
}, [users]);

Notice that useMemo is an optimization, not a replacement for every calculation.

4. Debugging Is One of The Few Places Where I Still Use Effects A Lot

When debugging state updates I often do this:

useEffect(() => {
    console.log(user);
}, [user]);

It's incredibly useful while debugging but before merging the code, delete it.

5. Fetching Data With useEffect Isn't Always The Best Choice Anymore

Years ago almost every React project looked like this:

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

Nowadays we have much better alternatives. Libraries like TanStack Query or SWR solve things that you eventually end up building yourself:

caching
retries
background refetching
loading state
error state
deduplication And instead of all of this, you can:

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

That's less code and you get fewer bugs and better developer experience.

If you're interested in API reliability, I wrote another article about common integration mistakes:

"Building Reliable API integrations in Modern Web Applications"

6. Effects Often Hide Architecture Problems

Something I've noticed over time is whenever I find myself writing lots of effects indife the same component and it's usually because the component is trying to do too much. For example:

fetching
filtering
sorting
formatting
validation
event handling
rendering

and everything together. Splitting responsabilities into smaller hooks or components ofter removes half of those effects automatically.

When You SHOULD Use useEffect

None of this means "never use useEffect". There are plenty of legitimate use cases to use it, and let me tell some of them.
WebSocket connections:

useEffect(() => {
    const socket = new WebSocket(url);
    return() => socket.close();
}, []);

Timers:

useEffect(() => {
    const id= setInterval(fetchData, 5000);
    return() => clearInterval(id);
}, []);

Browser APIs:

useEffect(() => {
    window.addEventListener("resize", onResize);
    return() => {
        window.removeEventListener("resize", onResize);
    };
}, []);

Third-party libraries:

useEffect(() => {
    const chart= new Chart(canvas);
    return()=> chart.destroy();
}, []);

These are exactly the kinds of external systems effects were designed for.

My Personal Rule

Whenever I'm about to write an effect, I stop for a second and ask myself if am I synchronizing with an external system or am I compensating for my component design. That question alone has removed a surprising amount of unnecessary code from my projects.

Conclusion

useEffect isn't bad. It's just much easier to overuse than most React hooks. Today I try to use:

derived values instead of derived state
props instead of synchronized state
TanStack Query for server state
custom hooks for reusable logic
effects only when I actually need to synchronize with something outside React

And you can get fewer renders, less state, fewer bugs and components that are easier to understand months later.

Next Articles in This Series

Part 2: Stop Fetching Data Inside useEffect
Part 3: Stop Syncing Props Into State
Part 4: Event handlers are usually the better place for side effect
Part 5: Stop Using Effects for State Resets

Thanks for reading!! If you're looking for help with an existing project or need someone to solve a tricky frontend/backend issue, you can also find my freelance profiles through my Dev.to profile.

Angular performance optimization: change detection mistakes you should avoid

Alejandro — Fri, 03 Jul 2026 14:59:05 +0000

Angular apps can stay fast for a long time, until they don't. A lot of performance issues i've debugged had nothing to do with bundle size or server speed. The real problem was change detection doing way more work than it needed.
Here are some common mistakes.

1. Using the default strategy everywhere

Angular's default change detection is convenient, but it checks more often than many apps actually need. For bigger applications, this can become expensive fast. Using OnPush in the right places can reduce unnecessary updates a lot.

2. Calling functions directly in templates

This one is easy to miss. every detection cycle will execute those functions again. If the function is expensive or creates new objects, performance can drop quickly.
Computed values should usually live outside the template.

3. Mutating objects with OnPush

A common mistake. With OnPush, Angular watches references, not deep changes. Mutating and existing object can prevent updates from rendering. Immutable updates make this much more prefictable.

4. Rendering large lists without trackBy

Without trackBy, Angular may recreate DOM elements unnecessarily. On big lists, that gets expensive. A simple trackBy can save a lot of work.

Most Angular performance problems are not caused by Angular. They usually come from small patterns repeated across the app. And change detection is often where those patterns hurt the most.

How to optimize Angular bundle size for faster load times

Alejandro — Fri, 03 Jul 2026 14:45:07 +0000

One of the most common problems I see in Angular projects is bundle size growing way faster than expected.
At first, everything feels fine, then the app grows, dependencies pile up and suddenly your first load is slow, your Lighthouse score drops and users start noticing.
Here are some practical ways to optimize Angular bundle size.

1. Lazy load everything that makes sense

A lot of apps still ship too much code upfront.
Feature modules, admin panels, dashboards or rarely used routes should be lazy loaded so users only download what they need. This alone can make a huge difference.

2. Audit third-party dependencies

Some libraries look small but pull in a lot of extra code. Date libraries, UI kits and utility packages are usually the biggest offenders. Always check if you really need the whole package.

3. Whatch for duplicated imports

It's easy to accidentally import the same heavy dependency in multiple places. This can bloat the final bundle more than expected. Bundle analyzers help a lot here.

4. Use standalone components when possible

Angular's newer architecture can reduce unnecessary module overhead and improve tree-shaking

5. Optimize assets too

Images, fonts and icons are part of your load time. A perfectly optimized Js bundle can still feel slow if assets are heavy

Most Angular performance issues don't come from Angular itself. They come from how the app grows. Bundle size is one of the first places where that shows up.

Why API integrations break when your app scales

Alejandro — Fri, 03 Jul 2026 10:36:58 +0000

API integrations usually feel easy at the beginning. A few requests, some authentications, maybe a webhook or two and everything works fine. Then your app grows; more users, more traffic, more concurrent requests, more dependencies. That's when things start breaking.

1. Rate limits hit faster than expected

What worked for 50 users suddenly fails at 5000.
Without queues, batching or retry strategies, external APIs can quickly become bottlenecks.

2. Small delays become big problems

At scale, even small latency from third-party APIs adds up. One slow dependency can affect the whole user flow. This is why timeouts and fallback strategies matter.

3. Token management gets harder

More users means more sessions, more refreshes and more chances for auth flows to fail. Bad token rotation logic becomes a real problem fast.

4. Error handling becomes architecture

At small scale, you can fix things manually. At bigger scale, every failure needs to be predictable. Logging, monitoring and graceful recovery stop being optional. Scaling an app doesn't just expose performance issues. It exposes weak integrations. An most teams realize it later than they should.

Building reliable API integrations in modern web application

Alejandro — Fri, 03 Jul 2026 10:16:55 +0000

Modern applications depend on APIs more than ever.
Payments, authentication, notifications, analytics, CRMs... most products today rely on multiple third-party services to function properly. Connecting them is usually the easy part.
Making them reliable is where things get difficult.
A lot of API integrations work perfectly during development, but start failing once real users, real traffic and edge cases show up.
Here are some of the most common problemns I keep seeing.

1. Third-party failures are normal

External APIs fail. Timeouts happen. Servers go down. Responses get delayed. If your app assumes every request will succeed, it will eventually break. Retries, fallbacks and proper error handling should be part of the architecture from day one.

2. Authentication gets messy fast

Expired tokens, refresh logic, invalid sessions and revoked credentials create a lot of hidden problems.
A secure auth flows is not just about getting a token. It's about handling the full lifecycle correctly.

3. APIs change over time

Response structures evolve. Fields get renamed, removed or changed.
Without validation and version control, even small changes can break critical features.

4. Rate limits become real at scale

What works with 10 users may fail with 10000. Batching, queues and backoff strategies become necessary much earlier than most teams expect.