When to use asObservable() in rxjs?

When to use Subject.prototype.asObservable()

The purpose of this is to prevent leaking the "observer side" of the Subject out of an API. Basically to prevent a leaky abstraction when you don't want people to be able to "next" into the resulting observable.

Example

(NOTE: This really isn't how you should make a data source like this into an Observable, instead you should use the new Observable constructor, See below).

const myAPI = {
getData: () => {
const subject = new Subject();
const source = new SomeWeirdDataSource();
source.onMessage = (data) => subject.next({ type: 'message', data });
source.onOtherMessage = (data) => subject.next({ type: 'othermessage', data });
return subject.asObservable();
}
};

Now when someone gets the observable result from myAPI.getData() they can't next values in to the result:

const result = myAPI.getData();
result.next('LOL hax!'); // throws an error because `next` doesn't exist

You should usually be using new Observable(), though

In the example above, we're probably creating something we didn't mean to. For one, getData() isn't lazy like most observables, it's going to create the underlying data source SomeWeirdDataSource (and presumably some side effects) immediately. This also means if you retry or repeat the resulting observable, it's not going to work like you think it will.

It's better to encapsulate the creation of your data source within your observable like so:

const myAPI = {
getData: () => return new Observable(subscriber => {
const source = new SomeWeirdDataSource();
source.onMessage = (data) => subscriber.next({ type: 'message', data });
source.onOtherMessage = (data) => subscriber.next({ type: 'othermessage', data });
return () => {
// Even better, now we can tear down the data source for cancellation!
source.destroy();
};
});
}

With the code above, any behavior, including making it "not lazy" can be composed on top of the observable using RxJS's existing operators.

A Subject can act both as an observer and an observable.

An Obervable has 2 methods.

• subscribe
• unsubscribe

Whenever you subscribe to an observable, you get an observer which has next, error and complete methods on it.

You'd need to hide the sequence because you don't want the stream source to be publicly available in every component. You can refer to @BenLesh's example, for the same.

P.S. : When I first-time came through Reactive Javascript, I was not able to understand asObservable. Because I had to make sure I understand the basics clearly and then go for asObservable. :)

In addition to this answer I would mention that in my opinion it depends on the language in use.

For untyped (or weakly typed) languages like JavaScript it might make sense to conceal the source object from the caller by creating a delegate object like asObservable() method does. Although if you think about it it won't prevent a caller from doing observable.source.next(...). So this technique doesn't prevent the Subject API from leaking, but it indeed makes it more hidden form the caller.

On the other hand, for strongly typed languages like TypeScript the method asObservable() doesn't seem to make much sense (if any). Statically typed languages solve the API leakage problem by simply utilizing the type system (e.g. interfaces). For example, if your getData() method is defined as returning Observable<T> then you can safely return the original Subject, and the caller will get a compilation error if attempting to call getData().next() on it.

Think about this modified example:

let myAPI: { getData: () => Observable<any> }


myAPI = {
getData: () => {
const subject = new Subject()
// ... stuff ...
return subject
}
}


myAPI.getData().next() // <--- error TS2339: Property 'next' does not exist on type 'Observable<any>'

Of course, since it all compiles to JavaScript in the end of the day there might still be cases when you want to create a delegate. But my point is that the room for those cases is much smaller then when using vanilla JavaScript , and probably in majority of cases you don't need that method.

(Typescript Only) Use Types Instead of asObservable()

I like what Alex Vayda is saying about using types instead, so I'm going to add some additional information to clarify.

If you use asObservable(), then you are running the following code.

/**
* Creates a new Observable with this Subject as the source. You can do this
* to create customize Observer-side logic of the Subject and conceal it from
* code that uses the Observable.
* @return {Observable} Observable that the Subject casts to
*/
asObservable(): Observable<T> {
const observable = new Observable<T>();
(<any>observable).source = this;
return observable;
}

This is useful for Javascript, but not needed in Typescript. I'll explain why below.

Example

export class ExampleViewModel {


// I don't want the outside codeworld to be able to set this INPUT
// so I'm going to make it private. This means it's scoped to this class
// and only this class can set it.
private _exampleData = new BehaviorSubject<ExampleData>(null);


// I do however want the outside codeworld to be able to listen to
// this data source as an OUTPUT. Therefore, I make it public so that
// any code that has reference to this class can listen to this data
// source, but can't write to it because of a type cast.
// So I write this
public exampleData$ = this._exampleData as Observable<ExampleData>;
// and not this
// public exampleData$ = this._exampleData.asObservable();
}

Both do the samething, but one doesn't add additional code calls or memory allocation to your program.

❌this._exampleData.asObservable();❌
Requires additional memory allocation and computation at runtime.

✅this._exampleData as Observable<ExampleData>;✅
Handled by the type system and will NOT add additional code or memory allocation at runtime.

Conclusion

If your colleagues try this, referenceToExampleViewModel.exampleData$.next(new ExampleData());, then it will be caught at compile time and the type system won't let them, because exampleData$ has been casted to Observable<ExampleData> and is no longer of type BehaviorSubject<ExampleData>, but they will be able to listen (.subscribe()) to that source of data or extend it (.pipe()).

This is useful when you only want a particular service or class to be setting an information source, and when you don't want people to be setting that source of information willy-nilly from random spots within your codebase.