Rxjs: Proposal for a change of type

[abelardolg]

At this example:

const intervalo$ = new Observable<number>(emitter => {
  let cont = 0;
  const intervaloId = setInterval(() => {
    cont++;
    emitter.next(cont);
  }, 1000);

  return (() => {
    clearInterval(intervaloId)
    console.log("clear interval")
  });
});

the 'emitter' is Subscriber; so, why doesn't it call "Emitter"?

I hardly can understand concepts when the syntax of the name doesn't correspond with its semantic.

This object has the responsability for emitting values; so, why don't you call it Emitter?

Disclaimer:
I wasn't sure if this proposal goes here; so, if you consider to delete it, beg your pardon.

Best regards.

[josepot]

Hi @abelardolg

I think that I understand where you are coming from. However, I'm of the opinion that either observer or subscriber are better terms than emitter (or producer). This is how I see it:

Observables are lazy: it's not until a consumer (or observer, or subscriber, or listener) subscribes to an Observable that the function of the Observable gets evaluated. When a new subscription occurs and the function is evaluated, then the argument that it receives represents the listener of the subscription, the one that wants to know what's happening. Strictly speaking, this consumer is not the original producer (or emitter), it's the one that receives the values from the emitter.

IMO, in the example that you shared the emitter would is the setInterval callback function.

Another reason for not calling it emitter, is that sometimes the emitter exists outside of the Observable. That's the case for "hot observables".

[cartant]

Closing this because there is a long history behind the 'observer' and 'subscriber' terms. I cannot believe that there will be any appetite for changing the terminology at this stage.

Also, the reason the argument passed to the Observable constructor's subscribe callback being named subscriber - rather than observer - is because subscribers have a closed property that is checked in some observable implementations to determine whether or not the subscriber has been explicitly unsubscribed synchronously during the subscription process.

[josepot]

Also, the reason the argument passed to the Observable constructor's subscribe callback being named subscriber - rather than observer - is because subscribers have a closed property that is checked in some observable implementations to determine whether or not the subscriber has been explicitly unsubscribed synchronously during the subscription process.

I didn't know that. I've been using the two terms like if they were interchangeable. Thanks for for pointing that out!

Although, I have a small question about this: the docs for Subject state that:

Every Subject is an Observer. It is an object with the methods next(v), error(e), and complete(). To feed a new value to the Subject, just call next(theValue), and it will be multicasted to the Observers registered to listen to the Subject.

Which is correct, of course, but maybe it would it be worth it to also mention (in a separate paragraph) that a Subject is also a Subscriber because it has the closed property?

[cartant]

... that a Subject is also a Subscriber because it has the closed property?

Nope. The closed property alone doesn't make it a subscriber. I mentioned closed because that's the primary reason that the callback's parameter is typed as Subscriber and not Observer.

A subject's closed property serves another purpose - one you rarely, if ever, need to deal with. That is, if you call unsubscribe on a Subscription return by a subscribe call to which you passed a Subject, that subject's closed property won't have been set to false.

[abelardolg]

Hi @josepot , @cartant
Thanks for your nice explanations.