We were tasked with bringing an Angular/NgRx application up to date at work, and it was quite out of date. As the only person on the team with prior NgRx experience (it was quite minor though), I was volunteered to take responsibility for that portion of the project.
I quickly learned the previous devs had no idea what they were doing. They used the libraries but appeared to have no conception of what the actual pattern was, and so were getting essentially zero of the benefits.
I tried to make some piecemeal refactors, but I gave up on that approach. Everything was too tangled together, too reliant on other portions of the system, that I had no choice but to completely rewrite all aspects of the state management system.
It took me over a month, and I came away with a diminished opinion of NgRx. I think without context, it's good (but oh my, the boilerplate; I used to pooh-pooh people who complained about it but after thousands and thousands of lines of it, I have now joined their ranks). The problem is that ...
(a) it is likely significantly different than anything a standard team has used before, and highly complex;
(b) it provides ample footguns -- following the pattern is just as important as using the libraries, and this requires self-control that some don't have (not to mention actual knowledge of the pattern),
(c) therefore there seems to be a high likelihood of inexperienced teams building complex state management systems that don't provide any of the guarantees you want from NgRx and which become impossible to maintain.
I'm a data point of one, but that's been my experience with the Redux pattern/NgRx at work.
I was in a similar situation, and ultimately decided to reimplement the state management using NGXS. Fortunately the app was relatively small at that point, but I found that it held the developers hands a bit more, which lead to significantly more readable code.
Things can still get tangled up once you start using "ofActionDispatched" lifecycle handlers, but overall I found them to be far more manageable over time than NGXS.
I quickly learned the previous devs had no idea what they were doing. They used the libraries but appeared to have no conception of what the actual pattern was, and so were getting essentially zero of the benefits.
I tried to make some piecemeal refactors, but I gave up on that approach. Everything was too tangled together, too reliant on other portions of the system, that I had no choice but to completely rewrite all aspects of the state management system.
It took me over a month, and I came away with a diminished opinion of NgRx. I think without context, it's good (but oh my, the boilerplate; I used to pooh-pooh people who complained about it but after thousands and thousands of lines of it, I have now joined their ranks). The problem is that ... (a) it is likely significantly different than anything a standard team has used before, and highly complex; (b) it provides ample footguns -- following the pattern is just as important as using the libraries, and this requires self-control that some don't have (not to mention actual knowledge of the pattern), (c) therefore there seems to be a high likelihood of inexperienced teams building complex state management systems that don't provide any of the guarantees you want from NgRx and which become impossible to maintain.
I'm a data point of one, but that's been my experience with the Redux pattern/NgRx at work.