DEV Community

loading...

Discussion on: Vanilla JavaScript vs. RxJs

Collapse
bias profile image
Tobias Nickel

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?

Collapse
leobm profile image
Felix Wittmann

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?

Collapse
riccardoodone profile image
Riccardo Odone Author

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.

Collapse
riccardoodone profile image
Riccardo Odone Author

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.

Collapse
bias profile image
Tobias Nickel

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.

Thread Thread
riccardoodone profile image
Riccardo Odone Author

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');
Enter fullscreen mode Exit fullscreen mode

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.