Reputation: 19
I am using Angular 16 and just started with signals. Those make working with ngrx even better. When transitioning I found myself presented with something that can be abstracted to this:
const state = {
someArray: [1, 5, 7]
}
export const selectArray = createSelector(
state,
(state) => state.someArray
);
export const selectFirst = createSelector(
selectArray,
(someArray) => someArray[0]
);
export const selectLast = createSelector(
selectArray,
(someArray) => someArray[state.someArray.length-1]
);
export const selectLastMinusFirst = createSelector(
[selectFirst, selectLast],
(first, last) =>
last - first
);
Now with signals this could be rewritten using computed signals in the component that wants to use it to something like this:
const someArray: Signal<number[]> = this.store.selectSignal(Selectors.SelectArray)
const first: Signal<number> = computed(() => someArray()[0]);
const last: Signal<number> = computed(() => someArray()[state.someArray.length-1]);
const lastMinusFirst: Signal<number> = computed(() => last() - first());
Or even using signals effects:
const first = 0;
const last = 0;
const lastMinusFirst = 0;
const someArray: Signal<number[]> = this.store.selectSignal(Selectors.SelectArray)
constructor() {
effect(() => {
if(someArray().length) {
this.first = someArray()[0];
this.last = someArray()[someArray().length - 1];
this.lastMinusFirst = this.last - this.first;
}
});
}
What is the intended way of doing it? Are computed signals more efficient as they mention lazy evaluation and memoized?
Upvotes: 1
Views: 4440
Reputation:
computed()
is better than a selector, because
|async
or dirty checking;computed()
you call some function, that also uses signals, then the resulting signal will be updated when a signal in that function is updated. And this can happen somewhere deep in the stack, as long as it happens synchronously. It allows to create very flexible and powerful things - derived signals, composed of derived signals.Meanwhile, NgRx is working on integration with Angular Signals:
Upvotes: 0