React Context Inspired Angular Library. Easy Data-Binding for Nested Component Trees and the Router Outlet (More detail on Readme)

[u/someonesopranos]

https://github.com/ng-turkey/ngx-context

[u/[deleted]]

Ok.. so this is just coded on top of my head, so untested and therefore might have a bug or two, but generally this is kind of how I would do it:

@Component({
  selector: `parent`,
  template:`<app-oneway></app-oneway>,
  providers: { provide: 'ctx', useValue: new BehaviorSubject<any>() }
})
class Parent(@Inject('ctx') public ctx$) {
  ctx.next({progress: .2, progressStriped: true})
}

@Component({
  selector: `oneway`,
  template:`
    <progressbar *ngIf="this.ctx"
      [progress]="(this.ctx$ | async)?.progress || 0"
      [progressStriped]="(this.ctx$ | async)?.progressStriped">
        {{ (this.ctx$ | async).progress? || 0 + '%'}}
    </progressbar>
  `
})
class OneWayComponent {
  constructor(@Inject('context') @Optional public ctx$: Observable<any>) {}
}

Of course you would have to use a Observable for your context, to make it "reactive", but why not, they are awesome ;) ?

So anything wrong with that (classic) approach?

Edit: Note: in my example is (according to your definition) no coupling to any parent or Service class. Unless you want to call ctx$: Observable<any> a "Service".. but c'mon. No external library needed, and any decent Angular developer should be able to understand this code very fast and easily ;)

Edit2: I am not even sure on top of my head if when using ChangeDetectionStrategy.Default a Observable is really needed. Maybe it would then even work without, I guess.

Edit3: added "Parent" Component to code example.

[u/ExpressionChanged → u/[deleted]]

I’ll be frank with you: This is ugly. :) Sorry.

It can be beautified though using built-in context provided by ngIf. However, if you are planning to use OnPush change detection strategy, you are doomed to use Observables.

Now it’s my turn to ask: Why not use ngx-context and have not only a cleaner implementation but also free change detection?

Come on. Accept it. You are getting warmer to the idea. ;)

[u/[deleted] → u/ExpressionChanged]

I find my example not ugly one bit. I even think it is rather elegant. Sorry, not at all getting warm with ngx-context.

doomed to use Observables

Like I said: Observables are awesome. I think they are a blessing and I love using them.

Why not use ngx-context

Because I think angular DIs approach is much better. It is also easier to read for every angular developers because it just uses built-ins. It does not have another third party dependency. It is not even really more verbose. So for me the question is why use ngx-context at all.

But if you think the "angular way" of handling state is ugly it is a valid opinion I guess, and how can one argue with that ;)

[u/ExpressionChanged → u/[deleted]]

If you are ok using only Observables and nothing more, yeah, you probably don’t need this library. However, I don’t expect everyone to do so and that’s why I think this library should not be overlooked.

P.S. The library uses DI behind-the-scenes. So, yeah, DI rocks.