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

[Florian Spier]

Was looking at the NgRx example (stackblitz.com/edit/state-adapt-ngrx)... Can you explain what the benefit of state-adapt is in comparison to the native NgRx implementation?:

countAdapter looks like a nicer reducer... it's cool that the reducer is just an Object. (stackblitz.com/edit/state-adapt-ng...)

Instead of creating NgRx actions and dispatching them to one action stream you create many "Sources" and use next on them.

state-adapt looks like having just another syntax for actions, dispatching actions and reducers. Am I missing something?

I played little bit with the example and found it a bit tedious to repeat e.g. the increment key inside this.adapt.initGet and createAdapter.

At least that given NgRx example does not look like less boilerplate to me... you still have some kind of actions (Sources) and dispatch them (Source.next) and some kind of reducer (the createAdapter Object).

[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$
}

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:

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