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 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.
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.
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?
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
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.
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?
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.