Skip to content
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

fix(core): disallow reactive node creation in consumer context #51082

Conversation

pkozlowski-opensource
Copy link
Member

This change introduces a check around reactive node creation. On the high level it disallows creation of the new reactive nodes while executing consumer functions (computed, effects, template dirty-checking).

It might turn out that this check is too restrictive and there are legitimate use-cases for which we would want to allow reactive node creation while executing computed, effect etc. This is why this PR has infrastructure to enable those checks on the per reactive node type.

We do start with the most restrictive version of checks and might gradually releax those checks as we learn more.

Closes #51055

@@ -88,6 +92,8 @@ class ComputedImpl<T> extends ReactiveNode {

protected override readonly consumerAllowSignalWrites = false;

protected override readonly consumerAllowReactiveNodeCreation = false;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will effectively prevent creation of reactive nodes in angular expressions. Which I think is a good guiderail but calling it out explicitly.

* Whether new reactive node creation should be allowed when this `ReactiveNode` is the current
* consumer.
*/
protected abstract readonly consumerAllowReactiveNodeCreation: boolean;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perf note: depending on how many of those flags we are going to have in the future, we might want to combine them into a single bit-flag numeric field.

This change introduces a check around reactive node creation. On the high
level it disallows creation of the new reactive nodes while executing
consumer functions (computed, effects, template dirty-checking).

It might turn out that this check is too restrictive and there are legitimate
use-cases for which we would want to allow reactive node creation while
executing computed, effect etc. This is why this PR has infrastructure to
enable those checks on the per reactive node type.

We do start with the most restrictive version of checks and might gradually
releax those checks as we learn more.

Closes angular#51055
@pkozlowski-opensource
Copy link
Member Author

Obsolete after landing #51226 - will open another PR to tackle #51027

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Oct 14, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Nested computed signals have glitchy behavior due to garbage collection of WeakRef dependencies
1 participant