DEV Community: flo-dmtx

`resource({ loadStrategy: 'whenTracked' })`: what should wake a lazy resource?

flo-dmtx — Wed, 05 Aug 2026 19:46:27 +0000

A few days ago, I proposed resource({ lazy: true }) for Angular: resources load eagerly by design, and I wanted one that waits until something actually looks at it. This is the follow-up, because the design changed: for the better, and for reasons worth writing down. The whole thing turns on a question that looks trivial and is not: a lazy resource waits. Waits for what, exactly?

Hypothesis 1: any read wakes it

That was v1's answer. Read value(), status(), hasValue(), from anywhere, and the loader fires. I picked that rule for two reasons, and they are solid. No template guard can deadlock, because @if (r.hasValue()) is itself a read. And composition works for free: resourceFromSnapshots, the composition API Angular documents, reads input.snapshot inside a linkedSignal computation. Since that read is a read like any other, wrapping a lazy resource just works.

Then a contributor, wartab, brought the best kind of pushback to the issue thread: a production implementation. Their team runs a userland lazy resource where plain reads do not trigger anything: only long-term interest counts, meaning a template or an effect; untracked never wakes anything; imperative code gets an explicit loadValue() that returns a promise. It works, in production, today.

So: two opposite rules, each backed by something real. Mine by composition, theirs by usage. When two contradictory answers both hold up under pressure, the question is usually cut along the wrong axis. Finding the right axis took two more iterations.

Hypothesis 2: give every intent its own method

The disagreement seemed to be about intent. Some reads mean "I need this data, go get it". Other reads just want to look at the current state without causing anything. v1 collapsed both into one rule; wartab's model collapsed them into another. So the next hypothesis: stop collapsing. If reads carry different intents, give each intent its own entry point.

That design looks like this: peek() reads the state and triggers nothing. toPromise() (wartab's loadValue(), which I adopted under a new name) asks for the value imperatively and waits for it. An option picks the trigger strategy, including one where the resource goes back to sleep when nobody watches it. Every intent gets a door. On paper, nothing is missing.

Building it is what broke it. The sleep-capable strategy kept producing states I could not defend. Wake the resource with a single read from an event handler: nobody is listening, so "the last watcher leaves" can never happen, so it never goes back to sleep. Awake forever, for a caller that got undefined back and will never hear anything more. toPromise() on that same strategy was almost comical: the promise resolves, and the value it just delivered is immediately thrown away, because nobody is still listening. And peek() needed guard after guard to avoid leaking internal states. Every method was an answer to a question that the model itself kept generating. When every edge case needs its own branch, the state model is wrong.

The Rx detour

The tension (what should wake a lazy resource) had been there from the very start. What I was missing was a way to state it in terms that already have answers. So I translated the design into RxJS, a model with a decade of production wear on exactly these questions.

The mapping is short. A resource is a hot observable: it runs whether or not anyone is watching. What my lazy option was trying to revive is the cold observable subscribed by the async pipe, the exact pattern from the first article: nothing runs until the template subscribes, and the subscription is what starts the work. Complete the equivalence with shareReplay (many readers, one execution, the latest value replayed to late arrivals) and it holds: a lazy resource is a cold, shared observable, and listening to it is subscribing to it.

Stated in those terms, two things became visible that I had not managed to see before.

First, refCount. A shared observable can reset when its subscriber count drops back to zero. Modern Rx spells it share({resetOnRefCountZero: true}). That is the moment wartab's model clicked into place for me. The feature their implementation was actually built around is the resource can return to idle, and that is refCount behavior, a named, well-understood thing. loadValue() was never the need; it is the consequence of an implementation choice. Once I could attach "going back to idle" to use cases I understood, the conversation stopped being about which reads should trigger and started being about lifecycle.

Second, subscriptions have callbacks, and a promise is not a stream. Waking a lazy resource is subscribing to it. A read inside a reactive context can genuinely subscribe: it leaves a listener behind, someone the load will actually serve. A read outside a reactive context cannot: it gets a value once, and there is no channel for anything later. Waking the resource for it serves nobody: the caller got undefined and will never be notified. That one distinction resolves the original tension: reads that can subscribe wake the resource; reads that cannot, photograph it. It also kills toPromise() on principle: wanting exactly one value out of a stream is the wrong primitive. The rare genuine need already composes from existing bridges: firstValueFrom(toObservable(...)).

Why would a resource go back to idle?

One thing left to formalize: what is returning-to-idle for? To make a new request? Not quite: reload() already does that. To free the value when nothing is using it? Closer. Combine the two: drop the value when nobody needs it anymore, and fetch fresh data when someone comes back. That is the use case: an automatic refresh on return, with no stale data kept alive in between. Think of a details panel: close it, its data is disposed; reopen it a minute later, it loads current data, not last minute's.

What about refreshing while the resource is being watched? That is reload(), and the split holds for a precise reason: there is exactly one situation where no code has a handle to call reload(): the moment the last watcher leaves. Every other refresh scenario has an event or a code path attached to it, some place where calling reload() is natural. So the last-watcher transition is the single point where the resource must act on its own; everywhere else stays explicit.

From there, the model stops needing methods and collapses into two cases with clean semantics:

resource({ loadStrategy: 'whenTracked', params, loader });   // first listener starts the load; value kept afterwards
resource({ loadStrategy: 'whileTracked', params, loader });  // lives exactly while listened to

One invariant behind both: no load ever runs while nothing tracks the resource. when is a trigger, while is a lifetime, and the pair carries the whole contract.

What fell out

The API ended smaller than where v1 started. peek() is gone: a read outside a reactive context already is one. toPromise() is gone too, and it is the telling one: the method both designs kept while disagreeing on everything else. With the right trigger found, it had nothing left to do.

The disagreement dissolved the same way. Liveness propagates transitively through computeds, so listening to a wrapper wakes the source through every layer. wartab's rule and my composition constraint were never in conflict. They were sitting on different axes.

The price in core is small. Two optional hooks on the reactive graph, 22 lines, fired on the live-consumer transitions the graph already maintains (they happen to be the watched / unwatched callbacks of the TC39 Signals proposal). About 190 lines in resource.ts. The public API diff is exactly one option. The lazy behaviors are a 43-spec contract run against both strategies.

Where this goes

The issue is open, an Angular team member left it open for community discussion. To support this feature or take part in the discussion, head to the issue. The playground runs the actual branch diff if you want to watch whileTracked cancel a request in the network log, and the gist is the copy-paste version for today.

Thanks to wartab for the pushback and the discussion.

resource({ lazy: true }): the laziness we lost when we left the async pipe

flo-dmtx — Fri, 31 Jul 2026 12:22:57 +0000

An observable does nothing until something subscribes. For years that gave Angular data loading a property we barely had to think about: expose a cold observable from a service, drop an async pipe in the template, and the request fired only when the view actually displayed it. A panel behind an @if that stayed false never subscribed, so it never fetched.

Then signals arrived, and resource() and rxResource() are a real upgrade: statuses, errors, cancellation, a value you can read anywhere. I have no desire to go back. But resources are eager by design: they start their loader from an effect at construction, so declaring a resource is fetching it. Somewhere in that upgrade, the laziness quietly disappeared.

What the framework nudges you toward instead is this component:

// this component exists to defer one fetch
class UserCard {
    readonly user = rxResource({
        params: () => 1,
        stream: ({ params }) => api.user(params),
    });
}

<!--
  created: fetches.
  destroyed: forgets.
  shown again: fetches again.
-->
@if (showCard()) {
    <user-card />
}

The component has no real job. It exists so that its lifecycle can play the part of the missing laziness: the only way to say "don't fetch this yet" is to push the resource down into a component that does not exist yet, behind an @if or inside a @defer block. The component lifecycle becomes your fetch trigger.

It works. That is exactly why it spreads. And every time it spreads, you pay three costs:

The value dies with the component. Close the panel, open it again: refetch. The user pays for your architecture with a spinner, every single time.
Data fetching scatters down the component tree. The route or service that owns the screen no longer owns its data. To find out what a page loads, you walk the tree and collect resources from leaf components.
The codebase accumulates wrapper components. Each one is a file, a selector, a test, a name in your head. Their only feature is delaying one request.

@defer does not save you here. It defers a block of the view and its code chunk, which is great, but it says nothing about data. Nothing on the resources side defers the data itself. So we all keep reaching for the one deferral mechanism we have, the component lifecycle, and we keep paying those three costs.

For a long time I simply refused the pattern: I would rather fetch everything eagerly and pay for a few requests nobody looks at than scatter data fetching down the tree. The day I caught myself writing computed() wrappers whose only purpose was to create a resource on its first read, I stopped treating this as an architecture trade-off and started treating it as a missing primitive.

The fix is one line

Here is the proposal:

readonly user = resource({
    lazy: true,                                  // the only new line
    params: () => this.userId(),
    loader: ({ params }) => fetchUser(params),
});
// rxResource({ lazy: true, ... }) — inherited through its options, no other change

With lazy: true, the load effect is simply not created. Instead, the first read of any of the resource's signals starts the load. Templates read signals, so what renders is what fetches. The UserCard above becomes: declare the resource in the parent (or the route, or a service), read it wherever it shows. No wrapper.

Notice how each of the three costs falls away, and not by accident:

The resource lives where you declared it, so its value outlives the panel that reads it. First visit fetches; revisit shows the kept value. No refetch, no spinner.
The declaration moves up the tree, back to the route or service that owns the screen. The trigger stays down in the view, where it belongs, as a plain signal read.
The wrapper components can be deleted. That is my favorite kind of feature: one that removes code.

The semantics: the decisions behind "the first read fetches"

A one-line option still has to behave correctly in every corner, and I had to make some calls. These are the ones worth knowing:

Every read wakes it, even inside untracked(). Suppose only untracked reads could stay silent, and your template does @if (r.hasValue()). The read returns false, nothing reactive changed, so no change detection cycle ever comes back to ask again. The template asked the question once, got "not yet", and the resource took "not yet" as permission to sleep forever: the guard that was supposed to reveal the data is the thing keeping it hidden. So: any read wakes the resource. A non-waking peek() is a natural follow-up if you truly need to look without touching.

Params changes while asleep are tracked but never fetched. The first read fetches once, with the latest params value. A user can change every filter in a form before opening the results panel and the network stays idle. Then one read, one request. I like this one because it falls out of thinking of params as state, not as events. The loader does not care how the params got to their current value, only what they are when someone finally wants the data. Once you frame it that way there is nothing to queue and nothing to replay.

Writes never wake it. set() on a never-read resource goes to the local status without running the loader. reload() defers the load to the next read.

Laziness composes. A computed() over a lazy resource is itself lazy. Chained resources (one's params reading another's value) stay asleep end to end, and one read at the end of the chain wakes them in order, never in parallel.

Once awake, it is exactly an eager resource. Same statuses, same errors, same cancellation, same SSR stability. The only documented caveat: combining lazy with id (SSR transfer) is discouraged, because the hydration window has usually closed by the first read.

Wasn't this already rejected?

Yes, mostly. Issue #58422 asked for a lazy option and the Angular team closed it. Their concern was legitimate: render-driven data fetching invites request waterfalls, and data is generally better lifted up to routes.

I agree with the concern. But look at where that closure left us. The workaround everyone uses instead, fetching tied to a component lifecycle, is render-driven fetching in its most fragile form, and it re-runs the waterfall on every component recreation. Each time the panel reopens, the whole chain of requests fires again. So the honest summary of the status quo is: Angular says "lift your data up", and then the only supported way to defer a fetch is to push it down.

Compare that with the wrapper component on the three points of the concern:

Where is the declaration? Up the tree, at the route or service. The wrapper pushed it down.
How many times does the trigger fire? Once, on first read. The wrapper refires on every recreation.
Who owns the value? The service. It survives its readers. The wrapper's value died with the DOM.

The waterfall has nowhere to repeat. And it is strictly opt-in: eager resources are untouched. It also composes with @defer instead of competing with it: the deferred view brings the code, the lazy resource in the parent brings the data.

The proof, in numbers

I did not want this to be an opinion. Building custom signal primitives is how I usually attack this kind of gap, so I built the proposal three times, and scored the userland attempts against a parameterized suite of 39 observable behaviors: the sleeping rules above, plus everything a native resource must keep doing once awake.

strategy	lines	contract
gate the params on a "shown" flag (the common workaround)	~60	18/39
drive core's private `loadEffect` (2 private fields, do not ship)	—	34/39
reimplement beside core, public API only	~370	39/39
the native option (this proposal)	~90 in ResourceImpl	by construction

A few things this table taught me. The "shown flag" gate looks like a cheap fix, but it only defers the first load and misses most of the sleeping rules. Reaching into core's privates gets you to 34/39 and a dependency on two private fields; its real value was as evidence, because the behaviors it passes are exactly the ones you get for free when the laziness lives where the effect is created. And the full reimplementation does pass everything, but it costs ~370 lines to reproduce what the native option does in ~90 inside ResourceImpl, because natively you are not fighting the design, you are just not creating one effect.

The native version is real code, not a sketch: branch feat/lazy-resource on my fork of angular/angular. One commit, a 500-line spec, docs. When lazy is set the load effect is not created; a small reactive pull node takes its place, pulled by value, status and error. On that branch, //packages/core/test/resource passes 91/91 (the new lazy suite plus every pre-existing spec, unchanged), rxjs-interop passes 76/76, and the public API goldens are green, all with the repo's own Bazel tooling. rxResource inherits the option through its existing options spread: zero interop code change.

If you would rather see it than believe a table, the interactive proposal page pins @angular/core 22.1.0 and applies the native diff to the published bundle with patch-package, so the option exists in your browser even though it does not exist in Angular. Every demo on the page runs the actual rxResource({ lazy: true }), with a per-demo network log showing every request that leaves and, more importantly, every request that does not. You can watch a parent-owned resource being read by a child, tabs that fetch on first visit and keep their value on revisit, params changing while the resource sleeps, a chain waking in order, and the full contract with reload, set, a 503 and the recovery. The same project runs on StackBlitz if you want to poke at the code.

Use it today, and help it land

Two things you can do, one for you and one for the feature.

For you: the 39/39 userland implementation is a single file with no private imports, published as a gist. It exports lazyResource (promise loader) and lazyRxResource (observable stream). Copy the file into your project, swap rxResource for lazyRxResource, and start deleting wrapper components this week.

For the feature: I have opened a feature request for the native option at angular/angular#70036.

If you have written the UserCard component above, in any of its forms, a thumbs-up helps; a comment describing your own wrapper-component pile helps more, because "who actually needs this" is the question the team will ask. The previous issue was closed on a reasonable concern; what it was missing, I suspect, is evidence of how many of us are living with the workaround. That part is on us.