Computed signals and Effects should produce runtime warning if dependencies reaches zero #55647
Labels
area: core
Issues related to the framework runtime
core: reactivity
Work related to fine-grained reactivity in the core framework
cross-cutting: signals
Milestone
Which @angular/* package(s) are relevant/related to the feature request?
Core (signals)
Description
An easy pitfall to encounter with computed signals and effects is creating a function that only gets called once because it depends on non-signal conditions. Especially for devs new to signals (almost everyone at this point), it can be a counter-intuitive problem source to debug. And there are already issues reported that can be traced to this.
#51180
Here's some example code that I wrote that caused non-obvious problems for me:
this.range
is a signal, andthis.calendarRef
is possibly undefined. I expected any changes torange
to trigger the effect, but the optional chaining on thecalendarRef
(which was undefined) preventedrange()
from ever being evaluated and thus tracked as a dependency. And I believe that even if it wasn't undefined for the first run, if it ever reached undefined while the effect was evaluated, the effect would never run again.Proposed solution
At the least, if the first run of a computed() or effect() callback produces no dependencies (invokes no signals), a runtime warning should show in the console to warn the user that their computed signal/effect will not run again.
It might also be useful to warn them if their dependency count drops from >1 to 0, which again means the computed signal/effect will not be evaluated again.
Similar to
allowSignalWrites
, the dev could remove these training-wheels warnings by positively expressing that they are intentionally designing a callback that will only be called once/stop being updated at some point.Alternatives considered
It would likely be harder to implement, but static code analysis could detect the possibility of a zero-dependency computed signal/effect.
Regardless of whether a warning is added, documentation talking about this pitfall would be useful; currently not present as far as I can tell.
The text was updated successfully, but these errors were encountered: