각도 신호 및 효과

Version coverage

• signal(), computed(), effect(), toSignal(), toObservable() — stable since Angular 17 (developer preview in Angular 16)
• Effect onCleanup — stable since Angular 17
• Zoneless mode — stable since Angular 18, default since Angular 21

A signal is a reactive value container. When a signal’s value changes, Angular knows exactly which parts of the UI depend on it and updates only those parts — no full component scan needed.

1. Writable signals

Create a signal with signal(), passing the initial value. Read it by calling it like a function. Update it with set() or update().

import { signal } from '@angular/core';

export class CounterComponent {
  count = signal(0);

  increment() {
    this.count.update(c => c + 1); // derive next value from current
  }

  reset() {
    this.count.set(0); // set an explicit value
  }
}

Enter fullscreen mode Exit fullscreen mode

set() replaces the value. update() receives the current value and returns the next one.

2. Computed signals

computed() creates a read-only signal whose value is derived from other signals. Angular evaluates the derivation lazily (only when first read) and caches the result. When any dependency signal changes, the cached value is invalidated and recalculated on the next read.

import { signal, computed } from '@angular/core';

export class CartComponent {
  items = signal<{ price: number }[]>([]);
  total = computed(() => this.items().reduce((sum, item) => sum + item.price, 0));
}

Enter fullscreen mode Exit fullscreen mode

total always reflects the current sum of items. You never call .set() on it — Angular manages it.

3. Reading signals in templates

In a template, you read a signal by calling it as a function. Angular automatically tracks every signal called during template rendering and re-renders the component whenever any of those signals change.

<!-- counter.html -->
<p>Count: {{ count() }}</p>
<p>Total: {{ total() }}</p>
<button (click)="increment()">+1</button>

Enter fullscreen mode Exit fullscreen mode

There is no async pipe, no subscription, and no manual change detection call needed. Angular handles all of it.

4. Why you don’t “subscribe” to signals in the component class

Reading a signal in the component class (outside a reactive context) just returns the current value at that instant — it does not set up a reactive dependency. The read is synchronous and stateless.

ngOnInit() {
  const current = this.count(); // reads the value once — no subscription
  console.log(current);         // this will NOT re-run when count changes
}

Enter fullscreen mode Exit fullscreen mode

This is intentional. Signals are not Observables. There is no .subscribe() method. If you need to react to signal changes in the class — for example to trigger a side effect — use effect().

5. effect() — reacting to signal changes in the class

effect() creates a reactive side effect. Angular runs its callback immediately, tracks which signals are read inside it, and re-runs the callback automatically whenever any of those signals change.

Use effect() when you need to bridge a signal to a non-reactive API: logging, calling a third-party library, writing to localStorage, or manipulating the DOM directly.

import { signal, effect } from '@angular/core';

export class ThemeComponent {
  theme = signal<'light' | 'dark'>('light');

  constructor() {
    effect(() => {
      document.body.setAttribute('data-theme', this.theme()); // runs whenever theme changes
    });
  }
}

Enter fullscreen mode Exit fullscreen mode

effect() must be called in an injection context — the constructor or a field initializer. It cannot be called inside a lifecycle hook like ngOnInit.

Why not just use a getter or computed()? computed() is for deriving reactive state. effect() is for side effects — actions with no return value that touch something outside Angular’s reactivity system.

6. Effect cleanup

When an effect re-runs (because a dependency changed) or when the component is destroyed, you may need to clean up work from the previous run — cancel a timer, abort a fetch, remove a listener. The effect callback receives an optional onCleanup function for this purpose.

import { signal, effect } from '@angular/core';

export class PollingComponent {
  interval = signal(3000);

  constructor() {
    effect((onCleanup) => {
      const id = setInterval(() => {
        this.fetchData();
      }, this.interval()); // tracked — effect re-runs if interval changes

      onCleanup(() => {
        clearInterval(id); // called before the next run, or when the component is destroyed
      });
    });
  }

  private fetchData() { /* ... */ }
}

Enter fullscreen mode Exit fullscreen mode

The sequence when interval changes:

1. onCleanup callback runs → clearInterval(id) cancels the old timer
2. Effect re-runs → a new setInterval starts with the updated value

Without onCleanup, changing interval would start a new timer on each change while the old ones kept running.

7. Signals vs. Zone.js change detection

Before signals, Angular relied on Zone.js to detect when anything in the app might have changed. Zone.js monkey-patches browser APIs (setTimeout, event listeners, Promises, etc.) so Angular knows when to trigger a full change detection scan of the component tree.

Signals make this unnecessary. Because Angular knows exactly which signal each template reads, it can skip the full scan and update only the components that actually depend on a changed value. This is the foundation of Angular’s zoneless mode, which is stable from Angular 18+ and the default from Angular 21+. In zoneless mode, Zone.js is not loaded at all — change detection is driven entirely by signals.

In practice for new apps: prefer signals over @Input() / @Output() with plain class properties. Signals are what makes zoneless possible.

8. Signals and RxJS

Signals and RxJS solve overlapping but different problems. Angular provides an interop layer in @angular/core/rxjs-interop so you can use both together where needed.

When to use signals vs. RxJS

Use signals when… Use RxJS when… Holding and deriving UI state Handling async streams (HTTP, WebSocket, events) Driving template rendering Combining, debouncing, or transforming event sequences Replacing @Input() / @Output() You need operators like switchMap, debounceTime, combineLatest Working in a zoneless app Integrating with libraries that return Observables

The general pattern in modern Angular: use RxJS for data fetching and complex async logic, then convert the result to a signal for the template.

toSignal() — Observable → Signal

toSignal() subscribes to an Observable and exposes its latest value as a read-only signal. The subscription is automatically cleaned up when the component is destroyed.

import { toSignal } from '@angular/core/rxjs-interop';
import { HttpClient } from '@angular/common/http';

export class UsersComponent {
  private http = inject(HttpClient);

  users = toSignal(
    this.http.get<User[]>('/api/users'),
    { initialValue: [] }   // signal value before the Observable emits
  );
}

Enter fullscreen mode Exit fullscreen mode

@for (user of users(); track user.id) {
  <li>{{ user.name }}</li>
}

Enter fullscreen mode Exit fullscreen mode

initialValue sets the signal’s value before the Observable has emitted. Without it, the signal type includes undefined until the first emission.

toObservable() — Signal → Observable

toObservable() wraps a signal as an Observable. It emits the signal’s latest value after each change stabilises (not synchronously on every .set() call). Use it when you need to pipe a signal through RxJS operators.

import { toObservable } from '@angular/core/rxjs-interop';
import { debounceTime, switchMap } from 'rxjs/operators';

export class SearchComponent {
  query = signal('');

  results = toSignal(
    toObservable(this.query).pipe(
      debounceTime(300),
      switchMap(q => this.http.get<Result[]>(`/api/search?q=${q}`))
    ),
    { initialValue: [] }
  );
}

Enter fullscreen mode Exit fullscreen mode

This pattern — toObservable → RxJS pipeline → toSignal — is the idiomatic way to do debounced search or any async transformation driven by a signal.

9. input(), model(), and output()

Angular 17+ introduced decorator-free alternatives to @Input(), @Output(), and two-way binding. Two of them are signals; one is not.

input() — read-only signal input (Angular 17.1+)

input() replaces @Input(). It returns an InputSignal — a read-only signal whose value is set by the parent. Because it is a signal, you can use it directly inside computed() and effect() without any extra wiring.

import { input, computed } from '@angular/core';

export class UserCardComponent {
  // optional with a default
  name = input('Anonymous');

  // required — throws at runtime if parent does not provide it
  userId = input.required<number>();

  // derived value reacts automatically when userId changes
  profileUrl = computed(() => `/users/${this.userId()}`);
}

Enter fullscreen mode Exit fullscreen mode

<!-- user-card.html — read signals with () just like any other signal -->
<h2>{{ name() }}</h2>
<a [href]="profileUrl()">Profile</a>

Enter fullscreen mode Exit fullscreen mode

Because name and profileUrl are signals, they must be called with () in the template. This is different from @Input() where you would write {{ name }} without parentheses. The () is what tells Angular to track the value reactively and re-render when it changes.

<!-- parent template -->
<app-user-card [userId]="42" [name]="'Alice'" />

Enter fullscreen mode Exit fullscreen mode

InputSignal is read-only — calling .set() or .update() on it is a compile error.

model() — writable signal for two-way binding (Angular 17.2+)

model() creates a ModelSignal, which is a writable signal that also acts as an input/output pair. The parent can bind to it with [()] syntax; the child can update it with .set() or .update() and the new value is automatically propagated back to the parent.

Under the hood, model() declares both an input named property and an output named propertyChange — the same convention used by @Input() + @Output() two-way binding, but without the boilerplate.

import { model } from '@angular/core';

export class RatingComponent {
  // writable signal — parent can read it, child can change it
  rating = model(0);

  increase() {
    this.rating.update(r => r + 1); // parent's bound variable updates automatically
  }
}

Enter fullscreen mode Exit fullscreen mode

<!-- rating.html — read with () like any writable signal -->
<p>Current rating: {{ rating() }}</p>
<button (click)="increase()">+</button>

Enter fullscreen mode Exit fullscreen mode

rating() reads the current value reactively. When increase() calls this.rating.update(), Angular updates both the child template and the parent’s bound variable in one step. Compare this to @Input() where you would write {{ rating }} without () and the parent’s variable would not update at all without a manual @Output() emit.

<!-- parent template -->
<app-rating [(rating)]="userRating" />
<p>Parent sees: {{ userRating }}</p>

Enter fullscreen mode Exit fullscreen mode

[(rating)] desugars to [rating]="userRating" (ratingChange)="userRating = $event" — exactly what you would write manually with @Input() + @Output(). The difference is that model() sets this up in one line, and this.rating is a real signal usable inside computed() and effect().

@Input() + @Output() model() Two-way binding syntax [(prop)] ✓ [(prop)] ✓ Value as signal No Yes — ModelSignal Writable from child Manual emit .set() / .update() Use in computed() No Yes

output() — decorator-free event emitter (Angular 17.3+)

output() replaces @Output() + EventEmitter. It is not a signal. It returns an OutputEmitterRef<T> which only has one method: .emit(). You cannot call this.myOutput() to read a value from it — it is a one-way notification channel, not a reactive value.

import { output } from '@angular/core';

export class SearchComponent {
  searched = output<string>(); // OutputEmitterRef<string> — not a signal

  onSearch(query: string) {
    this.searched.emit(query);
  }
}

Enter fullscreen mode Exit fullscreen mode

<!-- parent template — identical to @Output() usage -->
<app-search (searched)="handleSearch($event)" />

Enter fullscreen mode Exit fullscreen mode

output() belongs to the same decorator-free API family as input() and model(), but it has no connection to signal reactivity. It is included here for completeness.

input() model() output() Type returned InputSignal ModelSignal OutputEmitterRef Is a signal Yes (read-only) Yes (writable) No Direction Parent → Child Parent ↔ Child Child → Parent Usable in computed() / effect() Yes Yes No Replaces @Input() @Input() + @Output() pair @Output() + EventEmitter

10. Signals and effects compared to React

If you come from React, Angular signals and effects map closely to concepts you already know — but with two key structural differences: Angular tracks dependencies automatically (no dependency arrays), and a signal change only updates the parts of the template that read it, not the whole component.

useState vs signal()

Both hold reactive state. The API is slightly different:

// React
const [count, setCount] = useState(0);
setCount(5);                        // set a value
setCount(prev => prev + 1);         // derive from previous

Enter fullscreen mode Exit fullscreen mode

// Angular
count = signal(0);
this.count.set(5);                  // set a value
this.count.update(prev => prev + 1); // derive from previous

Enter fullscreen mode Exit fullscreen mode

Reading is the biggest visible difference. In React, count is a plain variable captured by the render closure. In Angular, count() is a function call — the () is what registers the reactive dependency.

React useState Angular signal() Read count count() Write (replace) setCount(val) count.set(val) Write (derive) setCount(prev => ...) count.update(prev => ...) On change Whole component re-renders Only signal-dependent DOM updates Stale closure risk Yes — closures capture old values No — count() always reads current value

useMemo vs computed()

Both derive a cached value from other state. The critical difference is that React requires you to list dependencies manually, while Angular tracks them automatically by observing which signals are called during the derivation.

// React — dependency array is manual and error-prone
const total = useMemo(
  () => items.reduce((sum, item) => sum + item.price, 0),
  [items]   // must be kept in sync by hand
);

Enter fullscreen mode Exit fullscreen mode

// Angular — no dependency array; Angular tracks items() automatically
total = computed(() => this.items().reduce((sum, item) => sum + item.price, 0));

Enter fullscreen mode Exit fullscreen mode

If you add a new signal inside the computed() body, Angular picks it up automatically. In React, forgetting to add a dependency to useMemo silently produces stale values.

useEffect vs effect()

Both run a side effect in response to state changes. Same automatic vs. manual dependency distinction applies.

// React — manual dependency array
useEffect(() => {
  document.body.setAttribute('data-theme', theme);
}, [theme]);   // must list every dependency

Enter fullscreen mode Exit fullscreen mode

// Angular — automatic tracking
effect(() => {
  document.body.setAttribute('data-theme', this.theme()); // theme() is tracked automatically
});

Enter fullscreen mode Exit fullscreen mode

Cleanup — return vs onCleanup

React’s cleanup is a return value from the effect callback. Angular’s is a parameter passed into it.

// React — return a cleanup function
useEffect(() => {
  const id = setInterval(() => fetch('/api/poll'), 3000);
  return () => clearInterval(id);   // runs before next effect or on unmount
}, []);

Enter fullscreen mode Exit fullscreen mode

// Angular — onCleanup parameter
effect((onCleanup) => {
  const id = setInterval(() => this.poll(), this.interval());
  onCleanup(() => clearInterval(id)); // runs before next effect or on destroy
});

Enter fullscreen mode Exit fullscreen mode

Both cleanup functions run at the same moments: before the effect re-runs due to a dependency change, and when the component is destroyed/unmounted.

Summary of differences

React Angular Dependency tracking Manual arrays ([dep1, dep2]) Automatic — reads inside the callback On state change Whole component re-renders Only the affected template nodes update Stale closure problem Yes — must manage carefully No — signals always read current value Derived state useMemo with dep array computed() — no array needed Side effects useEffect with dep array effect() — no array needed Cleanup Return a function onCleanup parameter Where effects can be called Top level of component only Constructor or field initializer

11. Summary

Signal Computed Effect RxJS Observable Purpose Holds reactive state Derives reactive state Side effects on signal change Async event/data streams Writable Yes (set, update) No N/A No (push-based) Reactive in template Yes — call as value() Yes — call as value() N/A Only via async pipe or toSignal() Reactive in class Only inside effect() or computed() Only inside effect() or computed() Yes — auto-tracks reads Yes — via .subscribe() Cleanup N/A N/A onCleanup callback unsubscribe() or takeUntilDestroyed Zoneless compatible Yes Yes Yes Yes, via toSignal()