A Gentle Reintroduction to the Reactive Extensions for JavaScript Part 1

In the previous post, I briefly covered that yes, the Reactive Extensions for JavaScript is alive, with two releases to show for it.  Before going into the depths of what’s in the box for V1 and V2, I want to step back and cover some of the basics and why you might care about this library.  It’s great to talk about APIs and general capabilities, but let’s first cover asynchronous and event-based programming in JavaScript today.

Callbacks as a Way of Life

The life of a JavaScript programmer is filled with callbacks whether it is listening to events, creating Ajax requests or even simple coordination using setTimeout, there is no getting around this.  For many who hang out on the Node.js mailing list, this continues to be a pain spot as they dip their toes into large scale application development in JavaScript. 

In any given day in the browser, you might be using

  • DOM and Custom Events
  • Timeouts and Intervals (setTimeout, setInterval)
  • Ajax Requests

And with the introduction of HTML5, we have even more possibilities for rich interactions adding in, each with their own way of expressing asynchronous/evented behavior.

  • Scheduling (requestAnimationFrame)
  • Geolocation
  • EventSource
  • File API
  • IndexedDB
  • Web Sockets
  • Web Workers

Node.js also embraces JavaScript to the core by using callbacks everywhere from the file and network APIs down to event emitters.

Making the Case for Composition

With me highlighting all of the areas of callbacks within a JavaScript developer’s daily routine, is there anything wrong with it?  By themselves, no, meaning if I just want to handle a single click event on a DOM element and then take result from an input and query an Ajax service via a Promise API, and populate the results, standard callbacks work just fine, whether nested or named functions.

But, what if we want to go a little deeper than that?

  • What if we want to throttle data such as key up events?
  • What if we want to filter the data before querying another service?
  • What about composition?  Can I combine events together?
  • The list goes on…

When we start addressing those concerns, then we quickly lose sight of the actual logic required for simply taking text and querying a service.  It goes from a pretty simple solution to something a bit harder to understand.

Instead, we should be focusing on our actual behavior that we want, such as the distinct values after an allotted period of time.  What if we could design an API where we can add compositional behavior via a Fluent API to solve this issue?  The Reactive Extensions for JavaScript provides a mechanism to do exactly that via a well known pattern of the Subject/Observer pattern.

This is just a simple example, but the idea is that we can combine together both events which yield zero to many values, with single return methods such as Ajax requests, in a single API.  Patterns such as Promises go only so far with assurances of composition in a single way of dealing with completion, progress and errors, but it doesn’t address the very core issue of event composition.

Conclusion

In the coming posts, I’ll go over in detail, reintroducing the Reactive Extensions for JavaScript, why it’s useful and where you can take advantage of it.  Check us out on GitHub, download us via NuGet or the MSDN Data Developer Center, and give feedback on the forum!

This entry was posted in JavaScript, Reactive Framework and tagged , . Bookmark the permalink. Follow any comments here with the RSS feed for this post.

Comments are closed.