resource, rxResource, and httpResource In short: Fetching data is the same seven problems in every app. Resources solve all seven, so you stop writing the same store over and over. The seven: track loading, track errors, cancel requests that are no longer wanted, fetch again when settings change, hold the current value, allow a manual refresh, and clean up on destroy. Every team writes a service to handle these. Every one is slightly different and slightly wrong. Resources arrived as an early version in v19, came in v20, and all became final in v22 . — the common case That is the whole feature. What you get without writing it: The request runs again whenever or changes. The old request is stopped when a new one replaces it, and only the newest reply is used — the stale-reply race is handled. , , , and are signals, so the template just reads them. Everything is cleaned up with the component. The small function you pass is the key idea. You do not call a method to fetch. You describe what the request is, in terms of signals. Same principle as : describe the connection, let Angular decide when to run it. The status values tells you more than a true/false loading flag, and one distinction really matters for how the screen feels: Status Meaning --- --- No request — your function returned nothing First load, no value yet Fetching again, old value still available Loaded successfully Failed The value was set by your own code versus is what lets you avoid the worst pattern in data screens: blanking everything to a spinner every time a filter changes. Fetching only when ready Return nothing from your function and no request is made — the resource sits at . This is how you say "do not fetch until we have what we need": No guard clauses, no around a subscribe. Not fetching is just a state the resource understands. Other response types, and checking the data And a option, which is the right place to check that the server sent what you expected: The resource's type then comes from the checker's output. This is a real improvement over 's type parameter, which was always just an unchecked promise about what the server sends. Setting the value yourself can be written to, which supports showing a change before the server confirms it: The status becomes , which is how you can tell the shown data is not confirmed. and is the specialised version. The general one takes any promise: You are given an — pass it to and cancelling works properly. takes an observable, for when you need operators in the middle: Note the names: these changed while the API was being finished — became , and became for . Older tutorials show the old names. What v22 added They became final. No more warnings, and a fixed leak in that caused slow memory growth in sessions creating many short-lived resources. Server rendering support. A resource loaded while rendering on the server is reused on the browser's first draw, with no second fetch and no flash. The old "load in a resolver, stash it, read it back" pattern is now just using normally. Building one resource from another. gives you the whole state as one value, and builds a new resource from it — so you can transform without fetching again: The filtered resource keeps the loading and error status of the original. Where resources do not fit They are built for reading data with settings that come from signals. They are the wrong shape for: Changes. A from a button click is an action, not data. Use and then . Live feeds. WebSockets are not request-and-reply. That stays RxJS. Sharing across components. A resource belongs to whoever created it. If several components need the same data fetched once, you still want a service — though it can hold the resource: One request no matter how many components read it, and the store is six lines instead of sixty. "But doesn't httpResource replace HttpClient?" It is built on — same interceptors, same settings. Removing would remove the thing runs on. The clean split: --- --- --- Shape Describing — "this data is that URL" Commanding — "go do this now" Triggered by Signals changing A user action Usual method , , Runs again Automatically Only when called The one-line test: could this run twice with no harm? Reading a list — yes, that is a resource. Charging a card — absolutely not. The mistake this prevents: Change while browsing and you have deleted a record nobody asked to delete. And "do resources replace state management libraries?" For server data — things that live on a server and are cached in the browser — largely yes, and that was most of what many stores held. For genuine screen state — a multi-step wizard, undo history — no. Separate the two, and a large part of many stores turns out to be server data that a resource handles in a few lines. The architect's view Every team writes a version of this service. It is worth comparing side by side, because the differences are structural rather than cosmetic. The hand-written version — a filterable list with loading and err…