DEV Community

Why I didn't just use NgRx, NGXS or Subjects in a Service

Mike Pearson on April 07, 2021

I am about to criticize some beloved state management solutions, and this is bound to upset some people. Great people have worked hard on these, an...

Read full post

timsar2 • Jun 17 '21 • Edited

Is it ready to use in production?
And what about updating repo?

Mike Pearson • Jun 17 '21

I'm currently helping a team upgrade from AngularJS to Angular and haven't had time recently, but in the next couple of weeks I will be getting back to StateAdapt, and I should have several months to work on it and write about it. I was about to release documentation for the adapter library and a couple of adapters to start with, and then version 1.0 shortly after that. Nothing fundamental will be changing though I don't think, so if you feel like using it in production, I don't see an issue with it. Check out the website to make sure you've got the core concepts down and let me know if you have questions.

timsar2 • Nov 9 '22

Two years later, I'm still looking for version 1.0 StateAdapt :D

Mike Pearson • Nov 9 '22

Yeah...

I'm releasing an article in 16 hours explaining the most recent bug I found. It almost caused a fundamental API change, so I'm glad I found it before 1.0.

But I've implemented it in 20-30 projects now and feel really good about it after this last bugfix. I have a bunch of unit tests covering everything I've found. I haven't used in in a humongous project yet, but I've used it in medium-sized projects and my confidence in it is pretty high. The last project I did was what made me discover the last major bug I think, so doing these projects has been valuable.

Here's the last official issue required for 1.0 github.com/state-adapt/state-adapt...

But my unofficial todo list currently looks like this

It will probably take an extra week, and I'm thinking of waiting for Angular 15 to release 1.0 as well, but not sure on that. So, I'll say either 11/22 or when Angular 15 comes out.

Mike Pearson • Feb 5 '23

The Angular library is ready to use in production I think.

1.0 is only delayed now because I already had a React implementation and wanted to test it for 1.0 to release at the same time as the Angular library.

Just make sure @state-adapt/core @state-adapt/rxjs @state-adapt/angular are all on the same version. There was an issue with ng-packagr that caused one of them to have a stupid peer dependency. node.js 14 had an issue with it with npm install, but I think everything else is fine.

timsar2 • Feb 7 '23

Congratulations, Can you please make an example of how to use it without zonejs like rx-angular.
Rx-angular has template library and it's missing in other, is it worth to use both stateAdapt and rx-angular template together?

Mike Pearson • Feb 7 '23

Yes, use them both. No reason to re-implement RxAngular's innovations for templates.

This is an example of Todo MVC that I forked from the RxAngular implementation, which I believe is zoneless. It's a 3-month old example, but I don't think any API I used has changed. github.com/mfp22/state-adapt-todo-mvc

The next couple of days will be finishing up documentation. I'll comment again when the new docs site is live.

Mike Pearson • Feb 7 '23

And here's a diff between the RxState and StateAdapt implementations
github.com/edbzn/rx-angular-todo-m...

timsar2 • Feb 19 '23 • Edited

I run it, new todo does not added to the list

Mike Pearson • Feb 19 '23

Any console errors?

timsar2 • Feb 20 '23 • Edited

I'm sorry It was my mistake, It's working right.

Richard Davenport • Apr 13 '21

I think it's fantastic that you've been trying to make state management easier and I really like what you're doing. I found NGXS to be much easier than NgRx and the concept count much lower. Less boilerplate and less RxJs code, which is good for most people, especially newer devs. I would say that what you've created looks really similar to some plugins I've tried in NGXS. Namely github.com/ngxs-labs/emitter

I actually don't think managing deep state trees is that difficult if you use State Operators: ngxs.io/advanced/operators#state-o....

I also think that having actions be asynchronous is a good thing, not a bad thing. You have less side effects this way (at least how I understand it).

I just found this article as well: dev.to/this-is-angular/why-and-how... and this looks very promising. Forms is a PITA and needs to be solved better in angular. Maybe state adapt could solve forms in a better way!

I will also say NGXS has another great plugin that allows you to separate your action handlers and move them to a simple more unit testable pure function, so that certainly helps with being more DRY and could be easier to update state.

My last comment would be that I know NGXS has some interesting things in the works, like local state.

Mike Pearson • Apr 15 '21 • Edited

I think the main difference between my philosophy and that of NGXS is I actually think the more RxJS code, the better. I believe it achieves much better separation of concerns. I believe reactive programming is the future of web development, and a lot of the friction we are feeling now is more from our old habits and ways of thinking than any inherent conceptual difficulty with RxJS. The first thing most people do with a click event is write a callback function, and that's the first sign they're thinking imperatively still. It's no wonder they think reactive programming is extra, because they are not letting go of imperative muscle-memory so they have to carry both mindsets at the same time while programming. Whichever is the new thing will take the blame for being harder.

I think of boilerplate as stuff that could be generated with schematics. Actually, if you can generate code, it's probably not DRY. I think NGXS reduces new concepts but not necessarily boilerplate, since there is still a pull towards schematics. But it is just subjective as to whether you see value in reactive style vs imperative, so what is boilerplate and what is valuable code is subjective as well.

I am unfamiliar with many NGXS plugins. I do not think that plugin is very similar to my thing though. It looks like the event source has the responsibility to know what state is supposed to change.

I look forward to seeing how NGXS progresses over time. Since I think FRP is basically inevitable, I imagine we will see NGXS plugins that rely more and more on RxJS. I could be wrong, but I hope I'm not :) My personal experience is just that life is much simpler in the reactive paradigm once you cross :)

Edit: Oh, and thanks for commenting! I really appreciate hearing your thoughts.

Richard Davenport • Apr 20 '21

I completely agree about reactive programming. That's one of the reasons I got away from React. Hilariously named since it isn't in fact reactive...
I love RxJs and feel really comfortable with it. I just have seen too many people overuse and abuse it. For example, using a combination of several operators in one stream when it turns out you could use a couple different subjects and a couple of operators. Stuff that takes a lot of experience to learn.

If you have some slightly larger examples of using StateAdapt I would love to see them. The biggest take away I have from looking at StateAdapt is easy state changes, not changing large state trees. Does that seem right to you?

Mike Pearson • Apr 21 '21

React does not react very precisely, and when you involve asynchronicity you move into an imperative style. Sometimes I would want to call it OverReact, other times AlmostReact. Still, when you add RxJS it can be nice with hooks and not having to deal with | async.

I think StateAdapt shines most with large state trees, actually. You can use the same source and also select across several mini-stores, so I see no issue in scaling the pattern at all. You can define it in a service and reuse it anywhere, too. It just feels more like local state, because you are not describing a giant, global tree structure up front. But even in NgRx you treat each slice of state independently, so for the sake of devtools it seems unnecessary to me to force everyone to think about a global object at all while developing. Behind the scenes it get combined into one, but that is for dev tool purposes and shouldn't affect the development experience.

You are right, I need some less trivial examples. I think the next one I do might be something like a shopping cart demo, where you have filters, a filtered list, and a list of items in a cart. Something like that. I wish I could convert a large, real-world project to StateAdapt and write a big post about it, but it would need to be publicly visible, so none of the large projects I've worked on would work. But I think if I write enough small-medium examples, they can add up.

Xucong ZHAN • May 26 '21

Thanks for sharing. I am exploring alternative state management solutions to NgRx and I would definitely take a look at your library.
Just out of curiosity, do you happen to come across rx-angular/state? I haven't done any in-depth exploration yet but looking at the basic demos, it does feel kinda similar. Correct me if I am wrong and would appreciate your insights. Thanks!

Florian Spier • Apr 14 '21 • Edited

Was looking at the NgRx example (stackblitz.com/edit/state-adapt-ngrx)... Can you explain what the benefit of state-adapt is in comparison to the native NgRx implementation?:

countAdapter looks like a nicer reducer... it's cool that the reducer is just an Object. (stackblitz.com/edit/state-adapt-ng...)

Instead of creating NgRx actions and dispatching them to one action stream you create many "Sources" and use next on them.

state-adapt looks like having just another syntax for actions, dispatching actions and reducers. Am I missing something?

I played little bit with the example and found it a bit tedious to repeat e.g. the increment key inside this.adapt.initGet and createAdapter.

At least that given NgRx example does not look like less boilerplate to me... you still have some kind of actions (Sources) and dispatch them (Source.next) and some kind of reducer (the createAdapter Object).

Mike Pearson • Apr 15 '21

Hey thanks for checking it out!

I actually think of the object here as the reducer:

{
  increment: this.increment$,
  double: this.double$,
  reset: this.reset$
}

If you find it tedious to repeat increment then it seems like you would very much love something that is "just another syntax" if it was minimal. StateAdapt is 60% the non-business logic code in NgRx and I bet similar for NGXS. Which one of these looks more tedious? NgRx on the left, StateAdapt on the right:

(If you want to read more about that example it is from my last article).

I think minimalism is important, but I took it as far as I could before it would take value away from the pattern itself. The decoupling of state patterns from specific instances of state makes it worth repeating things like increment. It would be like complaining that with components you need to define an input in one place @Input() data: Data; and then type data again when you use the component: <app-component [data]="data"></app-component>. That isn't tedious, is it? Because you know that the component is reusable. Do you not see value in the reuse of state adapters?

It does a couple of things that are impossible in NgRx, but they don't matter very much to me. I don't see myself instantiating state dynamically inside components inside an *ngFor, for example. Maybe somebody will do it though.

When I say "boilerplate" I am not referring to separation of concerns. Those are good. I am referring to all the extra syntax where you want schematics to help you pretend that Angular isn't making you write and manage non-DRY code. StateAdapt has extremely little boilerplate.