This PR moves the Observable subscription of toSignal outside of the
reactive context. As the result the toSignal calls are allowed in the
computed, effect and all other reactive consumers.
This is based on the reasoning that we already allow signals creation
in a reactive context. Plus a similar change was done to the async pipe
in the https://github.com/angular/angular/pull/50522Fixes#51027
PR Close#51892
When a producer is no longer used, the consumer has to update its internal data structure
that keeps track of all producers. There used to be an issue where only half of the stale
producers would actually be removed from this data structure, as the intended upper bound
of the number of producers to remove would decrease with each removed producer, therefore
not reaching all producers that should be removed from the data structure.
This commit fixes the issue by truncating the arrays directly, without going through
individual `pop` operations. An assertion that would catch the inconsistent state in
the internal data structures of the signal graph has been introduced.
PR Close#51722
PR Close#51772
This commit switches the signals library from a bidirectional symmetric
dependency graph using weak references, to a bidirectional _asymmetric_
graph which uses strong references. This is made possible with a reference
counting algorithm which only tracks producer -> consumer references for
effect-like "live" consumers, preventing memory leaks.
The new algorithm should be simpler and faster than the previous
implementation as weak references are fairly slow to create and traverse.
A tradeoff is that non-live consumers must now poll their producers when
read, as they cannot rely on dirty notifications.
As part of this refactoring, the `ReactiveNode` class is replaced with an
interface instead, and methods are moved to standalone functions. This is
paired with instantiating individual signals/computeds via `Object.create`
against a prototype node which contains static or initial values. This
technique, in conjunction with the rest, greatly improves the performance
of node creation.
PR Close#51226
Unlike the current signature where the input argument must a function, this change allows an input of any type to be passed to the `isSignal` function.
PR Close#50035
The new asReadonly method on the WritableSignal interface makes
it possible to create readonly instance of a writable signal.
Readonly signals can be accessed to read their value,
but can't be changed using set, update or mutate methods.
PR Close#49802
This change makes is possible to use async functions
(ones returning a promise) as effect run functions.
To make it possible, the signature of the effect function
changed: effect cleanup function is registered now
(using a dedicated callback passed to the effect creation)
instead of being returned from the effect function.
PR Close#49783
This commit adds a hook to `WritableSignal` that is called whenever the
signal's value is updated via the mutation API. This hook allows consumers
to implement logic which is synchronous with signal sets (e.g. executing
effects). It's currently unused.
PR Close#49708
* Prevent reads of signals during the notification process. This shouldn't
ever be triggered by user code but is more of a preventative for
internal misuse. Reading a signal during notification would/could create
glitches where the values being read are not updated to reflect the
values being updated by the notification.
* Prevent signal writes inside of computed's. These are meant to be
derived values and should not have any side-effects like writing new
values to other signals
* Prevent signal writes inside of effects by default. Writing to signal
values during the execution of an effect can lead to the
`ExpressionChangedAfterItHasBeenCheckedError` if writing to signals
that represent global state which is read in a parent component. This is
mostly just a problem for `OnPush`/`CheckAlways` components, but with
signals being new and pure signal components not even available yet,
it will be the majority for a long time.
PR Close#49631
We've been experimenting with the DeepReadonly type that would make
signal values deeply read-only and prevent accidental changes without
going to the owner of data. What we've found out during the experiments
is that additional safety net has more drawbacks than benefits: it just
introduces too much friction to be practical for daily usage.
PR Close#49154
This change extends the effect API surface so effects can, optionally,
return a cleanup function. Such function, if returned, is executed
prior to the subsequent effect run.
PR Close#49625
This commit adds a `DeepReadonly` type to the signals API, and makes signal
getters return an immutable version of their value type. This doesn't
prevent all mutation but adds some friction against modifying the values
within signals outside of the proper mutation APIs.
PR Close#49529
The `effect` implemented in the signal library is useful for testing but
does not integrate with Angular. This commit moves that code to the
actual framework package and integrates it with automatic cleanup via
`DestroyRef`. A simpler effect implementation is used in the signal tests to
test the `Watch` primitive.
Further commits will update the scheduling to tie effects together with
change detection.
PR Close#49529
This commit switches the `signal` and `computed` APIs to accept an optional
options argument as their second argument, instead of an equality function
directly. The equality function has moved to an option in the options
argument.
PR Close#49529
This commit exposes `signal`, `computed`, `effect` and various helpers from
the `@angular/core` entrypoint.
These APIs are marked as `@developerPreview` and are still prototypes in
active development. Their final shapes will be subject to our internal
design reviews as well as one or more community RFCs. We're exporting them
now to allow for experimentation using 16.0.0 next and RC releases.
PR Close#49150
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>
PR Close#49091
Pawel Kozlowski