I totally agree with this. I learned NgRx because I had the feeling it would help me become more disciplined and it worked. It also finally helped me fully understand RxJS. Once you start using observables more extensively you start to think of ways all the different RxJS operators can help you.
Excellent intro and metaphor around why to use a redux / state management library. Most apps start off small but can grow into a complicated mess over time without state management, especially in a team setting
I've seen applications fail, and it was mostly because of this. They were scaling up and had such a big service of subjects/ behaviour subjects to handle that it got very dirty. I was very new to Web dev before and started with angular so I didn't even know state management existed, then I started doing some vue development and understood how good it is having a store for scaling . Excellent video!
I just watched this twice so I apologize if I missed something. To me, it seems as though many coding content creators saying “do this - its the best practice” What does this mean? Yes, you're comparing NgRx to RxJs but you don’t really expand on your analogies. For example, the analogy you make @ 1:00 i.e. “…dark and misty forest…logs to trip over.” (In regards to simpler state management - I assume you meant RxJS). What does this mean exactly? Exactly how does the code get messy with RxJs and exactly *how* is this fixed in NgRx? A code comparison of the this situation in both libraries would be great. I say the above with all due respect. I'm a subscriber to your channel and I do appreciate you offering this content for free.
To be clear, this isn't an "RxJS vs NgRx" thing - I'm suggesting NgRx as a way to learn RxJS. The point I'm trying to make here (maybe not well) is that there is a lot you can do with RxJS and it is very powerful - if you aren't experienced with it it's easy to get something wrong that might be detrimental (for example, the most natural approach for people might be to nest multiple subscribes within each other, when really the "best" approach would be to use an operator like concatMap, but that isn't obvious unless you already know about it), there's a lot to learn about RxJS. Using NgRx is kind of like having a very opinionated structure on top of just RxJS, so although it is complex there is a very clear set of guidelines/advice/recommendations for you to follow. So, code can get messy with RxJS if you don't have a good understanding of how it works. Learning NgRx can help with this, because it gives you an opinionated framework to work with RxJS within, and helps gives you a sense of how you "should" use RxJS even when not using NgRx.
@@JoshuaMorony Thank you for your reply. Again, a video showing a code comparison to a real-world or a common, messy RxJs implementation which is fixed by NgRx would be greatly anticipated by yours truly if you're up for it.
@@devx4175 I'm not sure that a video like that would make sense - I could show some "bad" RxJS code (e.g. multiple nested subscribes) and then show how to write better RxJS code, but I don't think it would make sense to show how NgRx would "fix" it since its a drastically different approach. The point I'm making is that if you took the time to learn NgRx, then you would learn a lot about how to use RxJS well, so that when you come to that "bad" RxJS example with multiple nested subscribes, you would know how to handle it better because you will have learned about operators and concatMap and so on through using NgRx.
@@JoshuaMorony Ok. I’m hoping the how and why NgRx will optimize my state management will become apparent as I use It. At this point I can only suspect NgRx will optimize an existing RxJS-only project. I can’t yet go to the client of this project and tell him “Here’s exactly why you should spend the $$$ to switch to NgRx.” All this boilerplate and what have we accomplished? One thing that pops into mind is that one can look at the history of the state. At least you can in Redux.
@@devx4175 Perhaps I didn't do a good job of making this video clear - I wouldn't recommend that most people switch to NgRx Store, for a lot of projects it is going to be far more complex/powerful than what you need (something like NgRx Component Store is probably closer to what most people need for state). I think using NgRx Store is 1) a good way to learn important/advanced RxJS concepts 2) a good default because it's never going to be the "wrong" choice - NgRx could handle any situation simple or complex - but still you probably don't *need* NgRx Store. If I could boil down my main thoughts here into a simple sentence: NgRx Store is a great thing to use if you want to learn/get better with RxJS and Angular, and also most projects don't need NgRx store (although its never going to be the wrong choice, it might just take more time/effort to build than an alternative). Once you get good at NgRx Store, you will probably stop using it most places, because now you have the knowledge of how to use RxJS well, and you can identify situations where you might actually benefit from NgRx Store.
I can't understand why there's no tutorial or review aboutNGXS, the Angular way of state management: DI, observables, type driven, no boiler code,... It seems the "big ones" community opinion leaders, turned their backs against that tool, probably due to some disagreement with the creators, that lead to a harmful ignorance of all the Angular coders. I've been using this tool from its very first version and I laugh at every presentation that tries to drive us to NGRX.
11 files for a todo 🤯 I do angular I do 3 files, bouta ditch scss for tailwind make it two per component ez pz. Ngrx? State management? The only global state I have in my app is the screen breakpoint value. Runs like butter.
What is the actual problem that NGRX is solving, what a Subject cannot do? In a Service I also can update stored values and let components subscribe to that. Without that amount of boilerplate code. Please don't hate me, I just want to understand what the actual benefit is. Can someone explain?
Just to be clear, I'm giving a case as to why it is a good idea to learn NgRx Store as a beginner because it is usually discouraged. The actual cases where I would recommend NgRx Store in a general sense are far fewer. It's not a perfect analogy, but using NgRx Store instead of just a Subject is like using Angular instead of just JavaScript (or a simpler framework). You can probably do what you need without NgRx Store, but its benefits are in its well defined/highly opinionated/predictable structure that can handle highly complex situations. It gives you opinions on how you should manage state in a way that scales, and gives you all the tools you need to do it (which is similar in spirit to Angular). It might not always be necessary (again, like Angular) but it's going to be able to handle whatever job you throw at it (again, like Angular).
In order to understand what problem is solved here, you have to look at Ngrx not as a library but as a pattern that it implements. The pattern in frontend is called Redux, basically a copycat from CQRS. Read why and where it is used. Martin Fowler described it well. Technically, absolutely same target can be achieved by using BehaviorSubjects (I mean, even Ngrx is built on top of BehaviorSubjects 😄). Small apps will definitely benefit from BehaviorSubject-based code as it is a lot easier to review and trace! With large apps, where you have 3+ teams working on different modules and inter-module data dependencies things get fancier. Lots of services, lots of API calls, lots of data that is transformed here and there. Sometimes one module has to expose its data, i.e. BehaviorSubjects, to other modules, react on data change and certain app events. Then you have lazy loaded modules, then maybe dump your state to LocalStorage and reload it because your app was converted to PWA... Again, technically all these problems are absolutely solvable using a standard service pattern and BehaviorSubjects BUT it gets a bit messy. In my opinion, here Ngrx helps to keep some order and structure code better (of course, as always there are some tradeoffs). Joshua did a great job but it is not so easy to show the difference between Ngrx and BehaviorSubject unless you scale his tiny app 1000x times, implement it using both paradigms and directly compare the code.
Nothing will really be obsolete with signals, but likely (certainly really) people will start adopting new patterns with signals. These older patterns are still useful to know though, because it will be a little while until the signal stuff is settled, and the patterns are likely to be similar
Coudn't agree more , I have been coding angular for 5 years and I spent 2 years begrudgingly using NGRX on a massive Angular project and I still don't see the point or necessity, if you are using proper domain driven design, with clean built for purpose components, dtos and services you shouldn't be having problems debugging or managing state. In fact it only creates unnecessary complexity making a domain/ feature harder to understand and navigate leading to Spaghetti code when ever new features get introduced, can not tell how much time is spent hunting bugs by trying to track down the very component or effect that triggers reducer. if you need to keep state for something specific yes then maybe use NGRX but I am very sure the same thing can be achieved much easier by using a mediatR pattern, but you don't need to store all the form data somewhere to hand it over to a service when your component is already fully capable of doing so by itself, in React it makes sense because data most likely has to be bubbled up from innermost components but angular has 2 way data binding.
Eppure continua a non convincermi. Troppo boiler code. Ogni entità che creo devo creare un file di action, selector, effect, e reducers. Già in un esempio così banale si vede come aumenta il codice da scrivere, figuriamoci in un applicazione complessa!
Yes you start with much boilerplate - but you gain when your app becomes big - because you have a clear model how you handle state - it is just a repetion for each new feature you add in your application and you can use the ngrx schematics cli possibilities to automate the feature creation - with one command on the cli you can create a full coded feature with CRUD code.
This is straight up, overengineering, its like 5-6 files more, not only that but the logic is really messy. like, what it could be done in 7-8 files with services converts to 25 files with this thing, not only that but readability is way worst, also is more tiring to search in different files the definitions of the reducers and all that, instead of using a service where everything is just readable and understandable. it just overcomplicated, I don't get it. I've been reading about you saying that it makes you learn rxjs well, and fine, I get it, It may help you became better in rxjs, but man, using this professionally for, for example a Web app or something if you already now rxjs seems like overcomplicating things, if is just to learn, well then its fine, but using this to write actual software, to me, makes no sense.
Join my mailing list for more exclusive content and access to the archive of my private tips of the week: mobirony.ck.page/4a331b9076
I totally agree with this. I learned NgRx because I had the feeling it would help me become more disciplined and it worked. It also finally helped me fully understand RxJS. Once you start using observables more extensively you start to think of ways all the different RxJS operators can help you.
Excellent intro and metaphor around why to use a redux / state management library. Most apps start off small but can grow into a complicated mess over time without state management, especially in a team setting
I've seen applications fail, and it was mostly because of this. They were scaling up and had such a big service of subjects/ behaviour subjects to handle that it got very dirty. I was very new to Web dev before and started with angular so I didn't even know state management existed, then I started doing some vue development and understood how good it is having a store for scaling . Excellent video!
2 years passed. Did you change your mind or do you still use ngrx ?
NgRx is one of those things I couldn't find a good tutorial for or a reason with an example to use it. Awaiting your next video
Nice video! Also a fair comparison of NgRx and Service with a Subject approaches 👍🏿
thx Josh. great intro on giving NgRx a consideration for use in Angular.
Nice introduction on the reasons why choosing NgRx. Thanks.
I’ve made 10 spas now and still haven’t found a need for ngrx
A bit strange for me, to hear that redux pattern is difficult. I coming to angular from world of react.
It is very easy and straitforward
I just watched this twice so I apologize if I missed something.
To me, it seems as though many coding content creators saying “do this - its the best practice” What does this mean?
Yes, you're comparing NgRx to RxJs but you don’t really expand on your analogies.
For example, the analogy you make @ 1:00 i.e. “…dark and misty forest…logs to trip over.” (In regards to simpler state management - I assume you meant RxJS). What does this mean exactly?
Exactly how does the code get messy with RxJs and exactly *how* is this fixed in NgRx? A code comparison of the this situation in both libraries would be great.
I say the above with all due respect. I'm a subscriber to your channel and I do appreciate you offering this content for free.
To be clear, this isn't an "RxJS vs NgRx" thing - I'm suggesting NgRx as a way to learn RxJS.
The point I'm trying to make here (maybe not well) is that there is a lot you can do with RxJS and it is very powerful - if you aren't experienced with it it's easy to get something wrong that might be detrimental (for example, the most natural approach for people might be to nest multiple subscribes within each other, when really the "best" approach would be to use an operator like concatMap, but that isn't obvious unless you already know about it), there's a lot to learn about RxJS. Using NgRx is kind of like having a very opinionated structure on top of just RxJS, so although it is complex there is a very clear set of guidelines/advice/recommendations for you to follow.
So, code can get messy with RxJS if you don't have a good understanding of how it works. Learning NgRx can help with this, because it gives you an opinionated framework to work with RxJS within, and helps gives you a sense of how you "should" use RxJS even when not using NgRx.
@@JoshuaMorony Thank you for your reply. Again, a video showing a code comparison to a real-world or a common, messy RxJs implementation which is fixed by NgRx would be greatly anticipated by yours truly if you're up for it.
@@devx4175 I'm not sure that a video like that would make sense - I could show some "bad" RxJS code (e.g. multiple nested subscribes) and then show how to write better RxJS code, but I don't think it would make sense to show how NgRx would "fix" it since its a drastically different approach.
The point I'm making is that if you took the time to learn NgRx, then you would learn a lot about how to use RxJS well, so that when you come to that "bad" RxJS example with multiple nested subscribes, you would know how to handle it better because you will have learned about operators and concatMap and so on through using NgRx.
@@JoshuaMorony Ok. I’m hoping the how and why NgRx will optimize my state management will become apparent as I use It. At this point I can only suspect NgRx will optimize an existing RxJS-only project.
I can’t yet go to the client of this project and tell him
“Here’s exactly why you should spend the $$$ to switch to NgRx.”
All this boilerplate and what have we accomplished? One thing that pops into mind is that one can look at the history of the state. At least you can in Redux.
@@devx4175 Perhaps I didn't do a good job of making this video clear - I wouldn't recommend that most people switch to NgRx Store, for a lot of projects it is going to be far more complex/powerful than what you need (something like NgRx Component Store is probably closer to what most people need for state). I think using NgRx Store is 1) a good way to learn important/advanced RxJS concepts 2) a good default because it's never going to be the "wrong" choice - NgRx could handle any situation simple or complex - but still you probably don't *need* NgRx Store.
If I could boil down my main thoughts here into a simple sentence: NgRx Store is a great thing to use if you want to learn/get better with RxJS and Angular, and also most projects don't need NgRx store (although its never going to be the wrong choice, it might just take more time/effort to build than an alternative). Once you get good at NgRx Store, you will probably stop using it most places, because now you have the knowledge of how to use RxJS well, and you can identify situations where you might actually benefit from NgRx Store.
Amazing video, keep on the good work🔥🔥
Superb intro. I totally agree.
Hey mate, can you do a comparison of Akita and NGRX video and share your opinion when to use what and why. Thank you!
Waiting for your next video on ngrx 🤞
I can't understand why there's no tutorial or review aboutNGXS, the Angular way of state management: DI, observables, type driven, no boiler code,...
It seems the "big ones" community opinion leaders, turned their backs against that tool, probably due to some disagreement with the creators, that lead to a harmful ignorance of all the Angular coders.
I've been using this tool from its very first version and I laugh at every presentation that tries to drive us to NGRX.
Thanks for pointing out NGXS
What if you are a React dev with prior Redux coming into Angular?
11 files for a todo 🤯
I do angular I do 3 files, bouta ditch scss for tailwind make it two per component ez pz. Ngrx? State management? The only global state I have in my app is the screen breakpoint value. Runs like butter.
What is the actual problem that NGRX is solving, what a Subject cannot do?
In a Service I also can update stored values and let components subscribe to that. Without that amount of boilerplate code.
Please don't hate me, I just want to understand what the actual benefit is. Can someone explain?
Just to be clear, I'm giving a case as to why it is a good idea to learn NgRx Store as a beginner because it is usually discouraged. The actual cases where I would recommend NgRx Store in a general sense are far fewer. It's not a perfect analogy, but using NgRx Store instead of just a Subject is like using Angular instead of just JavaScript (or a simpler framework). You can probably do what you need without NgRx Store, but its benefits are in its well defined/highly opinionated/predictable structure that can handle highly complex situations. It gives you opinions on how you should manage state in a way that scales, and gives you all the tools you need to do it (which is similar in spirit to Angular). It might not always be necessary (again, like Angular) but it's going to be able to handle whatever job you throw at it (again, like Angular).
In order to understand what problem is solved here, you have to look at Ngrx not as a library but as a pattern that it implements. The pattern in frontend is called Redux, basically a copycat from CQRS. Read why and where it is used. Martin Fowler described it well.
Technically, absolutely same target can be achieved by using BehaviorSubjects (I mean, even Ngrx is built on top of BehaviorSubjects 😄). Small apps will definitely benefit from BehaviorSubject-based code as it is a lot easier to review and trace! With large apps, where you have 3+ teams working on different modules and inter-module data dependencies things get fancier. Lots of services, lots of API calls, lots of data that is transformed here and there. Sometimes one module has to expose its data, i.e. BehaviorSubjects, to other modules, react on data change and certain app events. Then you have lazy loaded modules, then maybe dump your state to LocalStorage and reload it because your app was converted to PWA... Again, technically all these problems are absolutely solvable using a standard service pattern and BehaviorSubjects BUT it gets a bit messy. In my opinion, here Ngrx helps to keep some order and structure code better (of course, as always there are some tradeoffs).
Joshua did a great job but it is not so easy to show the difference between Ngrx and BehaviorSubject unless you scale his tiny app 1000x times, implement it using both paradigms and directly compare the code.
My todos feature directory looks like that:
todos
page
components
list
form
details
state
actions
reducers
selectors
service
effects
routes
Is this obsolete now with Angular Signals?
Nothing will really be obsolete with signals, but likely (certainly really) people will start adopting new patterns with signals. These older patterns are still useful to know though, because it will be a little while until the signal stuff is settled, and the patterns are likely to be similar
Ngrx solves the problem that doesn't exist in Angular...
Exist in anglar
Coudn't agree more , I have been coding angular for 5 years and I spent 2 years begrudgingly using NGRX on a massive Angular project and I still don't see the point or necessity, if you are using proper domain driven design, with clean built for purpose components, dtos and services you shouldn't be having problems debugging or managing state. In fact it only creates unnecessary complexity making a domain/ feature harder to understand and navigate leading to Spaghetti code when ever new features get introduced, can not tell how much time is spent hunting bugs by trying to track down the very component or effect that triggers reducer. if you need to keep state for something specific yes then maybe use NGRX but I am very sure the same thing can be achieved much easier by using a mediatR pattern, but you don't need to store all the form data somewhere to hand it over to a service when your component is already fully capable of doing so by itself, in React it makes sense because data most likely has to be bubbled up from innermost components but angular has 2 way data binding.
Any state management for ionic angular mobile app?
The example application in this video is an Ionic/Angular app :)
Eppure continua a non convincermi. Troppo boiler code. Ogni entità che creo devo creare un file di action, selector, effect, e reducers. Già in un esempio così banale si vede come aumenta il codice da scrivere, figuriamoci in un applicazione complessa!
Yes you start with much boilerplate - but you gain when your app becomes big - because you have a clear model how you handle state - it is just a repetion for each new feature you add in your application and you can use the ngrx schematics cli possibilities to automate the feature creation - with one command on the cli you can create a full coded feature with CRUD code.
This is straight up, overengineering, its like 5-6 files more, not only that but the logic is really messy. like, what it could be done in 7-8 files with services converts to 25 files with this thing, not only that but readability is way worst, also is more tiring to search in different files the definitions of the reducers and all that, instead of using a service where everything is just readable and understandable. it just overcomplicated, I don't get it.
I've been reading about you saying that it makes you learn rxjs well, and fine, I get it, It may help you became better in rxjs, but man, using this professionally for, for example a Web app or something if you already now rxjs seems like overcomplicating things, if is just to learn, well then its fine, but using this to write actual software, to me, makes no sense.