DEV Community

Discussion on: Why I didn't just use NgRx, NGXS or Subjects in a Service

Collapse
 
mfp22 profile image
Mike Pearson

Hey thanks for checking it out!

I actually think of the object here as the reducer:

{
  increment: this.increment$,
  double: this.double$,
  reset: this.reset$
}
Enter fullscreen mode Exit fullscreen mode

If you find it tedious to repeat increment then it seems like you would very much love something that is "just another syntax" if it was minimal. StateAdapt is 60% the non-business logic code in NgRx and I bet similar for NGXS. Which one of these looks more tedious? NgRx on the left, StateAdapt on the right:
NgRx StateAdapt Diff

(If you want to read more about that example it is from my last article).

I think minimalism is important, but I took it as far as I could before it would take value away from the pattern itself. The decoupling of state patterns from specific instances of state makes it worth repeating things like increment. It would be like complaining that with components you need to define an input in one place @Input() data: Data; and then type data again when you use the component: <app-component [data]="data"></app-component>. That isn't tedious, is it? Because you know that the component is reusable. Do you not see value in the reuse of state adapters?

It does a couple of things that are impossible in NgRx, but they don't matter very much to me. I don't see myself instantiating state dynamically inside components inside an *ngFor, for example. Maybe somebody will do it though.

When I say "boilerplate" I am not referring to separation of concerns. Those are good. I am referring to all the extra syntax where you want schematics to help you pretend that Angular isn't making you write and manage non-DRY code. StateAdapt has extremely little boilerplate.