refactor(signals)!: multiple signals in STATE_SOURCE
#4779
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a necessary refactoring to support a state which allows different types of Signals, i.e.
linkedSignal
&signal
but still presents itself as a single unit to the outside.This commit splits the single Signal of
STATE_SOURCE
, which contains the state in theSignalStore
andsignalState
, into multiple Signals.An example. Given the following type:
Before,
STATE_SOURCE
would have been the following type:With this change, it is:
Most changes affect the tests which focus on the
STATE_SOURCE
. Except for one test insignal-state.spec.ts
('does not modify STATE_SOURCE'), all tests could be updated to assert the new behavior.Breaking Changes
STATE_SOURCE
will be impacted.different object reference for state of
STATE_SOURCE
STATE_SOURCE
does not keep the object reference of the initial state upon initialization.no Signal change on empty patched state
patchState
created a clone of the state and applied the patches to the clone. That meant, if nothing was changed, the Signal still fired because of the shallow clone. Since the state Signal doesn't exist anymore, there will be no change in this case.Further Changes
signalStoreFeature
had to be refactored because of typing issues with the change toWritableStateSource
.patchState
get theNoInfer
forupdaters
argument. Otherwise, with multiple updaters, the former updater would have defined theState
for the next updater.Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
Does this PR introduce a breaking change?