RxJS/Rx.Net Observable-subscribe vs events - Performance/Threads [closed]
Asked Answered
G

1

14

I recently started working on Reactive Extensions, mostly observables at client side using Angular 2. The concept of observables of Rx and events of dotnet seems to be very similar. Are there any specific examples where one is applicable and other is not. If not, is there any other reason why Microsoft introduced Rx.Net, as observables stand at the core of Reactive Extensions. Any links or real time examples would suffice. Has it got something better to do with respect to async/await, tasks or threads? I am looking for differences threading/performance wise.

Gokey answered 15/7, 2017 at 6:42 Comment(1)
Where stream-of-signals can be thought as multiple calls to a function, core difference between Rx and async-await would be stateful-ness. Each Rx operators can retain some state and behave differently for each calls. Async-await functions are not. You need to store states somewhere else to emulate Rx operators, but unlike Rx case, it cannot be encapsulated into the function itself.Liberality
D
22

They are different abstractions. Everything in this answer applies equally to JavaScript and C#.

async/await allow you to asynchronously wait for a single asynchronous operation. This "asynchronous operation" can only complete one time, with a single result.

Observables allow you to subscribe to a stream of data, and react to data arriving on that stream. This subscription model allows multiple items of data over time.

Defrock answered 15/7, 2017 at 10:24 Comment(3)
Thank you for helping me understand the difference. But I still feel that whatever observables are meant to do, there are already constructs that facilitate those features. Say for example Observable.subscribe and event handlers do the same thing. Am I missing something here or am I completely wrong with this too?Gokey
@Sreenath: Not at all. Rx was often referred to as "LINQ over events" in its early days. However, Rx is far superior to events; it has a more consistent and flexible usage. I think of observable as essentially a replacement for events; they're how events would be if they were designed today instead of copying a design from decades ago.Defrock
Found out few links which go hand in hand with above answer providing examples. Adding them for reference for anyone visiting this - learn.microsoft.com/en-us/previous-versions/dotnet/… & markheath.net/post/reactive-extensions-observables-versusGokey

© 2022 - 2024 — McMap. All rights reserved.