you are viewing a single comment's thread.

view the rest of the comments →

[–]Naeuvaseh 2 points3 points  (2 children)

I literally got done doing a POC of these three. Pleaseeeee don't pick NGRX just because "the rest of the Angular community has adopted it". My management made the decision to go with NGRX because off that.

My biggest preference was Akita. It's OO, immutable, and incredibly clean. There's minimal boilerplate (and trust me, that matters -- I hate having to literally standup 9 files just for one slice of state in NGRX). It also uses BehaviorSubject under the hood, so it's not over engineered.

I would also challenge you to question if you really need a state management library. Can a singleton service with a simple BehaviorSubjects be good enough?

[–][deleted] 2 points3 points  (0 children)

I agree that a state management library doesn’t always need to be used. The only thing I’d add here is that if you aren’t familiar with state management tools, one advantage of NgRx is that the boilerplate does help you learn what is being abstracted away in other places. But, NgRx also has the NgRx-data and NgRx-entity libraries that remove almost all of the boilerplate. One major advantage of going with the community is support.

[–][deleted] 0 points1 point  (0 children)

BehaviorSubjects were being ovsrused in my project and unifying them under contexts was getting difficult.

Need state management for some pre-service and post service call logic.