Discussion on: Vanilla JavaScript vs. RxJs

View post

why is there .subscribe? how many responses do you expect? are they so many that they need to get mapped? where would you put a breakpoint in the declaritive code?

Felix Wittmann • Nov 5 '20 • Edited

you can add a tap function?

Edit:
The fromFetch function, which I think creates a complete event on the observable after the fetch? But I have not used it myself yet. It's been a while since I used RXJS regularly. And otherwise rather directly from Angular. There you normally use the HttpClient from angular.

Edit2:
oh, and if I see it right, is the subscribe not on the fromEvent observable?

Riccardo Odone • Nov 5 '20

Hey Felix. I'm not sure I understand the comment.

As long as I see it, fromFetch wraps the native fetch in an observable that handles cancellations for you.

The subscribe is bound to the entire observable that precedes it (after the fromFetch some additional transformations are applied).

Having said that, I'm not on expert of RxJs. For example, I'm not totally sure if the flatMap shouldn't have been a switchMap. I guess, in general, it's safer to use switchMap as a default when only one inner subscription should be active at once.

Riccardo Odone • Nov 5 '20 • Edited

Hello Tobias, let's see if I can help with your questions.

why is there .subscribe?

In RxJs you need to subscribe to the observable to consume the values it produces.

how many responses do you expect?

An observable is a stream of values, it's like an array that grows over-time. For example, fromEvent(element, 'input').subscribe(x => console.log(x)) logs every time the input event is fired by element.

are they so many that they need to get mapped?

Yes, it's a stream of values.

where would you put a breakpoint in the declaritive code?

You can use tap as Felix mentioned.

RxJs is both powerful and complex. It took me a long time to learn the basics, and I still make many mistakes with it. But I believe it's worth learning because it really gives a different perspective.

Tobias Nickel • Nov 6 '20

thanks, now you have described the api to me. I see, that in this style of code, everything is treated as a stream. However, an api request, a call via fetch, is fundamentally a single in and a single out. there is no stream of responses. The stream will always only have a single response or a single error. that is what async/await is about, and you get nice meaningfull stacktraces for debugging.

Riccardo Odone • Nov 6 '20 • Edited

However, an api request, a call via fetch, is fundamentally a single in and a single out.

It doesn't have to be, it can be a response stream:

// https://web.dev/fetch-upload-streaming/

const response = await fetch(url);
const reader = response.body.getReader();

while (true) {
  const { value, done } = await reader.read();
  if (done) break;
  console.log('Received', value);
}

console.log('Response fully received');

However, I agree most of the time it's not used that way. Still, treating everything as a stream has the advantage of making things composable and re-usable.

In any case, I'm not advocating for any approach. I should have made it more clear in the post. Also, you are right, I could have used async/await in the vanilla JavaScript code to make it look cleaner.