Which @angular/* package(s) are relevant/related to the feature request?

core

Changelog

June 2, 2024: Added section on relying on external libraryes

Description

We have been refactoring an application towards using Angular's Signals. During this process, we observed a recurring pattern where effects inevitably require the use of untracked. This pattern has revealed several issues:

1. Frequent Use of untracked: Developers frequently need to use untracked to prevent unintended side effects in signals, making it a standard practice in our codebase.
2. Error-Prone Nature: The necessity of untracked is not well-known among developers, leading to common errors when it is omitted.
3. Maintenance Overhead: Constantly ensuring that untracked is correctly applied adds to the maintenance burden and cognitive load on developers.

To address these issues, we propose that Angular effects should adopt an explicit tracking model.

Proposed solution

1. Explicit Declaration: Developers should explicitly declare dependencies within effects, rather than relying on automatic tracking.
2. Default Non-Tracking: By default, effects should not track dependencies unless explicitly specified, reducing the need for untracked.

Example Scenario:
Currently, developers write:

id = input.required<number>();

effect(() => {
  // Part 1: Tracking
  const id = this.id();

  // Part 2: Execution
  untracked(() => {
    this.dataService.load(id);
  });
})

With explicit tracking, it would look like:

id = input.required<number>();

effect(this.id, (id) => {
  this.dataService.load(id);
});

Benefits:

1. Reduced Errors: Explicit tracking minimizes the risk of overlooking untracked, leading to more predictable and stable code.
2. Improved Developer Experience: Clearer dependency management simplifies understanding and maintaining the code.
3. Enhanced Performance: Explicit tracking can optimize performance by avoiding unnecessary re-computations and side effects.

Internal API and Library Ecosystem:
It is noteworthy that some parts of the internal Angular API already utilize automatic untracked. While this is beneficial, other libraries face similar problems and would benefit if the untracking responsibility was handled by the caller. This approach can provide more consistent and error-free usage across different codebases and libraries.

** External Libraries:**
It has been suggested that this change be implemented as an external library instead. Most application developers are not aware of explicit tracking, though, and would not expect implicit tracking, leading to bugs. Relying on an external library requires developers to be aware of the problem and actively seek out a solution.

Reference: #56155 (comment)

Prior Discussion:
This issue was previously raised in

• Issue #54548
• PR 54614

Thank you for considering this enhancement.

Alternatives considered

• Introducing a fourth "effect-like" function with explicit tracking
• Keep it as it is