I tried to build my dream (simple) state management for Angular 

If one day the browser API adopts signals natively then I want to believe it the that

Check out Elm language architecture. The holy grail is there

svelte

StateAdapt helped shaped a lot of my thinking around the initial state management approach (without libs) and this utility is basically just an extension of that

I would have thought signals are a lot more efficient than observables.

Thanks for the thoughts - yes very similar in fundamental concepts to NgRx, although I would frame it as that both signalSlice and NgRx implement the redux pattern. Nesting is a fair point, could probably do some thing to address this if the indentation is too much (e.g. rather than defining everything inline they could be defined separately: add: actions.add)

Maybe they'll add it in the future.

I imagine it probably would be possible to support redux dev tools with this approach (it's still essentially the redux pattern), it's something I'd have to look into

Me & my team currently use your signal based state management approach in our latest app. We previously used NgRx but the one thing I am missing is the redux dev tools integration, this would be a huge step in the right direction for a more widespread adoption, good work! @@JoshuaMorony

Generally just with standard signal effects that react to state changes - you can just use the standard effect API but signalSlice does actually currently support an effects config if you want to supply it directly to the signalSlice. I'm also currently working on a PR for "actionEffects" so would love your thoughts on that if you have any: github.com/nartc/ngxtension-platform/pull/154 basically this would allow for defining side effects from streams/actions rather than just changes in state Edit: to clarify, side effects should generally be used very sparingly/only when required (toast is a reasonable use case for a side effect imo and I do the same) - for updating a title for a change in an entity you would probably just want to have that title defined declaratively so it would just automatically update itself

@@JoshuaMorony Comment made in PR.

No this is too opinionated I think to have as the approach for the course, I want to keep the course approach vanilla/focus on the fundamentals rather than teach a specific state management library - I might add a small extension to the Advanced State Management module though where I showcase different state management libraries/approaches

@@JoshuaMorony I'd really appreciate that extension. Course is great by the way 👍

For me I would otherwise have actions defined separately as subjects and reducers for those actions/other sources in the constructor (either subscribed manually or with connect), this allows defining those reducers declaratively in the state and also handles creating the actions automatically for you

@@JoshuaMorony I think there is the key difference in our thinking. I would think about using and for that reason updating the signal in an action method instead of using observables/ subjects by default Edit: to the reducer topic, I would have that in the `connect().with()` as it really fits there. So for that reason an action method would either update the signal or (and yes that is a valid argument) next the subject.

@@chaos_monster yes there is a bit of a difference there - for me the main reason for having all actions/events represented by observables/subjects is to keep everything declarative/composable - this way you just trigger the action subject, and anything that needs to react to that can be derived from that action. With callback functions as this mechanism you would need to be imperatively triggering whatever needs to happen when that action is triggered. Not trying to say this is wrong, just not my preference And as for connect.with I agree it's great, not sure if you saw but one of my recent videos is on this. signalSlice is basically just one step further to remove the disconnect between action sources/state/reducers

Yes - I've been so keen to try out Analog properly for a long time, and soon I will finally have the time to do it. I'm expecting to create a lot of content around Analog

Both ends up with the same result. Someone clicks a button and it does something.

This requires using one of the features I didn't cover in this video - essentially you are going to need two sources that react to the same action, but sources can't react to actions created internally by signalSlice. What you need to do is define an external action as a subject, and pass that action into signalSlice (you can see an example of this for my pagination$ action here: github.com/joshuamorony/angularstart-giflist/blob/signalSlice/src/app/shared/data-access/reddit.service.ts). So in your case you would have something like an external update$ action that is passed into signalSlice, and then you would have one source (e.g. updateStarted$) that pipes off of update$ to set the loading state to true as soon as the action is triggered, and another source (e.g. updateCompleted$) that also pipes off of update$ and switchMaps to the request and you can then map this source to handle setting the loading back to false/whatever else you need to do

@@JoshuaMorony Thanks for the reply, I'll try to find time to whip up an example and try this out. When you talk about 'pass that action into signalSlice', you mean add it as a property of the 'actionSources' object correct? But then how do you trigger it? By calling service.state.myAction(param)? Or by emitting on the external subject? Also, I've looked at your example, but the pagination subject used as the value of the 'pagination' actionSource, emits either string or null, not a partial of the state. Shouldn't the actionSources be mapped such that the end result they emit is a partial of the state? Finally, if you have a better way of communicating than RU-vid comments, let me know :)

Nevermind me, I'm somewhat of an idiot it would appear. With the action stream being an observable whose emissions alter the state, I can ofcourse just make sure the call to the server observable I switch to has a 'startsWith({loading: true})' to change the state as soon as the call is made...

@@RobertMulderNL ah yes sorry I responded to your question too hastily, I do the same thing here for a login action: github.com/joshuamorony/angularstart-chat/blob/signalSlice/src/app/auth/login/data-access/login.service.ts - but as for situations where you do need external subjects (i.e. you need your sources to react to actions being triggered) you can indeed trigger it by calling "service.state.myAction(param)" you don't have to do this, you could just next the subject directly, but the idea behind passing the subject to signal slice is so that all of your actions can be available on the state object, rather than having some internal/some external.

@@JoshuaMorony thanks again for the quick reply. These external subjects (like the pagination$ in your reddit example) do not have a direct way of updating the state like other actions do, correct? If you do want them to somehow manipulate the state they must at some point lead back to a source right?

This hasn't been developed in opposition to any other library, the motivation for this was basically: 1) Signals are new and are going to impact the way we manage state 2) I landed on an approach I like for declarative Signals + RxJS state management where we have data sources/events represented by observables which are at some point used to update a state signal 3) There is boilerplate involved with this approach, so I want a utility that essentially keeps the same idea but removes as much boilerplate as possible and that's what signalSlice is It's essentially a single function that can be used to create a "slice" of declarative state using RxJS + Signals, it is much more a simple state management utility than a more full featured state management library.

I will always unsubscribe as a rule even if in a particular situation it isn't technically required. But in the case of http requests yes it is still mostly necessary anyway, consequences might be rarer but you can run into trouble with situations where a component/service is destroyed but an HTTP request hasn't finished yet and without some kind of unsubscribe strategy it will still complete which can cause problems

@@JoshuaMorony problems like a disconnection between the state of the app and the ui ?

This is really more intended for people who are using or want to use a declarative style of coding in Angular - this state management utility is a natural/easy extension in that context, but outside of that context it is a big paradigm shift and I wouldn't expect people to use this utility in that case Edit: Forgot to address the signals vs RxJS question - a lot of my videos recently have talked about this but to put it briefly you will still need RxJS (or some equivalent) to write code declaratively even with signals

​@@JoshuaMorony I also went into the RxJs rabbit hole myself, and for frontend development, I think it's not worth it the whole declarative style thing; This idea that everything in an application is a stream, including something as simple clicking a button, it's just not necessary. For me it's just over-abstraction and over-engineering, it's just not good design. The code of my app had far more bugs caused by my team misunderstanding how RxJS works. It's just a very advanced concept that developers struggle with, even senior ones. I've switched my team to async/await code which is widely adopted everywhere for years outside the Angular ecosystem, and we are way more productive this way. We don't need RxJs for doing HTTP, plain async/await is a way better fit, and it's even recommended by the Angular team in their latest beginner tutorial on RU-vid. These days we only use RxJs if absolutely necessary, and the code just feels way better this way.

Will definitely improve this - the docs atm have basically been added piece meal as new features were added

Me too, I think the full vanilla approach is fine and I think the sacrifice in "declarative-ness" there has very little impact

Agreed, but it is interesting to see how close you can get to full declarative!

You could but it leads to a different style/more imperative code - if it's a method then that method needs to imperatively trigger whatever needs to happen when that action is triggered, whereas with the subject approach you are essentially just broadcasting that the action happened and whatever needs to react to it can do so declaratively