React to input changes: signal effects vs ngOnChange about angular HOT 5 OPEN

Indeed... also noticed #54548 and the comment from the ngrx guys!
#54548 (comment)

Well, don't know what else to say then :-)... just that the automatic-tracking design choice for effects (with the addition of untracked) sounds a bit strange to me. It sounds kind of in between "full responsibility on developers" vs "everything automatic".

Moreover, IMHO explicit deps would make the code very clear on any developer's intention.

But ok: it might be simply my attitude (always: freedom / responsibilities to devs with great doc :-)) and the fact I'm missing an extensive usage of signals in a real (and big) app.

from angular.

@mauriziocescon you can also take my implementation from here: #54614 (comment)

from angular.

Hi, about explicit dependencies we had a previous discussion in #50916

from angular.

So there are multiple topics being discussed here, ranging from working with inputs all the way to the automatic dependencies tracking with signals.

Let me start with re-iterating our position from #50916 - we've chosen signals partly because of their automatic tracking nature: we don't want developers to remember and deal with the friction of manual dependency tracking. Having said this people are free to use coding patterns that make dependencies more explicit if this help their code organization.

Now, for the input as signals I would say that reactive primitives (computed, effect) are the way to go. Most of the time we expect people to reach out for a computed and only use effect for truly side-effectful operations. In this sense your example could be re-written as follows:

valueEffect = effect(() => {
       // whenever value changes, do something
       doSomething(this.value());
  });

I don't think untracked is needed by default since:

• using it as a way to allow signal writes is missing the point of the safety check of writing to signals in effects;
• mentioned bugs (ex.: #54548) are well, bugs that we've fixed already so those shouldn't factor in the decision;
• doSomething might want to respond reactively to the value changes.

I'm happy to discuss more around more concrete examples - here we do have just a short code snippet and this makes it impossible to reason about the general logic

from angular.

Hey!

Thanks for the reply: much appreciated. Well, I provided a stackblitz at the beginning, but it's just an easy example that can be refactored the way you proposed.

Considering the inputs part clarified, let me try to make the automatic deps tracking more clear: the logic and functionalities currently available for effects covers all the needs. No disagreement on that. So there isn't anything logically unsupported.

The problem I see is not about the logic, but what developers will use the most on a daily basis and how effects behave by default. IMHO effects will be massive used (not just rarely), but they don't fulfil (out of the box) common developer needs.

// `doSomething` could do many complex things like calling a method on a global service that
//
// 1) changes a signal as its internal implementation
//  (rxjs optional, signals replacing subjects), 
// 
// 2) that reads some service internal signals to perform some operations 
// (unwanted deps added to valueEffect by mistake)
// 
// 3) that is not under my control in terms of 
// implementation / refactoring (huge enterprise app with ~100 devs)



// default (automatic deps tracking, safe guard on signal writes): I'd say rarely needed 
// and able to track unwanted deps coming from doSomething
valueEffect = effect(() => doSomething(this.value()));


// variation (safe guard on the tracked dep(s), can write on signals): highly desirable cause 
// I don't need to know anything about doSomething internal implementation and 
// there's no risk at the level of unwanted deps coming from it
valueEffect = effect(() => {
       this.value(); // <- simple reactive condition I want to be auto tracked
       untracked(() => doSomething(this.value()); // <- safe callback
  });

I personally believe that the watch func suggestion is what is missing right now. No need to change effect, just a new primitive following the "effect variation" above and good documentation (watch vs effect).
#54548 (comment)

Here is a stackblitz with the service example mentioned above and lots of comments https://stackblitz.com/edit/stackblitz-starters-csmdrr

Again: the code could be refactored and problems solved. But don't forget about the real life:

• lots of developers,
• big app,
• complexity,
• calling global services without knowing the internal implementation,
• junior devs,
• the quick fix suggestion coming from Error: NG0600 (by the way: why suggesting to enable allowSignalWrites instead of a page untracked vs allowSignalWrites? :-) ) .

In other words: in a world of signals (services / components / ... ) is it really rare writing to signals in effects while reacting (for example) to component input changes? Is the default effect usage the safest in terms of unwanted tracked deps?

Just my 2 cents!

PS: thanks a lot for the amazing work you're doing!

from angular.