refactor(core): prototype of signals, a reactive primitive for Angular #49091
Conversation
alxhub
added
action: review
pkozlowski-opensource
added
target: major
Wow, that was a fast code review, @pkozlowski-opensource! |
Actually, isn't it one of the slowest? I was looking at the variants of this code for weeks already :-) |
pkozlowski-opensource
force-pushed
the
fw/reactivity/signals
branch
from
75de751
to
3429da5
Compare
alxhub
force-pushed
the
fw/reactivity/signals
branch
from
e883ff3
to
2a5b26d
Compare
| @@ -0,0 +1,248 @@ | |||
| /** | |||
There was a problem hiding this comment.
Non blocking, but consider changing/reorganizing in a follow-up PR. IMO file names should always describe the contents, so having a file named internal.ts is on par with having a file named functions.ts or classes.ts
|
|
||
| import {WeakRef} from './weak_ref'; | ||
|
|
||
| export type ProducerId = number&{__producer: true}; |
There was a problem hiding this comment.
Non blocking, but a comment here would be useful
This commit checks in (but does not export) a prototype implementation of Angular Signals, along with its unit test suite and a README explaining the algorithms used. Signals are not a new concept in the framework space, but there are many different flavors of implementations. These differ radically both in terms of public API as well as behavioral details (such as eager vs lazy computation, batching behavior, equality, cleanup, nesting, etc). This commit comprises a bespoke implementation that we've designed to best meet Angular's needs, especially when it comes to compatibility and flexibility of use within existing applications. Many of the API features of this implementation of signals, as well as the larger direction of reactivity in Angular, will be discussed in future RFCs. Co-Authored-By: Pawel Kozlowski <pkozlowski.opensource@gmail.com>
alxhub
force-pushed
the
fw/reactivity/signals
branch
from
2a5b26d
to
1193897
Compare
|
This PR was merged into the repository by commit 02cd490. |
|
can I remove zone when I use Signal？ |
| const counter = signal(0); | ||
|
|
||
| // Automatically updates when `counter` changes: | ||
| const isEven = computed(() => counter() % 2 === 0); |
There was a problem hiding this comment.
@alxhub If we don't preprocess function in computed at compile-time or use some form of reflection to atomically notify only affected signals, won't it require O(n) change checks, where n is a quantity of signals in application, effectively making it have same algorithmic complexity as ChangeDetectionStrategy.Default and making it harmful for angular ecosystem?(with signals there will be 2 ways to run change detection in O(n), using signals or ChangeDetectionStrategy.Default(which is simpler to do than signals), and 1 way to run change detection in ~O(1) - using rxjs and async pipe)
There was a problem hiding this comment.
@alxhub Oh, sorry, now I understand. We know for sure who is current consumer(because we track it in activeConsumer) and current producer(we can track it in code), so we have all the information needed to create dependency graph which will run atomically in O(1). I think we should mention explicitly for people like me why it runs in O(1)
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
For context, see this Github Discussion on our experiments with fine-grained reactivity in Angular
This commit checks in (but does not export) a prototype implementation of Angular Signals, along with its unit test suite and a README explaining the algorithms used.
Signals are not a new concept in the framework space, but there are many different flavors of implementations. These differ radically both in terms of public API as well as behavioral details (such as eager vs lazy computation, batching behavior, equality, cleanup, nesting, etc).
This commit comprises a bespoke implementation that we've designed to best meet Angular's needs, especially when it comes to compatibility and flexibility of use within existing applications.
Many of the API features of this implementation of signals, as well as the larger direction of reactivity in Angular, will be discussed in future RFCs.
🚦