Reactive programming is a programming paradigm based on the concept of an asynchronous data flow. A data flow is like a river: it can be observed, filtered, manipulated, or merged with a second flow to create a new flow for a new consumer.
A key concept of reactive programming is events. Events can be awaited, can trigger procedures, and can trigger other events. Events are the only proper way to map our real world to our software: we open a window if it's too hot inside. In the same way, we want the Total cell to update when we change some values in our spreadsheet (the propagation of the changes) or our robot to turn around the moment it reaches the wall (reaction to events).
Nowadays, one of the most common scenarios for reactive programming is UIs: we have mobile apps that have to react to network calls, user touch input, and system alerts. In this world, software has to be event-driven and reactive because real life is event-driven.
Functional reactive programming is an idea from the late 90s that inspired Erik Meijer, a computer scientist at Microsoft, to design and develop the Microsoft Rx library.
Rx is a reactive extension for Microsoft .NET. Rx provides an easy way to create asynchronous, event-driven programs using Observable sequences. A developer can model an asynchronous data stream using Observables, query the Observables using LINQ syntax, and easily manage concurrency with Schedulers.
Rx makes well-known concepts, such as the push approach, easy to implement and consume. In a reactive world, we can't just wait for a function result, a network call, or a database query to return and pretend that the user won't notice or even complain about it. Every moment we wait for something, we lose the opportunity to do other things in parallel, provide a better user experience, and free our software from the chains of sequential, blocking programming.
.NET Observable relates to .NET Enumerable according to the following table:
|
.NET Observable |
Single return value |
Multiple return values |
|---|---|---|
|
Pull/Synchronous/Interactive |
T |
|
|
Push/Asynchronous/Reactive |
|
|
The push approach reverses the problem: instead of asking for a result and waiting, the developer simply asks for a result and gets notified when the result is available. The developer provides a clear sequence of reactions to the events that are going to happen. For every event, the developer provides a reaction; for example, the user is asked to log in and submit a form with his username and password. The application executes the network call for the login and states what is going to happen:
- Show a success message and store the user's profile
- Show an error message
As you can see with the push approach, the developer doesn't wait for the result. He will be notified when the result arrives. In the meantime, he can do whatever he wants:
- Show a progress dialog
- Store the username and password for future logins
- Preload something he knows would take some time the moment the login succeeds