Angular - why Subscriptions ? why NOT to use service's properties in components directly?

Question

Everywhere you look you see subscribe here, subscription there, unsubscribe here, unsubscribe there. I ask, what do we NEED all this boilerplate code for, if its possible to use a service properties in components directly.

@injectable()
export class MyService {
  public logItems: Log[] = [];

  getLatestLogItems() {
      return this.httpService.GetLatestLogItems() // some http service
      .subscribe(
          (items) => {
              this.logItems = items;
          },
          ...
      );
  }
}

and then in component:

@Component({
  selector: 'app-logs',
  template:    `<ul>
                 <li *ngFor="let log of myService.logItems"> {{ log | json}} </li>
               </ul> `
})
export class MyComponent implements OnInit {
  constructor(public myService: MyService) { }

  ngOnInit() {
    this.myService.getLatestLogItems();
  }

if you want to refresh the data, simply invoke getLatestLogItems() again. what am I missing here ? why is Subjects required at all?

Because the code is asynchronous. By subscribing, you get notified as soon as the value is available. Usually, you would call `subscribe` from within the component though, and not within the service — user184994, Aug 19 '18 at 15:17
so that means a lot of copy-paste boiler plate code, on every component consuming that service doesn't it ? — angularpioneer, Aug 19 '18 at 15:19
What's your alternative? How do you know when `this.logItems` has been set? — user184994, Aug 19 '18 at 15:20
one way to reduce that boilerplate is to use async pipe in templates — AdityaParab, Aug 19 '18 at 15:22
Observables and streams is a great way to handle asynchronous data flow. Have a look at [this article](https://developer.telerik.com/topics/web-development/introduction-observables-angular-developers/). And I don't agree that what you call boilerplate necessarily is boilerplate, it's just regular code. In fact observabels more often reduce the amount of boilerplate. — Daniel B, Aug 19 '18 at 15:24

score 1 · Answer 1 · answered Aug 19 '18 at 15:50

Depending on your use case, generally I think it's a baad idea to do the way you mention above:

Potential Memory leak: When will the unsubscribe happen? By calling getLatestLogItems again and again, it may cause memory leak. Though in this case it might not because httpClient handled that, but other observable method might.
Value update is not track: Your value of myService.logItems is not track. If you have multiple same components in same page (e.g. ngFor) or using the component in other pages + your service is singleton (most of the case it is), you may end up with unexpected result. See the simple demo here: https://stackblitz.com/edit/so-rxjs-test. The value is not updated in template correctly.
Separation of concerns: Service should be private in component. You are exposing service to public. This is not a good practice. It's because service (another layer) is used for code separation. If you are doing the way above, might as well you write the getLatestLogItems function in component straight away.
If you do not like the boilerplate code, maybe you can consider convert all observable to promise by calling .toPromise. This way, you don't need to .subscribe and .unsubscribe but you need to .then or async await...

I hope this provide some reasoning behind the boilerplate. If you are using other frameworks like React or Vue or even just jquery without rxjs, item no 4 is mostly unavoidable (need to .then or async await) for all api calls.

Akj · Answer 2 · 2018-08-19T15:25:33.060

0

You should subscribe in component and return observable from service

@injectable()
export class MyService {
  public logItems: Log[] = [];

  getLatestLogItems(): Observable<any> {
      return this.httpService.GetLatestLogItems() // some http service
  }
}

In Component :

 ngOnInit() {
    this.myService.getLatestLogItems().subscribe(response => {console.log(response)})
  }

edited Aug 19 '18 at 15:25

answered Aug 19 '18 at 15:19

Akj

7,038
3
28
40

yes. But then i'll have `const itemsSubscription = ...` and `ngOnDestroy() { itemsSubscription.unsubscribe()} ` in addition to a local logs variable, on every component, copy-paste. isn't that redundant even more ? – angularpioneer Aug 19 '18 at 15:21
so you want to subscribe only once and use in other components. am i right? – Akj Aug 19 '18 at 15:22
1

If it;s an HTTP subscription, there is no need to unsubscribe as they complete themselves once they've emitted their value – user184994 Aug 19 '18 at 15:23
there is no need to unsubscribe as @user184994 told. – Akj Aug 19 '18 at 15:24
@UnluckyAj doing what you suggest would mean the retrieved value can not be reused. every component will invoke an http request of its own. the alternative would be, as he did, place a variable on the service and then local variables on each component, and then you ask, why use the local variables at all, and not the service's one to begin with. good question. – Stavm Aug 19 '18 at 15:32
@Stavm There is something called BehavoiurSubject in Rxjs . you can subscribe only once an use it in other component. – Akj Aug 19 '18 at 15:53

score 0 · Answer 3 · answered Aug 19 '18 at 15:47

ReactiveX Observable

To get around this, you need to understand the Observable and Observer concepts.

Observables do not return anything, Instead they emit items so Observers can subscribe. In this way the Observer stands ready to react appropriately at whatever future time the Observable does so.

For further reading please refer to ReactiveX documentation.

Yes, subscribing and unsubscribing can sometimes seem frustrating, but in your code:

  getLatestLogItems() {
       return this.httpService.GetLatestLogItems().subscribe((items) => {
                   this.logItems = items;
               });
  }

the getLatestLogItems is returning nothing.

score 0 · Answer 4 · answered Aug 19 '18 at 16:49

I wouldn’t say your code is wrong. Http requests automatically unsubscribe so there shouldn’t be a memory leak. You also have control over when the request is happening. Code wise, I don’t see any issues but maybe I’m missing something.

I still would not use this pattern. My argument is that services will begin to define your components. That feels kinda weird. You’re also limiting your use of RxJs. Each component should handle the api call as they see fit for that specific component.

However, I don’t see any loss of capability but I do see hacks creeping into your code. So it’s not terrible but it’s a little selfish on the services part. Let the components decide how they consume the data.

Angular - why Subscriptions ? why NOT to use service's properties in components directly?

4 Answers4

ReactiveX Observable

Linked