3

I have a question about Angular 4 in general.

One of my co-workers created a reference of an AComponent and bound it as a property to a BComponent to access AComponent's properties, instead of binding AComponent's properties individually. Then he also subscribes to an observable in the AComponent.

Here is the idea:

// a.component.ts
@Component({
  selector: 'some-a',
  template: `<some-b [someRefToAComponent]="someRefToThis">...</some-b>`
})
export class AComponent {
  someRefToThis = this;
  someObservable: Observable<any>;
}

// b.component.ts
@Component({
  selector: 'some-b',
  template: `...`
})
export class BComponent {
  @Input() someRefToAComponent: AComponent;
  someSubscription: Subscription<any>;

  ngOnInit() {
    this.someRefToAComponent.someObservable.subscribe(...);
  }

  ngOnDestroy() {
    this.someSubscription.unsubscribe();
  }
}

Here is my question: Is this a bad practice or a very bad practice? And additionally: What could happen in such a case? Could it lead to a memory leak?

Would be interesting to know what happens since I don't have that deep insights into Angular's internal functionality, yet.

4
  • there are definarely nicer ways to achieve such an effect depending on the end goal. On top of my head, it seems quite peculiar why angular did not complain about cyclic dependencies. Commented Jan 18, 2018 at 21:32
  • The material datepicker is binded to an input field in a similar way. In that case, the functionality of the input field is tightly coupled to the existence of a datepicker component, so it would be an unnecessary indirection to put a service in between. Take a look here github.com/angular/material2/blob/master/src/lib/datepicker/… Commented Jan 18, 2018 at 21:47
  • As always in programming, there is no silver bullet. As long as you think your decisions through and evaluate other approaches in a critical manner, its all good. Commented Jan 18, 2018 at 21:48
  • @Jota.Toledo yeah but you can put an optional dependency on the constructor of the parent element...wouldn't that way be a nice way to achieve such an effect Commented Jan 18, 2018 at 22:54

1 Answer 1

1

Ultimately, I would consider this "against the grain" when it comes to doing things the Angular way. It sounds like what you are really need are Services. Data that needs to interact and be accessible from multiple endpoints, whether they be components, or modules should be contained in a Service.

The other option is to pass data between Components using Data Binding.

This is where understanding the dependency injection system in Angular really becomes a requirement. Services are meant to be Application Singletons that allow components to interact with similar data.

I would really suggest taking a look through the Docs with regards to Dependency Injection.

Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.