Repository: angular
Issue: Explicit Tracking for `effect()`: Request for Reconsideration
Labels: area: core,core: reactivity,cross-cutting: signals

### 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:

```typescript

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:

```typescript
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: https://github.com/angular/angular/issues/56155#issuecomment-2137760839

**Prior Discussion:**
This issue was previously raised in 
- [Issue #54548](https://github.com/angular/angular/issues/54548#issuecomment-1961712985)
- [PR 54614](https://github.com/angular/angular/pull/54614)


Thank you for considering this enhancement.

### Alternatives considered

- Introducing a fourth "effect-like" function with explicit tracking
- Keep it as it is