Hands-On Reactive Programming with Clojure

Create asynchronous, event-based, and concurrent applications, 2nd Edition

Konrad Szydlo, Leonardo Borges

• Publisher: Packt Publishing
• Year: 2019
• ISBN:
  9781789341966
• Edition: 2
• Topic: Computer Science
• Subtopic: Computer Science General
• Index: Computer Science

Learn how to use RxClojure to deal with stateful computations

Key Features

• Leverage the features of Functional Reactive Programming using Clojure
• Create dataflow-based systems that are the building blocks of Reactive Programming
• Use different Functional Reactive Programming frameworks, techniques, and patterns to solve real-world problems

Book Description

Reactive Programming is central to many concurrent systems, and can help make the process of developing highly concurrent, event-driven, and asynchronous applications simpler and less error-prone.

This book will allow you to explore Reactive Programming in Clojure 1.9 and help you get to grips with some of its new features such as transducers, reader conditionals, additional string functions, direct linking, and socket servers. Hands-On Reactive Programming with Clojure starts by introducing you to Functional Reactive Programming (FRP) and its formulations, as well as showing you how it inspired Compositional Event Systems (CES). It then guides you in understanding Reactive Programming as well as learning how to develop your ability to work with time-varying values thanks to examples of reactive applications implemented in different frameworks. You'll also gain insight into some interesting Reactive design patterns such as the simple component, circuit breaker, request-response, and multiple-master replication. Finally, the book introduces microservices-based architecture in Clojure and closes with examples of unit testing frameworks.

By the end of the book, you will have gained all the knowledge you need to create applications using different Reactive Programming approaches.

What you will learn

• Understand how to think in terms of time-varying values and event streams
• Create, compose, and transform observable sequences using Reactive extensions
• Build a CES framework from scratch using core.async as its foundation
• Develop a simple ClojureScript game using Reagi
• Integrate Om and RxJS in a web application
• Implement a reactive API in Amazon Web Services (AWS)
• Discover helpful approaches to backpressure and error handling
• Get to grips with futures and their applications

Who this book is for

If you're interested in using Reactive Programming to build asynchronous and concurrent applications, this is the book for you. Basic knowledge of Clojure programming is necessary to understand the concepts covered in this book.

The UI as a Function

So far, we have taken a journey through managing complexity by efficiently handling and modeling asynchronous workflows in terms of streams of data. In particular, Chapter 4, Introduction to core.async, and Chapter 5, Creating Your Own CES Framework with core.async, explored what's involved in libraries that provide primitives and combinators for Compositional Event Systems (CES). We also built a simple ClojureScript application that made use of our framework.

One thing you might have noticed is that none of the examples so far have dealt with what happens to the data once we are ready to present it to our users. It's still an open question that we, as application developers, need to answer.

In this chapter, we will look at one way to handle Reactive User Interfaces in web applications using React^[1], a modern JavaScript framework developed by Facebook, as well as the following topics:

• How React renders user interfaces efficiently
• An introduction to Om, a ClojureScript interface for React
• How Om leverages persistent data structures for performance
• Developing two fully working ClojureScript applications with Om, including the use of core.async for inter-component communication

The problem with complex web UIs

With the rise of single-page web applications, it became a must to be able to manage the growth and complexity of a JavaScript code base. The same applies to ClojureScript.

In an effort to manage this complexity, a plethora of JavaScript MVC frameworks have emerged, such as AngularJS, Backbone.js, Ember.js, and KnockoutJS, to name a few.

They are very different, but share a few common features:

• Giving single-page applications more structure by providing models, views, controllers, templates, and so on
• Providing client-side routing
• Employing two-way data binding

In this chapter, we'll be focusing on the last goal.

Two-way data binding is absolutely crucial if we are to develop even a moderately complex single-page web application. Here's how it works.

Suppose we're developing a phone book application. More than likely, we will have a model—or entity, map, or what have you—that represents a contact. The contact model might have attributes such as name, phone number, and email address.

Of course, this application would not be all that useful if users couldn't update contact information, so we will need a form that displays the current details for contact and lets you update the contact's information.

The contact model might have been loaded via an AJAX request, and they might have used explicit DOM manipulation code to display the form. This would look something like the following pseudocode:

function editContact(contactId) { contactService.get(contactId, function(data) { contactForm.setName(data.name); contactForm.setPhone(data.phone); contactForm.setEmail(data.email); }) } 

But what happens when the user updates someone's information? We need to store it somehow. Upon clicking on save, a function such as the following would do the trick, assuming you're using jQuery:

$("save-button").click(function(){ contactService.update(contactForm.serialize(), function(){ flashMessage.set("Contact Updated.") }) 

This seemingly harmless code poses a big problem. The contact model for this particular person is now out of date. If we were still developing web applications the old way, where we reload the page at every update, this wouldn't be a problem. However, the whole point of single-page web applications is to be responsive, so it keeps a lot of state on the client, and it is important to keep our models synced with our views.

This is where two-way data binding comes in. An example from AngularJS would look like the following:

// JS // in the Controller $scope.contact = { name: 'Leonardo Borges', phone '+61 xxx xxx xxx', email: '[email protected]' } <!-- HTML --> <!-- in the View --> <form> <input type="text" name="contactName" ng-model="contact.name"/> <input type="text" name="contactPhone" ng-model="contact.phone"/> <input type="text" name="contactEmail" ng-model="contact.email"/> </form> 

Angular isn't the target of this chapter, so I won't dig into the details. All we need to know from this example is that $scope is how we tell Angular to make our contact model available to our views. In the view, the custom attribute ng-model tells Angular to look up that property in the scope. This establishes a two-way relationship in such a way that when your model data changes in the scope, Angular refreshes the UI. Similarly, if the user edits the form, Angular updates the model, keeping everything in sync.

There are, however, two main problems with this approach:

• It can be slow. The way Angular and friends implement two-way data binding is, roughly speaking, by attaching event handlers and watchers to view both custom attributes and model attributes. For complex-enough user interfaces, you will start noticing that the UI becomes slower to render, diminishing user experience.
• It relies heavily on mutation. As functional programmers, we strive to limit side effects to a minimum.

The slowness that comes with this and similar approaches is two-fold. First, AngularJS and friends have to watch all of the properties of every model in the scope to track updates. Once the framework determines that data has changed in the model, it then looks up parts of the UI, which depend on information such as the fragments by using ng-model, and then it re-renders them.

Secondly, the DOM is the slowest part of most single-page web applications. If we think about it for a moment, these frameworks are triggering dozens or perhaps hundreds of DOM event handlers to keep the data in sync, each of which ends up updating a node—or several in the DOM.

Don't take my word for it, though. I ran a simple benchmark to compare a pure calculation versus locating a DOM element and updating its value to the result of the said calculation. Here are the results—I've used JSPerf to run the benchmark, and these results are for Chrome 37.0.2062.94 on macOS X Mavericks^[2]:

document.getElementsByName("sum")[0].value = 1 + 2 // Operations per second: 2,090,202 1 + 2 // Operations per second: 780,538,120 

Updating the DOM is orders of magnitude slower than performing a simple calculation. It seems logical that we would want to do this in the most efficient manner possible.

However, if we don't keep our data in sync, we're back to square one. There should be a way by which we can drastically reduce the amount of rendering being done, while retaining the convenience of two-way data bindin...

Table of contents

• Title Page
• Copyright and Credits
• About Packt
• Contributors
• Preface
• What is Reactive Programming?
• A Look at Reactive Extensions
• Asynchronous Programming and Networking
• Introduction to core.async
• Creating Your Own CES Framework with core.async
• Building a Simple ClojureScript Game with Reagi
• The UI as a Function
• A New Approach to Futures
• A Reactive API to Amazon Web Services
• Reactive Microservices
• Testing Reactive Apps
• Concurrency Utilities in Clojure
• Appendix - The Algebra of Library Design
• Other Books You May Enjoy