An Angular app sets an effectiveTheme signal from an effect() reading prefersDark() and theme(); it causes extra change detection passes and once looped. Why, and what replaces it?

## The code under suspicion ```ts readonly theme = signal<'light' | 'dark' | 'system'>('system'); readonly prefersDark = signal(false); readonly effectiveTheme = signal<'light' | 'dark'>('light'); constructor() { effect(() => { const next = this.theme() === 'system' ? (this.prefersDark() ? 'dark' : 'light') : this.theme(); this.effectiveTheme.set(next); }); } ``` It looks harmless, and since **v19** it even compiles and runs without warnings: signal writes inside effects are allowed by default, and the `allowSignalWrites` option that used to gate them is deprecated and ignored. The bugs come from timing, not permission. ## Why it costs extra change detection Walk one change through change detection: 1. The user picks `'dark'`; `theme` changes. Readers of `theme` are marked dirty, and so is the effect. 2. Change detection runs. The effect runs at its scheduled point and **writes** `effectiveTheme`. 3. That write marks every reader of `effectiveTheme` dirty. Readers checked later in the same pass simply see the new value. 4. Any reader that was **already checked** in this pass, such as a header component higher in the tree, has to be checked again, so Angular runs another pass. Anything that read `effectiveTheme` between the `theme` change and the effect run saw a stale combination. With a `computed()`, the value is simply correct whenever it is read. There is no intermediate state and no second write. ## Why it can loop An effect re-runs when a signal it read changes, **including during its own run**: Angular re-runs such an effect before moving on with change detection. That is fine if the second run writes the same value, because the signal's equality check stops the cycle. It loops when: - the effect reads the signal it writes and always produces a different value, such as appending or incrementing; - two effects write each other's inputs, or an effect writes something that feeds its own input through a chain; - the written value is a fresh object each time, so `Object.is` never reports it as equal. The symptom is a frozen tab or a change detection error rather than a clear message, which makes this one of the costliest effect mistakes. ## What the guide says Angular's effect guide is blunt: - effects should be **the last API you reach for**; - avoid them **for propagation of state changes**, which "can result in `ExpressionChangedAfterItHasBeenChecked` errors, infinite circular updates, or unnecessary change detection cycles"; - if you are copying data from one signal to another with an effect, **move the source of truth** and use `computed()` or `linkedSignal()`. ## The replacements | Need | Use | Why | |---|---|---| | a value fully determined by other signals | `computed()` | pure, lazy, cached, no extra write | | derived by default but locally overridable | `linkedSignal()` | resets from its source, accepts `set()` | | loading async data from signal params | a resource API | handles loading state and cancellation | | pushing state to a non-signal API | `effect()` | the case effects exist for | | reacting to a user action | the event handler | the write happens where the intent is | For the theme: ```ts readonly effectiveTheme = computed(() => this.theme() === 'system' ? (this.prefersDark() ? 'dark' : 'light') : this.theme(), ); constructor() { effect(() => localStorage.setItem('app-theme', this.theme())); } ``` The effect that remains writes **out** of the signal graph, to storage, and writes no signal. ## When a write inside an effect is legitimate Writes are not banned, and some are reasonable: - recording the result of an imperative API back into a signal, such as a measured size; - resetting an unrelated piece of UI state as a genuine reaction to an external event; - bridging a non-signal source into signals where no dedicated API fits. Even then, check three things: the effect must not read what it writes, or must write a value that settles; the write must not be derivable; and wrapping incidental reads in `untracked()` should keep the dependency list to the signals that really should trigger it. ## Diagnosing it in a real app 1. Search for `.set(` and `.update(` inside `effect(` callbacks. 2. For each, ask whether the written value is a pure function of the signals read. If yes, it is a `computed()`. 3. For loops, look for an effect that reads the signal it writes, or two effects writing each other's inputs. 4. Confirm with Angular DevTools' signal graph, or by logging runs with a `debugName` on the effect.