When to Skip effect() in Angular and What You Should Use Instead

Ahmed Khan — Wed, 23 Jul 2025 15:01:23 +0000

Angular’s effect() function is a powerful tool — but like any powerful tool, it can be misused. One key rule to remember is this:

Only use effects when you need to do something outside the template that can’t be done with standard data binding.

Keep Angular’s Auto-Tracking in Mind

One of the important things to understand about effect() is that Angular uses implicit tracking — meaning signals accessed within an effect are automatically tracked, even if they’re buried inside called methods.

Take this example:

effect(() => {
  this.logError();
});

logError(): void {
  const error = this.error();
  if (error) {
    console.error(error);
  }
}

Even though error() isn’t directly referenced in the effect callback, Angular tracks it because it’s used inside logError().

This behavior shows how tightly coupled effects are to rendering. Any signals accessed during rendering (directly or indirectly) are tracked, and when they change, Angular re-runs the effect.

🚫 When Not to Use Effects

Angular’s own documentation clearly advises against using effects to propagate state. Here’s why:

You can easily end up in circular update situations.
Auto-tracking might lead to unpredictable side effects that are hard to debug.
Effects lean toward imperative code, which undermines the declarative style of reactive programming.
In general, if you’re using effects to update signals or drive state logic, you’re probably reaching for the wrong tool.

Also, keep in mind: Signals are glitch-free. If you update a signal multiple times in one synchronous execution, only the last update is used. This is great for rendering — but terrible for representing real-time events or sequential actions.

✅ Legit Uses of effect()

Besides rendering-related use cases, effects also power reactive helpers behind the scenes.

For example:

toObservable() in Angular
rxMethod() in the NgRx Signal Store
Utilities from libraries like ngxtension by Chau Tran and Enea Jahollari
These tools use effect() under the hood to bridge signals with other reactive systems, especially RxJS.

So, How Should You React to Signal Changes?
When you want to perform actions based on changes in signals, here are some clean alternatives:

1. Use computed()

If you can derive the new value from other signals synchronously — this is the most declarative and idiomatic approach.

2. React to Events, Not Signals

Instead of reacting to a signal change, respond to the event that caused the change. This avoids weird auto-tracking issues.

3. Leverage RxJS

In many cases, RxJS is a better fit for complex reactivity. You can convert signals to observables (and back) using toObservable() and toSignal(). RxJS’s operators like switchMap() are also great for handling things like overlapping HTTP requests without race conditions.

4. Use Reactive Helpers

If you’re using Signal Stores or reactive libraries, take advantage of utilities like rxMethod() or deriveAsync().

Example: rxMethod in Signal Store
Here’s a minimal example of how you can use rxMethod() to load data reactively:

export const DessertDetailStore = signalStore(
  { providedIn: 'root' },
  withState({
    dessert: initDessert,
    loading: false,
  }),
  withMethods((store, dessertService = inject(DessertService)) => ({
    rxLoad: rxMethod<number>(
      pipe(
        tap(() => patchState(store, { loading: true })),
        switchMap((id) => dessertService.findById(id)),
        tap((dessert) => patchState(store, { dessert, loading: false }))
      )
    ),
  }))
);

Final Thoughts

Think of effect() as a last resort: use it only when you can’t achieve your goal with bindings, computed, or reactive patterns. Misusing it can make your code harder to reason about and more prone to bugs.

Instead, lean into RxJS, computed signals, and event-based logic for most scenarios. Tools like rxMethod() offer a sweet spot between Signals and RxJS, giving you the best of both worlds.

Let me know if you’d like help converting existing effect-heavy code into a cleaner reactive approach!

Understanding linkedSignal vs computed in Angular Signals

Ahmed Khan — Wed, 23 Jul 2025 14:56:12 +0000

While exploring Angular’s Signals system, I came across something that initially felt a bit redundant — linkedSignal. At first glance, it seems like you could just use computed() to handle state that depends on other signals. For example:

const shippingOptions = signal(['Ground', 'Air', 'Sea']);
const selectedOption = computed(() => shippingOptions()[0]);

This works fine if all you need is a reactive read of the first shipping option. But here’s where linkedSignal offers more power.

The Key Difference: Writability

What sets linkedSignal apart is that it’s writable, whereas computed() is read-only. That means with linkedSignal, you can derive state reactively like computed, and update it locally when needed.

For example:

const selectedOption = linkedSignal(() => shippingOptions()[0]);
selectedOption.set('Air'); // You can override it manually

This is useful when you want something to default to a derived value, but still let the user (or component logic) update it manually afterward.

Handling Previous State

Another benefit of linkedSignal is access to the previous value during computation. You can do things like:

const selectedOption = linkedSignal({
  source: shippingOptions,
  compute: (newValue, oldValue) => {
    // maybe preserve selection if still valid
    return newValue.includes(oldValue) ? oldValue : newValue[0];
  }
});

This kind of logic isn’t possible with computed(), which doesn’t track previous values in the same way.

When to Prefer linkedSignal

Use linkedSignal when:

You want a derived default value, but still need the flexibility to update it locally.
You’re working with inputs or external signals but want to maintain a local copy that can be overridden internally.
You need access to the previous state during recalculations.
In contrast, computed() is perfect when your signal is purely reactive and read-only, with no need to write back or override.

TL;DR

computed = readonly reactive value
linkedSignal = reactive default + writable override + previous value access

Use linkedSignal when you want the best of both worlds — reactive derivation and local control.

Let me know if you want to see a working example in a real component!

DEV Community: Ahmed Khan