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 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.