Explicit Tracking for `effect()`: Request for Reconsideration

### 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.lo

Posted by rainerhahnekamp on May 29, 2024, 1:00 PM

Tags

• github (Other)

Related issues

• struct's lifetime requirements can be bypassed via covariant field assignment
• Proposal to Reorganize the Moderation Team and Review Moderation Policies
• Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
• proposal: container/...: generic collection types
• Better Custom Endpoint BYOK
• A concrete policy for backward compatibility until Godot 5.0