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
@ngrx/signals: add deepComputed
function
#4202
Comments
Unless I'm mistaken on your request, then is what the https://ngrx.io/guide/signals/signal-state We wouldn't created a |
No, For signals we have: count = signal(0)
doubleCount = computed(() => {
return this.count() * 2
}) I would like the same but for deep signals, so something like: count = signal(0)
doubleCount = computedState(() => {
return this.count() * 2
}) Hence, For primitives, this isn't very useful. But this would be useful for non-primitive values. Examples with non-primitive values:
profile = signalState({
firstName: "Georges",
lastName: "Bob",
})
computedSignal = computed(() => {
return {
firstName: this.profile.firstName(),
lastName: "Alice"
}
})
profile = signalState({
firstName: "Georges",
lastName: "Bob",
})
computedSignalState = computedState(() => {
return {
firstName: this.profile.firstName(),
lastName: "Alice"
}
}) Do not really pay attention to the body of the |
Right know, you can only have signals when using <p>
{{ computedSignal().firstName }}
</p> Whereas with a deep signal that you could get with <p>
{{ computedSignalState.firstName() }}
</p> Which is better for template rendering/change detection. With the |
We already considered this feature some time ago - const counts = signalState({ count1: 1, count2: 2 });
const doubleCounts = deepComputed(() => ({
count1: counts.count1() * 2,
count2: counts.count2() * 2,
});
console.log(doubleCounts()); // { count1: 2, count2: 4 }
console.log(doubleCounts.count1()); // 2
console.log(doubleCounts.count2()); // 4 |
deepComputed
function
Cool, what was the result of this consideration? Btw, if it is introduced later on in the library with the name |
@JulienLecoq I get the idea that the API is different and you like it more, but I'm not sure what problem are you trying to solve here. Since computeds are cached anyway, don't think perf could make much difference here. Especially in this section:
In what way would the proposed IMO the fact that e.g. the store itself is NOT a signal, or that we've got DeepSignals, etc. - all these are implementation details. The wonderful thing in the signal store design is its simplicity. By exposing additional Currently the fact that |
@ducin I have a In the end, when we access the store from a component, we see all the attributes, but some of them are The ideal would be to return DeepSignals when using Edit: |
Which @ngrx/* package(s) are relevant/related to the feature request?
signals
Information
I would like to have a
computed()
function similar to the one provided by Angular forSignals
but in this case, instead of returning a Signal, it would return aDeepSignal
.This would allow to optimise template rendering for computed states based on objects.
Exemples:
Describe any alternatives/workarounds you're currently using
I'm using the
computed()
function provided by Angular which returns a Signal.I would be willing to submit a PR to fix this issue
The text was updated successfully, but these errors were encountered: