fix(signals): deprecate calling rxMethod/signalMethod outside injection context

[david-shortman]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/ngrx/platform/blob/main/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Documentation has been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

When rxMethod or signalMethod is called with a reactive input outside an injection context without an explicit injector, a warning about a "potential memory leak" is displayed. This warning had some false positives in common usage patterns.

Closes #4991

What is the new behavior?

The warning is replaced with a deprecation message. The goal is to eventually align with Angular's reactive primitives by requiring an injector when reactive methods are called outside an injection context.

Changes:

• rxMethod and signalMethod: warning updated to deprecation notice
• Docs: alert type changed from inform to warn with deprecation language
• Tests: assertions updated to match new message, added child injection context coverage

Does this PR introduce a breaking change?

[ ] Yes
[x] No

This is a non-breaking change to a dev-mode warning message.

[netlify]

✅ Deploy Preview for ngrx-io ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	72f53ea
🔍 Latest deploy log	https://app.netlify.com/projects/ngrx-io/deploys/6998e2e9ab36a000075581df
😎 Deploy Preview	https://deploy-preview-5079--ngrx-io.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[markostanimirovic]

Hey @david-shortman 👋

Thanks for raising these PRs. I'm glad to see your PRs again!

I don't think we should show the warning only for root/platform injectors. In the following situation:

@Injectable()
export class ParentService {
  readonly parentMethod = rxMethod(...);
}

@Component({
  template: `
    @if (show()) { <child /> }
  `,
  providers: [ParentService],
})
export class ParentComponent {
  readonly show = signal(false);
}

@Component({ /* ... */ })
export class ChildComponent implements OnInit {
  readonly parentService = inject(ParentService);
  
  ngOnInit() {
    this.parentService.parentMethod(interval(2_000));
  }
}

The memory leak will happen when ChildComponent is destroyed, but a warning won't be displayed.

Another problem with this implementation is using the private injector.scope property that can potentially change in a non-major Angular version without a breaking change notice.

[david-shortman]

I'll see if I can detect this situation. Additionally, I can add testing that would catch a breaking change from Angular.

Glad to be looking at NgRx again. I was curious to look at older issues I had been involved with but with the fresh lens of researching and validating ideas with Claude Code.

[rainerhahnekamp]

👋 Hey all. If we’re looking to make changes here, I’d actually propose going into the opposite direction: show a deprecation message instead of a warning.

In that sense, rxMethod would align much better with the other Angular signal-based functions like effect, linkedSignal, and the resource APIs.

[david-shortman]

👋 Hey all. If we’re looking to make changes here, I’d actually propose going into the opposite direction: show a deprecation message instead of a warning.

In that sense, rxMethod would align much better with the other Angular signal-based functions like effect, linkedSignal, and the resource APIs.

You're referring to requiring supplying the injection context explicitly in all cases, correct?

Although I like the stylishness of the context being implicitly loaded, and the slightly less boilerplate that comes with it, I would support either direction.

So you're saying that, like the other Angular signal functions, unless you call in an injection context like the constructor, then you must explicitly supply the intended injection context?

[rainerhahnekamp]

So you're saying that, like the other Angular signal functions, unless you call in an injection context like the constructor, then you must explicitly supply the intended injection context?

Exactly.

My take here is that rxMethod's should follow the design of Angular's signal functions. So it is more the aspect of consistency.

[markostanimirovic]

Hey @david-shortman,

Do you want to update this PR with the suggested deprecation message?

[netlify]

✅ Deploy Preview for ngrx-site-v21 ready!

Name	Link
🔨 Latest commit	72f53ea
🔍 Latest deploy log	https://app.netlify.com/projects/ngrx-site-v21/deploys/6998e2e903df7e0008f30b3a
😎 Deploy Preview	https://deploy-preview-5079--ngrx-site-v21.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[david-shortman]

Hey @david-shortman,

Do you want to update this PR with the suggested deprecation message?

Yes; knowing that's the direction that multiple maintainers are good with, I've updated the PR to deprecate calling outside injection context.

[markostanimirovic]

thanks @david-shortman! 👑

[rainerhahnekamp]

Well done Mr. @david-shortman 👍