Have you ever heard about Reactive Programming or Reactive Systems ? Do you think React.js is a reactive library ? Have you ever thought about why you should use Rx.JS inside an Angular project ? Is Rx.JS the new L oadash ?
If at least one of these questions is often in your mind, this is exactly the right book to find an answer!
In these pages you will have a chance to learn more about reactive programming and reactive architecture for front-end development: a programming paradigm that is becoming more popular, every day, in the front-end community; but these days it is probably one of the most misunderstood and abused paradigm.
The main goal of this book is to provide a good understanding of what reactive programming is, how to use it in our projects, and particularly how to create fully reactive architectures for creating resilient and maintainable projects.
If you are wondering if the concepts learned inside this book are applicable also on a back-end architecture, my answer would be YES, or at least, the majority of them could be applied to your back-end architecture too.
Bear in mind that this book will focus the attention on front-end architectures with JavaScript, but some of the concepts illustrated should be easily portable to other back-end programming languages such as Node.js, for instance.
This book assumes that you already have good understanding of JavaScript , in particular ECMAScript 6 and 7 syntax; object-oriented programming; and possibly some knowledge of functional programming, but its not mandatory. Let the journey begin!
What Is Reactive Programming?
Every day when we open an editor or IDE to develop a program, we use our favorite programming language; sometimes we study a new one, but, consciously or unconsciously, we are making the decision of what kind of programming paradigm we are going to work with.
Reactive programming is not a new paradigm: its one of the buzzwords we are used to hearing about in the JavaScript community in the past year or so, and it will become more than just a buzzword in the future.
I dont want to begin immediately by using too many technical terms because we will have enough time to learn about them while reading this book, but its important that you understand what is the benefit of working in a reactive way.
If you read blog posts or articles on the Web, few of them are going to explain reactive programming with the spreadsheet cells example, where spreadsheet cells are reacting to changes happening in other cells after user input . This is definitely a good example but we can do better than this.
Im sure you are familiar with the dependency injection pattern where an object is injected via the constructor or in a public method exposed by a class or module. This pattern leverages several benefits like decoupling between two objects and the possibility of testing the hosting object in isolation without creating dependencies and so on.
In some programming languages when we use dependency injection we are going to define an interface as functions argument in the hosting object and then we can interact with the methods available in the injected object.
The injected object in this case is used as an interactive object , because the host knows exactly what the contract is and how to use it.
In reactive programming instead, the hosting object will just subscribe to the injected one, and it will react to the propagation of changes during the application lifetime. See Figure .
Figure 1-1
Interactive vs. Reactive programming : in Reactive Programming the producer is A and the consumer is B
Looking at the image above, we can immediately grasp the main difference between the two approaches :
In the interactive example, object A is aware of which methods to call because knows exactly the Bs object contract, also if we have to understand who has affected the state of the ingested object, we will search across all the projects that we are interacting with.
In the reactive one, the contract is standard and object A is reacting to changes happened in object B, on top we are certain that any manipulation would occur inside the injected object; therefore we will have a stronger separation of concerns between objects.
Because the hosting object is reacting to any value propagated inside the object injected, our program will be up to date without the need for implementing any additional logic.
Its time for a simple example before we move ahead with other concepts.
Lets assume we have a class called Calculator with a method sum and a class Receipt with a method print as shown in Listing .
class Calculator {
sum(a, b){
return a + b;
}
}
class Receipt {
constructor(calculator){
this.calc = calculator;
}
print(itemA, itemB){
const total = this.calc.sum(itemA, itemB);
console.log(`total receipt ${total}`);
}
}
const pizza = 6.00;
const beer = 5.00;
const calc = new Calculator();
const receipt = new Receipt(calc);
receipt.print(pizza, beer);
Listing 1-1
Check Snippet1.js
As you can imagine, the program outputs total receipt 11.
What we are doing in this example is creating the Calculator object and a Receipt object, and then we inject the Calculator instance called calc and we call the method print from the receipt instance with few arguments.
Inside the print method we are writing in the console the total price of the elements passed.
Checking the Receipt class implementation , you can spot in the print method that we are interacting with the method sum of the Calculator class and then getting the final result.
Now lets try to implement the same example in a reactive way in Listing .
class Calculator {
constructor(itemA, itemB){
const obs = Rx.Observable.of(itemA, itemB);
const sum$ = obs.reduce((acc, item) => (acc + item));
return {
observable: sum$
}
}
}
class Receipt {
constructor(observable$){
observable$.subscribe(value => console.log(`total receipt: ${value}`))
}
}
const pizza = 6.00;
const beer = 5.00;
const calc = new Calculator(pizza, beer);
const receipt = new Receipt(calc.observable);
Listing 1-2
Check Snippet2.js
As you can see in this example, the Receipt class is subscribing to an object called observable, injected via the constructor, and all the logic of how to sum the prices and propagate them is delegated to the Calculator class. Therefore, the Receipt class is just reacting to a change, happening in a certain moment of the programs lifetime, displaying in the console the value emitted by the Calculator instance.