Tuning into Backbone Radio

Marionette v3 brought a number of improvements, one of which being the integration of Backbone.Radio — now maintained by Marionette Core. In this post, we’ll explore how we can use the Radio to improve communication and information flow across your application.

What is the Radio?

A simple implementation where creating a note can show a notification

Most application frameworks have the concept of a bus — a global system that lets you pass messages and data between distinct modules in your application. The Radio does this job for Marionette, letting you perform actions across your application without needing to maintain references to otherwise unrelated views or models.

As you can imagine, this simplifies building complex applications significantly without having to depend on the window object.

How Does It Work?

The Radio works by using the Backbone Events system you may be familiar with. You can fire an event on your Radio and any other objects listening to that event will pick it up and respond.

The Radio also provides an API for handling Request/Response patterns — essentially functions called without having direct access to them. The next section will go through these in more detail.

Radio Patterns

The Backbone Radio provides two major patterns: Events and Requests.

Events

Events are essentially a broadcast mechanism for announcing that something happened. Just like modelEvents and collectionEvents, you can set up many listeners.

How does this help us? In my previous posts, I’ve assumed that there’s a short path between creating an item and adding it to the list that renders it. Sometimes that can be easily done by sharing the collection with the form and just adding it directly. This doesn’t always work, and your application may not be set up to make that possible, so we’ll use the Radio to pass this information along. The example below uses the note-taking example that I’m extremely fond of:

The form emits the creation events while the view in this case listens and responds

Requests

Radio requests have two big differences from events:

1. You can only have a single handler
2. You can return a value through a request

This dynamic gives requests a different meaning — the caller either wants some information or wants a specific thing to happen. Let’s see an example of what happens when we’ve created a note:

The note form now sends a notification message

This (fairly) simple setup lets you display notifications from anywhere in your application, without needing to hold the reference of the notification view being displayed (just imagine how much of a nuisance that would be!)

Changing the Channel

I’m stretching the channel analogy

You’ve probably seen me calling the channel method on the Radio. Backbone Radio Channels work exactly like real radio channels — you broadcast and receive over a single channel to prevent interference from other channels. In our example above we defined two channels:

1. notes for communicating about Note information.
2. notify for telling the system to display notifications.

Just like JavaScript modules, these channels provide a sort of namespacing and make it easier to minimise clashes. You don’t need to create channels for everything, just try to use them where they make most sense to simplify your application.

Autotune

There’s a bit of repeated code here constantly instantiating a channel object every time. Luckily, Radio gives us a simple short-hand for referencing a channel — just call trigger or request direction on Backbone.Radio as in the example below:

Accessing requests and triggers directly through the Radio proxy to channels

How does this work with Marionette?

With version 3, Marionette integrated the Radio directly into the base Object class, meaning anything that extends the Marionette Object can tune into Radio channels, listen to events and respond to requests. Let’s see an example using the Application checking taking the user to the login screen if they are logged-out of the system:

A fairly straightforward example of integrating Radio with Application

I’ve glossed over some details here such as how you figure out whether your user is logged in or not — this will depend heavily on how your application is structured, though we may cover some strategies for this in a future post.

And that’s pretty much all the basics to get you going with the Radio. It’s a pretty straightforward tool once you get your head around the concept of calling functions over a global bus.

What Next?

I’d really like to see what you guys think of this. Was it helpful? Do you have any uses for the Radio that I’ve not covered here? If so, please get in touch with me via Twitter.

In my next two posts, I’ll cover templating — with some different template engines — and routing using the Backbone Router. Further into the future, I’ll be looking into how to share common behavior between Views using the Marionette Behavior class.

Until next time!