I'm weighing `effect()` for loading data and managing state against `toObservable()` feeding an RxJS pipeline, and I want to give a nuanced, opinionated comparison. I'm starting to recall the key facts about signals and effects across recent Angular versions. I'm recalling that `effect()` is meant for syncing signal state with non-signal systems like logging, localStorage, analytics, or DOM and third-party libraries, and that Angular discourages using it to propagate state by setting other signals. Signal writes inside effects were blocked in Angular 16 through 18 without `allowSignalWrites`, and I think Angular 19 dropped that requirement, though the advice to avoid it still stands. I'm noting that in v19 the `allowSignalWrites` requirement was dropped, and that effects run asynchronously during change detection, with reads after an `await` left untracked. I'm also checking how `effect` cleanup and `toObservable` behave: it emits only the latest value, and tears down when its injection context is destroyed. I'm recalling that `resource` and `rxResource` arrived as experimental in Angular 19, and `httpResource` followed in 19.2. I'm trying to pin down whether they were promoted in Angular 20 or are still in developer preview there. I'm checking whether `resource` and `httpResource` graduated in Angular 20 or stayed experimental, and I'll hedge the answer to the version the user is on. I'm now getting to the practical rule of thumb: derived values should be `computed` or `linkedSignal`, which needs no effect or subscription at all. I also want to remember `takeUntilDestroyed` for any remaining subscriptions and the NgRx `rxMethod` for reactive side effects that need `switchMap`-style cancellation. Then I'll settle on the verdict: neither approach is a blanket answer for loading data. I'm now comparing the options for the second part: derived data is better served by `resource`, `rxResource`, `httpResource`, or a `toObservable` → `switchMap` → `toSignal` chain than by `effect`. An `effect` is for side effects outside Angular's reactive graph, while search-as-you-type and similar cases lean on RxJS operators like `debounceTime`, `switchMap`, and `catchError`, which is why I'd prefer those for loading data. I'm listing why a `toObservable` pipeline beats `effect` for loading: `switchMap` cancels stale requests, debounce and retry are built in, and errors stay inside the stream. Writing signals from inside effects hides the data flow and makes it harder to reason about, and effects are scheduled around change detection, so they aren't meant for orchestrating async work. I'm also noting that `toObservable` emits asynchronously and coalesces rapid changes into the latest value, which helps with debouncing but can trip up tests unless effects are flushed. I'm comparing the two patterns now: chaining `toObservable` into `switchMap` and then ending with `toSignal` is cleaner than subscribing and calling `set` by hand. I also want to remember that `toObservable` only emits after the effect flushes, and that in tests this means flushing effects or running change detection before asserting. I'm now sorting out the tiers: effect plus a manual set is the weakest for loading data, toObservable with subscribe and set is better, and the declarative toObservable-to-toSignal chain is best. I'm also listing where effect genuinely fits: syncing to storage, the URL, the title, or the document, driving imperative third-party APIs, logging, and simple synchronous side effects that wouldn't justify RxJS. I'm now going through the cases where `toObservable` fits better than `effect`: typeahead search that needs debounce and cancellation, master-detail views where fast selection changes can race, and pagination or filtering that combines several signals into one request. I'm now looking at the failure modes of `effect` for loading: if the user clicks through items quickly, responses can come back out of order and show the wrong one, which is why I'd need cleanup or a request token to guard against it. I also need to watch for reading signals inside the effect that it then writes, since that can loop or trigger unwanted reruns. I'm now checking the remaining pitfalls of `effect`: writing signals inside it is allowed since Angular 19 but still discouraged, since it tangles the data flow and can trigger extra change-detection passes. The first run waits for the first change-detection cycle, so the initial load is deferred but not broken, and effects can't be created outside an injection context. I'm checking whether effects run during SSR at all, since I believe regular `effect()` does run on the server while `afterRender` hooks don't. The open question is whether an HttpClient request started inside an effect would hold up server rendering, which depends on how pending tasks are tracked. I'm checking whether `resource` does its own SSR handling, since an HTTP request started in an effect is tracked by PendingTasks and so the server waits for it. I believe `resource` adds a pending task while it loads, which would make it the safer choice for server rendering. I'm checking whether HttpClient calls are already tracked for SSR stability, since that's the one case where the request would hold up server rendering. Raw `fetch` inside an effect would need `PendingTasks` to be waited on, so I'm weighing whether to mention that briefly or leave it out to keep the answer focused. I'm checking whether `HttpClient` already registers a pending task for SSR, since I half-remember that interceptor chain handling it. I'm not confident enough in the exact version or mechanism to lean on it, so I'll keep this point out of the answer and stay focused on the loading comparison. I'm checking how `toObservable` emits: it uses a ReplaySubject fed by an effect, so the first value arrives when that effect first runs during change detection rather than synchronously on subscribe. I'm also wondering whether it becomes a component-level effect when created inside a component's injection context, though that detail matters less here. I'm weighing signal-to-observable setups for the case where a signal change should cancel an in-flight request, and I'm noting that signals suit state rather than events. A refresh click is better handled with a method like `reload()` or a counter trigger, since setting the same value again won't re-run an effect. I'm recalling the Angular guidance on effects: they shouldn't be used to propagate state changes, since that risks ExpressionChangedAfterItHasBeenChecked errors, circular updates, and extra change-detection passes. Angular even blocks setting signals inside effects by default, and the recommended alternatives are `computed` for derived values and `linkedSignal` for derived-but-writable ones. I'm laying out the answer as a verdict first, then a comparison, then real scenarios with the pros and cons of each approach. I'm planning to show how a route-driven load goes wrong with an effect and how the `toObservable` and `switchMap` chain fixes the race. I'm now going through the case of polling or a WebSocket subscription that depends on a signal, which is another spot where an effect that tears down and rebuilds on each change could be handled more cleanly with RxJS. I'm settling on a set of concrete cases to compare: a room-based connection where a signal change should tear down the old one, form prefilling when an input changes, and saving on a button press, where the trigger is a command rather than state. For the first two I'm weighing whether `linkedSignal` or an effect fits better, and for the save action I'm leaning toward a plain method or an `exhaustMap` off a Subject instead of an effect. I'll keep it to around five or six scenarios so the answer stays readable. I'm working through a race-free loading setup, comparing an effect that calls HTTP directly against a `toObservable` and `switchMap` chain, since the effect version is the one that can show stale data on fast navigation. I'm looking at the `finally` handler in the fetch chain, which runs even after an abort and would flip `loading` back to false while the newer request is still in flight. I'm checking the race in the `finally` path: the aborted fetch still runs `finally` and sets `loading` to false while the newer request is still in flight. I'll point that out in a comment and then show the HttpClient version, where unsubscribing in `onCleanup` cancels the old request. I'm writing the HttpClient version now: the request gets subscribed inside the effect and unsubscribed in `onCleanup`, which cancels the old call when the id changes. Still, the loading flag gets tangled up in that teardown, so I'll check the ordering of `finalize` against the next run of the effect. I'm settling on the effect version that uses HttpClient with `onCleanup` to unsubscribe, since that ordering keeps the loading flag correct across re-runs. The fetch-with-abort version looks similar, but its `finally` fires after the new request has already started, so I'll mention that pitfall rather than show buggy code. I'm fixing the one remaining gap in the HttpClient version: if the request errors out, `complete` never fires, so `loading` would stay stuck at true. I'll set `loading` to false in the error handler too, and I'll note in a comment that writing signals inside the subscribe callback is fine here. I'm checking whether `set` and `update` create any dependency, and I'm concluding that writing a signal doesn't track anything, so `untracked` is only needed when reading other signals I don't want as triggers, like a `page()` or `filters()` signal. I'm settling on the effect version that wraps an HttpClient request, since unsubscribing in `onCleanup` keeps `loading` in the right order across re-runs. Signal writes don't create dependencies, so the `untracked` wrapper is only needed when reading other signals. Writing the effect version with HttpClient now, and each request gets unsubscribed in `onCleanup` so the old call is cancelled when the id changes. I'm comparing the `toObservable` route, where I add a `tap` to flip the loading and error flags, then use `switchMap` for the request and a `catchError` to record failures. Loading can stay stuck on error here unless I clear it there too, which makes this version feel more imperative than I'd like. I'm about to move on to a fully declarative pattern with `toSignal`. Writing the `toSignal` state wrapper now, with the `switchMap` and a `LoadState` union for loading, loaded, and error. Still writing the `rxResource` example... Still working through the Angular 20 API naming, comparing how `rxResource` renamed its parameters across versions. Checking the API naming for `rxResource` in v20: the `stream` option takes the params and returns an observable, which is what I'm trying to confirm against the docs. Still working through the API naming for `resource` and `rxResource`, which changed between v19 and v20, and I'll add a note to check the version. I'm laying out the decision guide now: `computed` for derived sync values, `linkedSignal` for writable state that resets from another signal, and an async read driven by signals going to `httpResource`, `resource`, `rxResource`, or a `toObservable` to `switchMap` to `toSignal` chain. RxJS through `toObservable` is the right tool when I need debounce, retry, polling, websockets, stream combining, or cancellation, while `effect` is for side effects outside Angular's reactive world like storage, the DOM, third-party libraries, or logging. I'm settling on the verdict that for loading data, a `toObservable` chain ending in `toSignal` or a resource API beats an effect, since effects are really for side effects rather than data flow. Still, plain `subscribe` plus `set` isn't ideal either, so I'd prefer to end the pipeline with `toSignal`. On the effect side, its appeal is that it needs little ceremony, tracks its dependencies automatically, and suits sync work like localStorage, logging, analytics, or a third-party library. I'm listing the pros and cons of `effect()`: its low ceremony and automatic dependency tracking on one side, and the manual handling of async work, cancellation, and loading state on the other. I'm listing the cons of `toObservable`, which include the need to know RxJS well, and I'm about to pick up where that list stops. I'm now listing the cons of `toObservable`: it's a steeper learning curve, emissions are async and coalesced so `.subscribe` won't fire synchronously, and it needs an injection context. I'm laying out the scenarios as a table now: route-param loads go to a resource API or a `toObservable` and `switchMap` chain, search-as-you-type needs debounce and cancellation, and persisting theme or cart state to localStorage is a plain effect. The table is where I'm mapping each case to its better tool and the reason behind it. I'm listing a few situations where an effect is the right call anyway, like showing a toast when `error()` becomes non-null. I'm also considering whether writing signals inside an effect is ever acceptable, and I'm leaning toward yes for edge cases where no declarative alternative exists, such as syncing non-Angular external state. I'm noting that `toObservable` might have a pitfall inside a constructor when subscribing without `takeUntilDestroyed`, and I'm checking whether its observable completes when the injection context is destroyed. Checking the source of `toObservable` now: it completes its subject when the injection context is destroyed, so the source side doesn't leak. Downstream, `switchMap` still waits for any inner request to finish before completing, which is fine in practice, though `takeUntilDestroyed()` is still worth adding when the pipeline has other long-lived sources like an interval. I'm noting that `toObservable` completes on destroy, so a plain subscribe won't leak from the source side, though `takeUntilDestroyed` is still worth it if the pipeline merges long-lived streams. The more useful point is that `toObservable` runs on an effect internally, so the real difference between the two approaches is where the async logic lives: an imperative effect body versus a composable stream with clear cancellation rules. Both depend on effect scheduling; the gap is in how the work is orchestrated. I'm also weighing where the Angular team is heading, with the `resource` API positioned as the default for async data that feeds signals. I'm settling on the point that the Angular docs themselves treat effects as a last resort, since they're rarely needed in most application code and derived state belongs in `computed`. I'll avoid putting specific attributions on community figures and stick to what the official docs actually say about use cases. I'm noting a few optional extras: that `rxMethod` in NgRx SignalStore is the built-in way to run an RxJS pipeline off signals, and that the `TestBed` flushing API for effects is changing in v20. I'm noting that the pure-function route gives a real testing advantage, since the RxJS pipeline can be checked with marbles and `TestScheduler` without spinning up Angular at all. I'm settling on a plan for the answer: a short verdict, then a mental model, then each option with its code, pros, cons, and where it fits, followed by a scenario breakdown, a decision path, and a few rules of thumb, all kept to a moderate length. I'm going through the correctness of my claims now: `toObservable` emits asynchronously because it's driven by an effect, and it coalesces rapid changes so only the latest stable value reaches subscribers. I also want to confirm that effects can't track signals read after an `await`, and that the `allowSignalWrites` requirement is gone as of Angular 19. I'm double-checking the Angular 19 detail: the `allowSignalWrites` flag got deprecated because writes inside effects are allowed by default now. Before that, you had to opt in explicitly, but the guidance on when to write signals stays the same. Next I'm checking the Angular version notes: `TestBed.flushEffects()` looks deprecated in v20 in favor of `TestBed.tick()`, so I'll keep the testing advice version-neutral and just say tests need to flush effects. I also want to flag that the `resource` APIs, including `httpResource`, are still experimental around v19 and v20, so I should hedge that. I'm checking the remaining version details: `linkedSignal` was a developer preview in v19 and became stable in v20. I'm also confirming that `toObservable` on an `input.required` field in a component field initializer is safe, since its effect only runs after inputs are set, so there's no early-read error. Still writing the example, now with a small `Load` union type for loading, loaded, and error states. Still writing the typed `Load` example, now with a `startWith` for the loading state and a `computed` that pulls out the loaded user. Still working through the typed loading example, and I'm weighing whether the `startWith` and union typing are worth spelling out in full. I'm inclined to trim it down to the essential `switchMap` pattern and mention loading and error handling in words, since `rxResource` or `httpResource` would package those hard parts anyway. I'm sketching the second option now: `toObservable` feeding a `switchMap` and landing in `toSignal`, with a debounced search as the example. I'll mention that loading and error states still need handling, either with a small `Load` type or with the resource API that packages them. Still outlining the code samples now: an effect-based loader for entities, the `toObservable` version of the same, a typeahead search where RxJS clearly shines, and a localStorage sync that fits an effect. I'm planning to close with the one-line resource equivalent. I'm planning a side-by-side comparison of one master-detail scenario, loading a user when `userId` changes, using an effect, a `toObservable` pipeline, and `httpResource`, then adding a typeahead snippet and an effect example. I also want to check when effect-based loading would actually be the right call, and I suspect it's rarely the best choice, since the `resource` API usually covers those cases. I'm now thinking about where the "use resource instead" advice fits, and whether to mention the other options like loading in `ngOnInit`, a route resolver, NgRx SignalStore with `rxMethod`. I want to keep that aside brief. The core principle I'm settling on is one-way flow: sources feed `computed` or `linkedSignal`, which feed the view. An effect that writes signals creates a second, hidden path, much like the React lesson that you might not need an effect. Now I'm drafting the short answer: `toObservable` piped through RxJS and ending in `toSignal` is the better fit for loading data from signal changes, and `resource` variants are better still where available, with `effect` kept for side effects outside the reactive graph. I'm now laying out the two approaches with their pros and cons, then a table of real scenarios, a note on the resource API, and a decision guide to close. I'm now writing out the failure modes of effects: race conditions unless I clean up, dependencies that get picked up by accident from helper calls, state written from effects creating hidden loops, no built-in operators for debounce or retry, and flag bookkeeping that can leave loading stuck. For `toObservable`, I'm starting on its own caveats, beginning with the fact that it's async and coalesces values, so it isn't meant for raw events. Now I'm looking at error handling in the `toObservable` pipeline: an error inside the outer stream ends it for good, so the `catchError` has to sit inside the `switchMap`, on the inner request. Without that, one failed call stops all future signal changes from reaching the result, which is a common RxJS trap that effects don't have, since an error in one effect run leaves the effect itself alive. I'm now laying out the rows of a scenario table, starting with a product details page where the route id changes and a fast click on "next" could let an earlier response overwrite a later one, so that request needs cancelling. I'm starting to fill in a search or autocomplete row as well. I'm filling in the rest of the scenario table now: a debounced typeahead with `distinctUntilChanged` and `switchMap`, a filtered data grid built from a `computed` params object, a dashboard that polls on a timer and restarts when the date range changes, and a chat room tied to `roomId`. I'm laying out the last rows of the scenario table: a WebSocket connection keyed to `roomId` that closes on switch, localStorage persistence and chart feeds as `effect` cases, and a toast or analytics call on a state change. I'm also noting that editable form state tied to the selected entity fits `linkedSignal`, and that save or delete commands are plain methods. Next I'm filling in the table with its last rows and trimming it to eight so it stays scannable. Then I'm adding a short snippet showing effects used correctly, one-way and without writing state back, and starting a typeahead example built on `toObservable` and `toSignal`. Still writing the typeahead and entity-loading examples... Still writing the typing for the entity state, checking that the union narrows cleanly on `status`. Now I'm checking the user's `load` function against the error state, and I want the resource version to make that shorter. The boilerplate here is the reason `resource()` exists, so I'll note that as the main drawback of the hand-rolled approach. Still writing the `httpResource` version of the user loader... Next I'm settling on the principle that one-way data flow is cleaner, so `route.paramMap` or `form.valueChanges` can stay in RxJS until the end and only then convert with `toSignal`, rather than round-tripping through signals. I'm settling on the verdict: `toObservable` piped through RxJS and finished with `toSignal` beats `effect` for signal-driven fetching, and the `resource` family beats both when it's available. I'm keeping `effect` reserved for side effects like localStorage, DOM work, charts, logging, and toasts, rather than data flow. I'm laying out the pros and cons of the `effect` approach for loading: it avoids RxJS and tracks dependencies automatically, but races, stale flags, and hidden data flow are all on me to handle. I'm laying out the drawbacks of effects, like testing and how signal writes hide the data flow. Next is `toObservable`, where I'm listing its strengths: operators like switchMap and retry, errors and loading handled as data, and automatic cleanup. Its costs are RxJS knowledge, async and coalesced updates, extra boilerplate, and the risk that an uncaught error ends the stream. I'm adding a closing recommendation as a bullet list of decisions, ordered by preference. I also want to flag one more `effect` pitfall: any signal read synchronously inside it, even through a helper method, becomes a trigger, so a `page()` read I only meant for building a URL could cause a surprise refetch. Now I'm weighing a few concerns about the effect approach: any signal read inside it, even through a helper, becomes a trigger, so a `page()` read meant only for building a URL could cause a refetch I didn't intend. I'm also settling the closing notes, including a reminder that the official docs advise against using effects to propagate state changes. I'm checking whether `toSignal` was still in developer preview in v20, since I remember the blog post promoting `effect`, `linkedSignal` and `toSignal` to stable but I'm not fully sure of the exact list. I'm weighing whether to note that the stability status of `toObservable` in v20 is unclear to me, so I'll avoid stating it as fact and instead just advise checking the stability of `resource` and `httpResource` for the version in use. I'm noting that a `toObservable` pipeline can run a tick behind the signal it feeds, so a loading state shows up after the effect flush, usually within the same change-detection pass. I'm also considering a manual reload trigger: a `reload` signal combined with the params via RxJS, or `.reload()` on a resource. I'm writing a small `UserDetail` component example that uses `effect` to react to the `userId` input, setting loading and error state along the way, and I'm checking which Angular versions need the `allowSignalWrites` flag. Still writing the `UserDetail` effect, handling the HTTP call, the success and error branches, and cleaning up the subscription when the input changes. I'm checking the `effect` version of the loader for runtime problems. Writing signals from inside the subscription is fine, since no reactive context is active there. Before v19, the synchronous `loading.set(true)` in the effect body needs `allowSignalWrites: true`, and I'll note that in a comment. Still writing the toObservable version of the user loader... Still writing the `httpResource` version and a `linkedSignal` draft example... I'm writing the short answer now: `toObservable` piped through RxJS and finished with `toSignal` is the better choice for loading data from signals, with `resource` variants better still where available, and `effect` kept for side effects. I'm weighing a verdict on the orchestration question: `toObservable` is itself effect-based, so the real difference is where the async logic lives, in a hand-managed effect body or in a declarative stream. I'm sketching the comparison table now, with `effect` and `toObservable` as the two columns and criteria like cancellation, loading/error state, boilerplate, and testing as the rows. I'm laying out the comparison table, with `effect` and `toObservable` as columns. The rows so far cover cancelling stale requests, where `effect` needs manual cleanup and `toObservable` uses `switchMap`, and debouncing, retries and polling, which are hand-rolled timers in one case and operators in the other. I'm finishing the comparison table with the failure-mode row, where an error not caught inside `switchMap` kills the stream. Then I'll add the real-life scenarios table, a "How I'd decide" ordered list, and a closing note on the difference between effects and RxJS/resource. I'm adding two last notes: that an Observable source like route params or `valueChanges` can skip the signal round trip, and that signals coalesce updates, so events like "refresh clicked" belong in a Subject or a `reload()` call instead. I'm checking the injection context for `toSignal` in the field initializer, and confirming that the `input.required` read is safe because the effect's first run happens after inputs are set. I'm also looking at how `startWith` ahead of `switchMap` emits loading first, and noting that each id change resets the user state while the new request is pending. I'm adding a small `effect` example for two side effects: persisting the theme to localStorage, and showing a toast when loading fails. The toast call could read signals internally, so I'll wrap it in `untracked` to keep those reads from becoming triggers. Still writing the `untracked` wrapper example for the toast call, keeping the one tracked read on the error signal. Now I'm drafting the closing note: the docs advise against using effects to propagate state, since that can cause change detection errors or circular updates, and computed signals are the better fit for state that depends on other state. I'm laying out the closing recommendations now: `toObservable` with RxJS and `toSignal` for loading data, `resource` variants where available, and `effect` kept for side effects like storage and notifications. Still writing the code examples, and I'm comparing the three approaches, effect, toObservable, and httpResource, on what each one leaves to the developer. I'm laying out the last sections now: a list of which tool to reach for in common situations, and a closing bottom line. I'm settling on the final answer's layout now, keeping the tables narrow so they stay readable. ## Short answer - **For loading data when a signal changes, `toObservable` + RxJS (ending in `toSignal`) is better than `effect`.** If your Angular version has them, `resource()`, `httpResource()` and `rxResource()` beat both, because they package exactly that pattern. - **Use `effect` for side effects only:** localStorage, DOM, charts, logging, toasts. The Angular docs say not to use effects to propagate state. - **Why:** `toObservable` is built on an effect internally, so scheduling is the same. The real difference is where the async orchestration lives. In an effect you hand-write cancellation, race handling and loading/error flags. In a stream you declare them with `switchMap`, `debounceTime`, `retry` and `catchError`. - **Caveat:** `toObservable(x).subscribe(v => this.y.set(v))` is only a half step up, because it is still "listen and write state". Finish with `toSignal` when you can. ## Same job, three ways: "load a user when `userId` changes" **A) effect** ```ts userId = input.required(); user = signal(null); loading = signal(false); error = signal(null); constructor() { effect((onCleanup) => { const id = this.userId(); // intended trigger this.loading.set(true); // before v19 this needed allowSignalWrites: true this.error.set(null); const sub = this.http.get(`/api/users/${id}`).subscribe({ next: u => { this.user.set(u); this.loading.set(false); }, error: e => { this.error.set(e); this.loading.set(false); }, }); onCleanup(() => sub.unsubscribe()); // you hand-rolled switchMap }); } ``` **B) toObservable → switchMap → toSignal** ```ts private state = toSignal( toObservable(this.userId).pipe( switchMap(id => this.http.get(`/api/users/${id}`).pipe( map(data => ({ status: 'loaded' as const, data })), catchError(error => of({ status: 'error' as const, error })), // catch INSIDE switchMap startWith({ status: 'loading' as const }), )), ), { initialValue: { status: 'loading' as const } }, ); user = computed(() => { const s = this.state(); return s.status === 'loaded' ? s.data : null; }); loading = computed(() => this.state().status === 'loading'); ``` **C) resource** ```ts user = httpResource(() => `/api/users/${this.userId()}`); // user.value(), user.isLoading(), user.error(), user.reload() ``` The `resource` APIs were still experimental or developer preview in v19 and v20, and the option names changed between those versions (`request` became `params`). Check your version before relying on them. The boilerplate in B is the reason C exists. ## Pros and cons | | `effect` + set signals | `toObservable` + RxJS | |---|---|---| | Cancel stale requests | Manual (`onCleanup`) | `switchMap` | | Debounce, retry, polling, combining sources | Hand-rolled timers | Operators | | Loading/error/data consistency | Several manual `set()` calls, so "stuck loading" bugs are easy | One stream produces one state | | Dependency tracking | Automatic, but easy to track too much or too little | You choose the sources explicitly | | Learning curve | Low | Needs RxJS | | Trivial sync side effects | Ideal | Overkill | | Testing | Must flush effects, and logic is buried in the body | Extract the pipeline and test it with marbles | | Typical failure | Silent races, stale data, accidental loops | A dead stream if an error escapes the inner observable | **Effect gotchas** - Any signal read synchronously in the effect becomes a trigger, even inside a helper method. Use `untracked()`. - Anything read after an `await` or inside a callback is not tracked. - Writing signals from effects creates hidden data flow, and it is easy to build loops. Prefer `computed` or `linkedSignal`. **toObservable gotchas** - Emissions are asynchronous and coalesced, so the first value arrives after the first change detection pass. If you set a signal three times in a row, only the last value emits. - Setting a signal to the same value emits nothing, so "refresh" needs a trigger or `resource.reload()`. - An error that escapes the outer pipeline kills the stream, so put `catchError` inside `switchMap`. `toSignal` also rethrows stream errors when you read it. - It needs an injection context, or you must pass `{ injector }`. ## Real-life scenarios | Scenario | Best tool | Why | |---|---|---| | Product page: route `id` → fetch, and the user clicks "next" quickly | `resource`, or `toObservable → switchMap` | The old request must be cancelled, or a slow response for product 1 overwrites product 3 | | Autocomplete / search box | `toObservable → debounceTime → distinctUntilChanged → switchMap` | Debounce, dedupe and cancel are one-liners | | Grid with filters, sort and page | One `computed` params signal → `resource` or `toObservable` | One request per coalesced change | | Dashboard polling every 10s for the selected range | `toObservable(range) → switchMap(r => timer(0, 10_000).pipe(switchMap(() => api.get(r))))` | Polling restarts and cancels when the range changes | | Chat: connect a WebSocket for `roomId` | `toObservable(roomId) → switchMap(socket$)` | The old socket closes automatically on switch | | Persist theme/cart/column layout | `effect` | Pure side effect, nothing to compose | | Push signal data into a chart or map library | `effect` (`afterRenderEffect` for DOM work) | Imperative API outside Angular | | Toast on error, analytics on login | `effect` | One-way notification, no state written back | | Edit form that resets when the selected entity changes | `linkedSignal` | Writable derived state, no effect needed | | Save/Delete button | Plain method (`exhaustMap` if needed) | A command, not a reaction to state | Typeahead: ```ts query = signal(''); results = toSignal( toObservable(this.query).pipe( debounceTime(300), distinctUntilChanged(), switchMap(q => q.length < 2 ? of([]) : this.api.search(q).pipe(catchError(() => of([])))), ), { initialValue: [] as Product[] }, ); ``` An effect used well: ```ts effect(() => localStorage.setItem('theme', this.theme())); effect(() => { const err = this.user.error(); // the only tracked read if (err) untracked(() => this.toast.error('Could not load user')); }); ``` ## How I'd choose 1. **Derived value:** use `computed`. For writable state that resets when a source changes, use `linkedSignal`. 2. **Async read driven by signals:** use the `resource` family. If you need operators like debounce, retry or polling, use `toObservable → switchMap → toSignal`. 3. **Source already an Observable** (route params, `valueChanges`, sockets): stay in RxJS and call `toSignal` at the end. Don't convert to a signal and back. 4. **Leaving the signal world** (storage, DOM, third-party libs, logging, toasts): use `effect`. 5. **User commands:** use a plain method. Signals model state, not events, so don't use them to trigger actions. Effects are the escape hatch from signals into the outside world. RxJS or `resource` is how you describe async data flow inside your app.

Test of knowledge and good practise