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.
