Reactive programming is the most preferred way to write event-based code by completely replacing the observer-based pattern. It has therefore replaced all ambiguous situations that arise from observer driven programs. It is the modular way to code event-driven logic. Users are finding wide application of reactive programming in developing user interfaces, interactive games, control or monitoring applications etc. Reactive programming has also solved the scalability issues.
Simple examples of javascript events are like user’s click with the mouse or loading of web page/image has been loaded, a change in the input field or submission of an HTML form.
<!DOCTYPE html>
<html>
<body>
Click on the text!
</body>
</html>
The JavaScript event handling prototype has three implementations, but all of them are incompatible to each other. Therefore, you should be selective while working on them and see which one to use and when. For example, the original DOM 0 model is the base model that was supported by all browsers, but it had some big limitation. The event handler was taken as a property of the objects that started the event.
myButton.onsubmit = myObject.onsubmiteventhandler;
Therefore, you cannot set more than one event handler for one event, though it is possible to set the same event handler for different events. When you use the object within the event handler, this would refer to the firing object (in this case, myButton) and not the one that handles the event (myObject). This creates a problem with some of the Windows programming.
The advanced DOM 2 model has come next but it is not supported by Internet Explorer versions older than 9. Though, with this you can assign more event handler for the same event and those have an Event object parameter with all significant event data.
The third one, the Internet Explorer model is supported only by Microsoft`s browsers. It has a missing third parameter in the Capturing Phase during event propagation.
Functional Reactive Programming is undoubtedly the best-known user interface paradigm where UIs are modeled as dataflows. Here changes in user actions or data source work purely with the help of functional operations. This shows up as visual changes in the UI. In other words the changes are reflected as change in data in one cell of a spread sheet automatically changing the data in other interrelated cells.
Functional Reactive Programming has become simple yet powerful with Event stream processing. In this patterns are detected in incoming event streams that make the process extremely responsive in timely detection of critical conditions like in medical emergencies or fraud detection.
For example, monitoring of heartbeat can be taken as an event stream reflecting time event. It is representative of time that is pseudo continuous.
var timerE = function(delay) {
var stream = new EventStream();
setInterval(function() {
stream._occur(new Date());
});
return stream;
}
It no more concentrates on detecting temporal patterns where instantaneous events had no duration. They could be happening either before/after/at the same time. This sequential pattern was however inadequate in complex temporal relationships experienced in cases stated above where duration of the event was equally important.
Event stream processing is different from its previous XML/relational stream processing. It can specify non-occurrence pattern in case of ambiguous events when an event can match multiple query symbols.
With this kind of reactive programming you are actually doing some simple actions like replacing nested programming with a loops concepts using ‘map’ and ‘filter’. You no more work with individual events but with event streams and change your data with ‘map’ and ‘filter’ and combine them with ‘merge’ and ‘combine’.
The other semantic type that is quite inherently related to event streams is behaviors. Behaviors are like events that remember their last value. When event streams can be defined as unlimited data sequences connected to a time, behaviors are function of time, and their value change continuously over time. Pseudo-Haskell says it as
// EventStream a = [(Time, Event)]
// Behavior a = Time -> a
With functional reactive programming you can have solutions to many issues which could not be addresses with observer- or actor-based programming like order of events, threading and leaking issues, accidental recursion etc. It also solves the javascript event handling problems with performance friendly programming. It can be implemented later as and when needed and therefore solving the issues of scalability. Another advantage of this approach is its parallelism, when handling real-time parallel events becomes easy.
