-
Notifications
You must be signed in to change notification settings - Fork 25k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
input signal effects are not run when attaching a directive to an IonButton #55644
Comments
Referenced in Ionic: ionic-team/ionic-framework#29444 |
Hello. We found the same issue in a new project inside our company. It looks like the problem is really the
Component and directive:
|
The root cause is the injection of the The effect is scheduled to run first when the component is init and uses the CDR to do that. In this case, the component is never init (because of running A workaround for this would be to let the component finish its initialization and detach only in the |
Here is a minimal repro: https://stackblitz.com/edit/stackblitz-starters-7zd1fv?file=src%2Fmain.ts As @JeanMeche pointed out, the root cause here is a component detaching from the change detection tree. Having said this I do recognize that this is very non-obvious - this is one of the cases we want to look into before stabilizing |
Reopening as this is a separate issue than #55808. |
The original effect design for Angular had one "bucket" of effects, which are scheduled on the microtask queue. This approach got us pretty far, but as developers have built more complex reactive systems, we've hit the limitations of this design. This commit changes the nature of effects significantly. In particular, effects created in components have a completely new scheduling system, which executes them as a part of the change detection cycle. This results in behavior similar to that of nested effects in other reactive frameworks. The scheduling behavior here uses the "mark for traversal" flag (`HasChildViewsToRefresh`). This has really nice behavior: * if the component is dirty already, effects run following preorder hooks (ngOnInit, etc). * if the component isn't dirty, it doesn't get change detected only because of the dirty effect. This is not a breaking change, since `effect()` is in developer preview (and it remains so). Fixes angular#55311 Fixes angular#55808 Fixes angular#55644
The original effect design for Angular had one "bucket" of effects, which are scheduled on the microtask queue. This approach got us pretty far, but as developers have built more complex reactive systems, we've hit the limitations of this design. This commit changes the nature of effects significantly. In particular, effects created in components have a completely new scheduling system, which executes them as a part of the change detection cycle. This results in behavior similar to that of nested effects in other reactive frameworks. The scheduling behavior here uses the "mark for traversal" flag (`HasChildViewsToRefresh`). This has really nice behavior: * if the component is dirty already, effects run following preorder hooks (ngOnInit, etc). * if the component isn't dirty, it doesn't get change detected only because of the dirty effect. This is not a breaking change, since `effect()` is in developer preview (and it remains so). As a part of this redesigned `effect()` behavior, the `allowSignalWrites` flag was removed. Effects no longer prohibit writing to signals at all. This decision was taken in response to feedback / observations of usage patterns, which showed the benefit of the restriction did not justify the DX cost. Fixes angular#55311 Fixes angular#55808 Fixes angular#55644 Fixes angular#56863
The original effect design for Angular had one "bucket" of effects, which are scheduled on the microtask queue. This approach got us pretty far, but as developers have built more complex reactive systems, we've hit the limitations of this design. This commit changes the nature of effects significantly. In particular, effects created in components have a completely new scheduling system, which executes them as a part of the change detection cycle. This results in behavior similar to that of nested effects in other reactive frameworks. The scheduling behavior here uses the "mark for traversal" flag (`HasChildViewsToRefresh`). This has really nice behavior: * if the component is dirty already, effects run following preorder hooks (ngOnInit, etc). * if the component isn't dirty, it doesn't get change detected only because of the dirty effect. This is not a breaking change, since `effect()` is in developer preview (and it remains so). As a part of this redesigned `effect()` behavior, the `allowSignalWrites` flag was removed. Effects no longer prohibit writing to signals at all. This decision was taken in response to feedback / observations of usage patterns, which showed the benefit of the restriction did not justify the DX cost. Fixes angular#55311 Fixes angular#55808 Fixes angular#55644 Fixes angular#56863
The original effect design for Angular had one "bucket" of effects, which are scheduled on the microtask queue. This approach got us pretty far, but as developers have built more complex reactive systems, we've hit the limitations of this design. This commit changes the nature of effects significantly. In particular, effects created in components have a completely new scheduling system, which executes them as a part of the change detection cycle. This results in behavior similar to that of nested effects in other reactive frameworks. The scheduling behavior here uses the "mark for traversal" flag (`HasChildViewsToRefresh`). This has really nice behavior: * if the component is dirty already, effects run following preorder hooks (ngOnInit, etc). * if the component isn't dirty, it doesn't get change detected only because of the dirty effect. This is not a breaking change, since `effect()` is in developer preview (and it remains so). As a part of this redesigned `effect()` behavior, the `allowSignalWrites` flag was removed. Effects no longer prohibit writing to signals at all. This decision was taken in response to feedback / observations of usage patterns, which showed the benefit of the restriction did not justify the DX cost. Fixes angular#55311 Fixes angular#55808 Fixes angular#55644 Fixes angular#56863
The original effect design for Angular had one "bucket" of effects, which are scheduled on the microtask queue. This approach got us pretty far, but as developers have built more complex reactive systems, we've hit the limitations of this design. This commit changes the nature of effects significantly. In particular, effects created in components have a completely new scheduling system, which executes them as a part of the change detection cycle. This results in behavior similar to that of nested effects in other reactive frameworks. The scheduling behavior here uses the "mark for traversal" flag (`HasChildViewsToRefresh`). This has really nice behavior: * if the component is dirty already, effects run following preorder hooks (ngOnInit, etc). * if the component isn't dirty, it doesn't get change detected only because of the dirty effect. This is not a breaking change, since `effect()` is in developer preview (and it remains so). As a part of this redesigned `effect()` behavior, the `allowSignalWrites` flag was removed. Effects no longer prohibit writing to signals at all. This decision was taken in response to feedback / observations of usage patterns, which showed the benefit of the restriction did not justify the DX cost. Fixes angular#55311 Fixes angular#55808 Fixes angular#55644 Fixes angular#56863
The original effect design for Angular had one "bucket" of effects, which are scheduled on the microtask queue. This approach got us pretty far, but as developers have built more complex reactive systems, we've hit the limitations of this design. This commit changes the nature of effects significantly. In particular, effects created in components have a completely new scheduling system, which executes them as a part of the change detection cycle. This results in behavior similar to that of nested effects in other reactive frameworks. The scheduling behavior here uses the "mark for traversal" flag (`HasChildViewsToRefresh`). This has really nice behavior: * if the component is dirty already, effects run following preorder hooks (ngOnInit, etc). * if the component isn't dirty, it doesn't get change detected only because of the dirty effect. This is not a breaking change, since `effect()` is in developer preview (and it remains so). As a part of this redesigned `effect()` behavior, the `allowSignalWrites` flag was removed. Effects no longer prohibit writing to signals at all. This decision was taken in response to feedback / observations of usage patterns, which showed the benefit of the restriction did not justify the DX cost. Fixes angular#55311 Fixes angular#55808 Fixes angular#55644 Fixes angular#56863
The original effect design for Angular had one "bucket" of effects, which are scheduled on the microtask queue. This approach got us pretty far, but as developers have built more complex reactive systems, we've hit the limitations of this design. This commit changes the nature of effects significantly. In particular, effects created in components have a completely new scheduling system, which executes them as a part of the change detection cycle. This results in behavior similar to that of nested effects in other reactive frameworks. The scheduling behavior here uses the "mark for traversal" flag (`HasChildViewsToRefresh`). This has really nice behavior: * if the component is dirty already, effects run following preorder hooks (ngOnInit, etc). * if the component isn't dirty, it doesn't get change detected only because of the dirty effect. This is not a breaking change, since `effect()` is in developer preview (and it remains so). As a part of this redesigned `effect()` behavior, the `allowSignalWrites` flag was removed. Effects no longer prohibit writing to signals at all. This decision was taken in response to feedback / observations of usage patterns, which showed the benefit of the restriction did not justify the DX cost. Fixes angular#55311 Fixes angular#55808 Fixes angular#55644 Fixes angular#56863
Which @angular/* package(s) are the source of the bug?
core, elements
Description
Expected:
Running an effect on an input signal within a directive that is attached to an IonButton should trigger/run the effect code.
Actual:
The effect is not run.
It works just fine if attached to other html tags.
Insight:
This is where the current behavior is probably sourced => https://github.com/ionic-team/ionic-framework/blob/ba5cebf2542c8fbd6c29af593a31a742e0caba1e/packages/angular/src/directives/proxies.ts#L357
Please provide a link to a minimal reproduction of the bug
https://stackblitz.com/edit/stackblitz-starters-gkckxf?file=src%2Fmain.ts
Please provide the environment you discovered this bug in (run
ng version
)Anything else?
Issue has been confirmed by "JB Nizet" and "Matthieu Riegler" and I was encouraged to create a bug report here.
The text was updated successfully, but these errors were encountered: