It would be good if you make a best practice with StateApat in angular 16 and Signal.
Or any clue for me to upgrade and existing angular opensource project to version 16 with StateAdapt.
All this investment people are doing in signals seems like overuse to me. I'm very optimistic about signals, but I have strict expectations for what I want to use for state management, and signals are inherently limited. Signals are not lazy. Signals are the new Angular change detection mechanism. It's best to think of them as the new AsyncPipe, at least for now.
The best practice for StateAdapt is easy to describe: Use RxJS for anything that might be shared, which is pretty much everything.
This is how I plan on using signals:
Using computed to derive component-specific state, from toSignal
Use the tight integration between new Angular APIs and signals, such as component inputs, to drive either 1. Derived state, like described above, or 2. Event sources for other state to update, using toObservable and toSource. Maybe I should create toSignalSource to combine those steps, since they will be common. Probably for Angular 17.
Over time, the role of signals will increase. Signals can be lazy, because they can be returned from functions. I wish I had time to work on it myself right now, but what I'm waiting for is TanStack Query for signals in Angular. That is a great API and example of lazily requesting shared async state.
It would be good if you make a best practice with StateApat in angular 16 and Signal.
Or any clue for me to upgrade and existing angular opensource project to version 16 with StateAdapt.
[github.com/fullstackhero/angular-m...]
All this investment people are doing in signals seems like overuse to me. I'm very optimistic about signals, but I have strict expectations for what I want to use for state management, and signals are inherently limited. Signals are not lazy. Signals are the new Angular change detection mechanism. It's best to think of them as the new AsyncPipe, at least for now.
The best practice for StateAdapt is easy to describe: Use RxJS for anything that might be shared, which is pretty much everything.
This is how I plan on using signals:
computedto derive component-specific state, fromtoSignaltoObservableandtoSource. Maybe I should createtoSignalSourceto combine those steps, since they will be common. Probably for Angular 17.Over time, the role of signals will increase. Signals can be lazy, because they can be returned from functions. I wish I had time to work on it myself right now, but what I'm waiting for is TanStack Query for signals in Angular. That is a great API and example of lazily requesting shared async state.
Thank you for clarifying the road to me.