I once read a book that suggested that Newton came up with the idea for calculus when he was observing the flow of a river around a reed. I've never been able to find any other source which supports that assertion. It is, however, a nice picture to hold in your mind. Calculus deals with understanding how the state of a system changes over time. Most developers will rarely have to deal with calculus in their day to day work. They will, however, have to deal with systems changing. After all, having a system which doesn't change at all is pretty boring.
Over the last few years a number of different ideas have arisen in the area of treating change as a stream of events – just like the stream that Newton supposedly observed. Given a starting position and a stream of events it should be possible to figure out the state of the system. Indeed, this is the idea behind using an event store. Instead of keeping the final state of an aggregate in a database we instead keep track of all the events which have been applied to that aggregate. By replaying this series of events we can recreate the current state of the aggregate. This seems like a roundabout way of storing the state of an object but it is actually very useful for a number of situations. For example, a disconnected system, like a cell phone application when the phone isn't connected to the network, which uses an event store can be merged with other events much more easily than simply keeping the end state. It is also stunningly useful for audit scenarios as it is possible to pull the system back to the state it was in at any point in time by simply halting the replay at a time index. How frequently have you been asked, "why is the system in this state?", and you've been unable to reply? With an event store the answer should be easy to ascertain.
In this chapter we'll cover the following topics:
- Application state changes
- Streams
- Filtering streams
- Merging streams
- Streams for multiplexing
Within an application we can think of all the events happening as a similar stream of events. The user clicks on a button? Event. The user's mouse enters some region? Event. A clock ticks? Event. In both front and backend applications, events are the things which trigger changes in state. You're likely already using events for event listeners. Consider attaching a click handler to a button:
var item = document.getElementById("item1");
item. addEventListener("click", function(event){ /*do something */ });In this code we have attached a handler to the click event. This is fairly simple code but think about how rapidly the complexity of this code increases when we add conditions like "ignore additional click for 500ms once a click is fired to prevent people double-clicking" and "Fire a different event if the Ctrl key is being held when the button is clicked". Reactive programming or functional reactive programming provides a simple solution to these complex interaction scenarios through use of streams. Let's explore how your code can benefit from leveraging reactive programming.