Comparison to other solutions

[maku]

I am looking for a signal-based solution for state management.

That's why I primarily look at https://www.npmjs.com/package/@ngrx/signals and also ngx-signal-state. I would be interested to know the reason why ngx-signal-state was created and how it differs from @ngrx/signals.

In general I would think that ngx-signal-state is easier to use and @ngrx/signals places a lot of emphasis on composability and a functional approach. In general, I'm more of a fan of a class-based approach because it's simply clearer for me personally.

How do other developers see this?

[simplifiedcourses]

Thank you for raising this. I'm eager to get the feedback of the community on this.

Let me explain why I created this:

• I think most of the frameworks and libraries are walking away from the reducer pattern and I consider it a lot of boilerplate and effort to get something simple done. For that reason I created this thing called ObservableState last year.
• When signals became a thing, I saw that a lot of principles behind observable state that went hand-in-hand with signals (initial state, removing RxJS knowhow, treating state asynchronously)
• That's why I wrote Signal state with the same simplified api as ObservableState. We use it at my current client where I am frontend architect (DHL global aviation) and the developers are really happy with it. That's when I decided to open-source it.
• I would even recommend copy pasting the code and owning it yourself, it's that simple! The code shouldn't be complex and in my personal opinion alternative state management frameworks tend to become big and more complex. But that's just my gut feeling
• I personally think it simplifies state management in an opinionated way.

I hope this helps