[Angular] Semantic difference between Subject and Observable when using $ suffix.

[mightymatth]

At PDC, we've recently discussed this topic and come up with different points of view. As I noticed this section in the handbook, to avoid discussing in different places, I wanted to share why I advocate for suffixing subjects with Sub (or Subject) instead of both suffixing with $.
I'd like to show you some examples of where I had issues in the past and what others say about it. Also, I want to be open-minded, even though it might sound offensive.

Angular documentation says this:

This can be useful when scanning through code and looking for observable values. Also, if you want a property to store the most recent value from an observable, it can be convenient to use the same name with or without the "$".

Here they say "observable values", "the most recent value from an observable", not using it in the context of subjects when we are able to push new values to it (IMO, that's the intent).
$ is here to indicate that you can subscribe to it (to be a consumer), not that you can push a new value to it (to be a producer).

However, let's see the opposite arguments from a blog post q/a, where they say:

Every subject is an observable. (...) The $ sign suffix doesn't mean asynchronous, its used as a soft convention to indicate that the variable is a stream. It is more like a naming helper to indicate types.

IMO this is semantically wrong. How Subject is implicitly an Observable, it shouldn't indicate that it should be used as an observable directly. That's why we have asObservable() method on a Subject to limit the usage just to act as a consumer, not also as a producer. Additionally, they didn't post any more valid arguments about it.

I found a tweet thread that talks about it.

Thx for the idea @geromegrignon
Small tip: Suffix #RxJS subjects with $$. Clear convention, easy to spot. You see it's an observable but not just an observable

I don't like $$ suffix just because it makes the code less readable. For example, it reminds me of naming variables like var, var1, var11, var111, etc. When you'll try to find some variable with the same name, but different (and similar) suffixes, you will end up with a list of variables with a bunch of $ characters.
There are some additional tweets where people state their opinions, I can comment on them, but it would be too verbose.

I found that I'm not the only one who has this distinction between subjects and observables. Moreover, I found a specific rule that people use to have a consistent subject suffix (that isn't also $).

Practical example

Let's say we have a sidebar that we want to open/close and expand/collapse. A simple service would look like:

@Injectable()
export class SidebarService {
	private readonly isOpenSub = new BehaviorSubject<boolean>(false);
	isOpen$ = this.isOpenSub.asObservable();

	private readonly isExpandedSub = new BehaviorSubject<boolean>(false);
	isExpanded$ = this.isExpandedSub.asObservable();

	open(): void {
		this.isOpenSub.next(true);
	}

	close(): void {
		this.isOpenSub.next(false);
	}

	expand(): void {
		this.isExpandedSub.next(true);
	}

	collapse(): void {
		this.isExpandedSub.next(false);
	}
}

This way we have a clear separation of concerns on who is a consumer and a producer. In the case of more complex services with more subjects and observables, it's easier to find the correct one, e.g.:

I'd like to hear your opinions about that statements on this topic. Would it be useful to give you more concrete examples in the code, and screenshots from the IDE? Just let me know.

[geromegrignon]

sub might be misleading due to Subscription.
I'd instead use subject in that case.

Somehow $$ is more straightforward to advocate than Subject in my mind.
Calling a subject xSubject and an observable w$ feels like using kebab-case and Pascal-case all together.

[mightymatth]

sub might be misleading due to Subscription.
I'd instead use subject in that case.

Yes, you might be right. I almost never deal with plain subscriptions (i.e. saving them in ngOnInit and unsubscribing from them in ngOnDestroy) as we always try to utilize async pipes. But that's a good point!

Somehow $$ is more straightforward to advocate than Subject in my mind.
Calling a subject xSubject and an observable w$ feels like using kebab-case and Pascal-case all together.

I understand your concern, but the idea is to make a clear distinction between observables and subjects, not make them look like one another, because it can lead to typos that can result in hardly detectable errors.
For example, if we have:

private readonly event$$: Subject<Event>;
event$: Observable<Event> = this.event$$.asObservable().pipe(
  shareReplay(1),
  tap(v => {}), // some side-effect
)

...it would be easy to mistype and subscribe to both of them like:

event$.subscribe() // case 1
event$$.subscribe() // case 2
eventSubject.subscribe() // case3

Even though you are able to subscribe to both of them, it doesn't mean you should. If you subscribe to event$$, it would probably result to wrong behavior because you would probably expect the latest value for the late subscriber and the side-effect. It's easy to make this mistake, hard to spot it, and you can spend a lot of time debugging it.

Additionally, at first, $ started to be used as the word "stream", so when you have a variable like event$, we can read it like "event stream", or "stream of event(s)", meaning that you can subscribe to this value. Adding $$ to subjects just because it's kind of related to observables, we're unintentionally breaking this meaning.

[geromegrignon]

Indeed $ and $$ differences might lead to errors.

I confess the more I use the current pattern, the less it's part of best practices for me.
It feels like just some sort of vault not to prevent people from accessing next but as a gatekeeper about proper education about when and where to use Subjects.

[fvoska]

The way we envision this rule and how we use it at Infinum is as follows:

$ is not used to make a distinction between different types of Subjects and the base Observable class. If something is an observable (no matter which child class), we mark it with $. This is to let you know it is something you can subscribe to. This naming does not let you know if you can change the observable in case it is, for example, a Subject.

This naming convention works hand-in-hand with no-exposed-subjects RxJS eslint rule.

The idea is that you never expose subjects publicly, you only expose them after converting to observable using some operators via pipe or asObservable().

This is how we want to name and use Observables:

class SomeComponent {
  private _isLoading$ = new BehaviourSubject(false); // for internal use for "state management"
  public isLoading$ = this._isLoading$.pipe(debounceTime(250)); // for use in template

  // to be called from some methods, for example during data fetching
  private updateLoadingState(state) {
    this._isLoading$.next(state)
  }
}

Same logic applies to services as well, for example:

class AuthService {
  private _user$ = new BehaviorSubject<User | null>(null);
  public user$ = this._user$.asObservable();
  public isLoggedIn$ = this.user$.pipe(map(Boolean)); // Maybe a bit unnecessary, you could always check if user$ is null. Could be useful in some cases so it's also nice to expose it like this

  public login() {
    this.http.post(...).pipe(tap((u) => this._user$.next(u)))
  }
}

To sum up, we use this naming convention and the rule about no exposed subjects to ensure that the public interface of component/service/whatever only exposes the base observable. This makes it easier to keep track of who can change value of the observable and to debug the flow. The only "ugly" part is that you need a separate name for private member and here we use _. Generally if there is no naming conflict, we don't prefix private members with _, this is one of the rare cases where we do it. I do not have a strong opinion about this _ prefix, you could also do something like this: private userSub$; public user$, but I think it is important to keep $ postfix

[mightymatth]

I like the approach of this eslint rule and naming subjects with underscores when there is a name conflict. Generally, I don't like prefixing private properties with underscores, but in this case, it neatly solves the issue with naming.

However, I still have a concern about putting both observables and subjects (sometimes called sources) into the same bucket in terms of naming. There are numerous examples where a user, either a writer or code reviewer, who is uninformed by this convention (or where there is no convention) could be easily mistaken and would use a subject instead of an observable intended to be consumed.
In practice, if you didn't have bad experiences with that, just ignore it. If it happens that somebody spends hours debugging why some side effect didn't run, or resolving performance issues because of a wrong subscription, this conversation could be useful.

Generally, I like the approach. Could we put it in the handbook?

[thabalija]

I agree with @fvoska on this one. $ is an indicator of an Observable, no matter which one. I also agree with @mightymatth that usage of $$ can lead to errors, and I personally would like to avoid that naming.

I would honestly add _ as prefix (like example above from @fvoska ) or Subject$ as a suffix:

@Injectable()
export class SidebarService {
	private readonly isOpenSubject$ = new BehaviorSubject<boolean>(false);
	isOpen$ = this.isOpenSubject$.asObservable();

	private readonly isExpandedSubject$ = new BehaviorSubject<boolean>(false);
	isExpanded$ = this.isExpandedSubject$.asObservable();

	open(): void {
		this.isOpenSubject$.next(true);
	}

	close(): void {
		this.isOpenSubject$.next(false);
	}

	expand(): void {
		this.isExpandedSubject$.next(true);
	}

	collapse(): void {
		this.isExpandedSubject$.next(false);
	}
}

[fvoska]

I have opened a task to expand the reasoning of the mentioned Handbook chapter with conclusions from this discussion.

[fvoska]

Handbook chapter has been updated with a bit more reasoning:
https://infinum.com/handbook/frontend/angular/angular-guidelines-and-best-practices/formatting-naming-and-best-practices#postfix-observables-with-codecode