My NEW default for state management in Angular

With the introduction of signals, I wanted to find a new default state management pattern I could use that is simple, reactive, declarative and doesn't involve using any 3rd party libraries

0:00 Introduction
0:26 The declarative approach
1:17 No 3rd party libraries
1:57 State and sources
3:12 Updating state
4:07 Alternatives
5:35 Side effects
5:55 Conclusion

#angular #rxjs #signals

[StephenMoreira]

Thanks for sharing. It's always great to see what someone else is thinking.

[williamxsp]

This approach looks very similar to ngrx/component-store. Thanks for the information. Its nice to see more content about angular signals as they will be the default.

[jotim]

This is such a good way of utilizing rxjs/signals for state management. Clean and easy to understand. Great job!

[mfpears]

This is really cool! More reactive than pretty much anything I've seen without a library, but without the scan boilerplate. Honestly I was bothered that RxJS itself didn't come up with something better than the Subject + map + scan + switch statement + startWith + publishReplay + refCount approach, but I've been annoyed at RxJS' lack of focus on state in general. For a while people who loved RxJS didn't really understand when I complained about it, but signals are really strong where RxJS is weak, so they're seeing it now. Signals mostly replace the need for selectors in addition to RxJS...

The signal in a service approach still isn't quite as good as custom hooks in React though, because the state is eternal. The subscriptions live forever, so HTTP requests aren't canceled or refetched automatically. React Query is very nice. But for not using a library, this is fantastic.

[rd_]

thanks....

I was learning angular for a while and i thought i know enough angular until i found your channel..because i use it imperatively.

I was learning these rxjs based approach for a while and signal occurs.
It is hard to keepup with angular.

Only if i was learning angular for long then these changes would feel good. But they are happening in mid of my journey.. it is what it is.

btw thanks josh for sharing these approaches.

[alextiger]

Thanks Man, Love that you always support your point with the corresponding source code

[desmondrouwhorst]

Joshua THANKS, for this greate video and idea!!

I'm a backend programmer from origin, but programming frontend for some years now, so probably doing thinks i a way you shouldn't 🙂

This video got me the idee to create a generic version of the storage.service and a generic version of the checklist(item).service which use a generic gatewayservice to call api's or in my case to read JSON-files from the assets location to make a simple website more dynamic and changeable. The api call is done when the data isn't in the storage yet, where the storage data is cleared every ....

Only thing no signal like is that you have to use a | null because you can't init a generic type, but a ngif fixes this problem quick easy.

Yeah backend programmers love their generics 😅
Don't see them much used in frontend, works really well.

Thanks again.

[SebieCodes]

After watching your video, I forked your repo, and ran the app. I had the idea to modify the reset feature. So, I made some minor changes and created a pull request. This would be the first time I've contributed to an opensource repo. Your Angular is more concise and you clearly have a strong grasp on the front end, still, maybe you will use the changes.

[bjarnekinkel]

I would be really interested in a video, that takes this concept a bit further. I would love to see how you would inplemteing pulling the data from an api and even more important, I would love to see how you would handle a reactive detail page (and service), that would get diffrent data depending on the item selected.

[AgustinCampon]

Hi Joshua thanks for your great content, I ve learned a lot from you over this last year. I was thinking on how signals are going to impact on the angular ecosystem, and I've concluded that the major change will be the transformation of properties into signals in our components. Surely this signals will end up receiving their values from observables, so we arent going to need in most cases the async pipe anymore. I think that the logic in services and store will surely remain the same (observable based) since its far more powerfull than having signals all over the application, by doing this you ve got the best of both worlds, reactivity and the ability to update an specific node of the DOM.

[VerhoevenSimon]

I really like the new possibilities offered by signals and takeuntildestroyed, and I'm looking forwards to signal based components.

[pdsavard]

Thank you for your video. It was the video I was looking to change my approach. I am like you, don’t want to use RxJs or NgRx, elf or other store management. Complicates, lots of boiler plates and our project is relatively small.

Lately i use Facade patterns with Observable state. Then using VM$ with combineLatest all the Facade State/Store variables to be more easily used with one general ASYNC pipe. That work OK, but little complicated and lots of code. I think you apprach fit very well in my FacadeService. I can use signal store and share it with my component. No need for Asyn pipe anymore.

[endlacer]

i found a potential problem with using a state signal. on 2:30 where you show the selectors for the state, you can see, that the computed signals update always when the state updates, even if its value is not changing.
when debugging i found that angular does stop the same value from propagating through the signal only when its a primative datatype. so objects and arrays for example will always trigger the signal and cause rerendering for example or further computations..

[evogenesis]

Hi Joshua, I really enjoy watching your videos as they are informative and educational. May I ask whether you have any advice on how to structure a large-scale Angular project? Possible you already have a video about it?

[bifty]

Thank you for the real nice presentations of all the topics. You can teach in a real good way! May i ask how / with what you create your diagrams / graphics?

[lucasgiunta]

I'm in fact using this pattern but in the others way. The state of my smart component is one computed signal contains one big object contains the signal value from the selector (one selector = one signal(...))

[babchenkonikolay]

What do you think about utilising ngrx’es component/store for these kind of operations?

The api looks much cleaner for me. And the concept should be familiar for most of the devs

[sebuzz]

A detail i'd like to understand better is, as you are in a service, which usually isn't destroyed (unless provided directly in the component), what's the reference for the takeUntilDestroyed pipe that will stop the subscription if you don't need this service anymore, let's say if you go in another part of the application where the subscription becomes obsolete ?

That's a concern i usually have in Angular projects where an app can have very different interfaces with specific functionalities and you don't want to start subscriptions all over the places that will become potential memory leaks. If you've addressed this issue in other videos, i'd be happy with the name or a link for it. Thanks.

[Artesgo]

hey Joshua, been following your vids for a while and directing people here because they are amazing.

what do you think of the toSignal utilities and why was it not chosen?

I've been trying to move away from NGRX while still replicating the pattern, the reducers having to reduce all of the state when any event affects just one or two props seems overkill and your tests would have to accommodate for that. i.e. my event emitted, check I've only touched the 2 props that i told it to touch

my approach is to put

private state = { prop: signal(), checklist: toSignal(checklistSource$) ... }
selector = { computed(...) }
actions = { someAction: () => state.prop.update() }

a. this groups all of the similar processes, makes it easier to scan the code and see what's available
b. those actions will only touch relevant pieces of data within your state
c. no subscribes

right now, i'm still stuck on ng14 so they're all behaviorSubjects still so perhaps you can drop some insights

[MrKyuubiJesus]

Ayyy, you should make sure that people can only remove by using a single method via encapsulation. Then it's very declarative. I think it's probably easier to do the same with signals.