Javascript Primer: Use Messaging For Loosely Coupled ViewModels

This is a continuation of the Javascript Primer series where we focus on topics essential for .Net or back-end developers or who are transitioning to Javascript and client side development. Many of the topics covered in this series will be related to producing web apps running in the browser. Some design patterns and practices are also application to NodeJS / server-side Javascript apps as well.

Keeping IT Together

One complaint that many have when embarking on applications of medium complexity is that organizing your code is difficult; indeed, even with frameworks you can still end up with giant god object that contains all data-bindings, algorithms, helpers methods. If you take the attitude that Javascript is a second class, toy language where you simply store jQuery animation methods and AJAX calls, you quickly end up with files that can be 3-4000 lines long! Maintaining that is beyond torture.

A common design pattern used to alleviate this issue is the Model View ViewModel (MVVM) pattern. The goal of MVVM is to divide up the logic of your application into UX, business logic, and data-binding activities into discrete components. KnockoutJS is a popular framework that supports this approach. Addy Osmani’s “Design Patterns for Javascript” defines the primary components of MVVM, and it is great primer to read if you are unfamiliar with these terms. For our purposes:

Model will contain the data elements, such as FirstName, LastName, etc. Essentially this is a building block for your front-end that will “model” entities such as user, customer, project, etc.

ViewModel will contain the behavior for the UI. This can be business logic, formatting of data, and bridge the gap between data coming from a server and what is useful for the user to interactive with. The ViewModel will also use the Models.

View will be the html document. This will also contain the directives for what to present to the user, and will interact with the ViewModel.

We Still Have A Problem

So even with the MVVM pattern at our disposal we still have to fight bloated ViewModels. From here out we will use a sample project for our discussion where we want to maintain project information comprised of project name, project description, and project notes, team members and a simple timeline / calendar function. Sounds straight forward enough. On our UI we will have a tab for grouping of information, and as information changes on a tab, we want that information available in each subsequent tab. Again, nothing too earth shattering here. It should look something like this JSFiddle below. (NOTE: For the sake of this exercise all code has been placed in the Javascript section of our JSFiddle. You should split your code into modules so they can easily managed).



Each tab on this screen has logical groupings of information. For the sake of argument let’s say that we decide to implement this UI with just one ViewModel for all three tabs. For databinding we will be using KnockoutJS, Starting out we have just one ViewModel – ProjectViewModel – that handles all updates; more specifically, we can take advantage of the data-binding facilities here, so when a team member is added, we can detect this change and automatically execute and update to the calendar.

We have three tabs – “Project Info” is pretty simple, and it uses the computed observable teamSize to display the count of the project team. You note that any changes to “Project Name” will be reflected on the “Team” tab. The tab “Team“ allows you to add a team member. To support updating the calendar with the team member start date we have create subscription to the projectTeam observable array. The tab “Timeline” has a calendar that displays the team member start date, and this is updated each time we add a new team member. Also, any changes to the number of team members will be reflected on the first tab, “Project Info”.

Indeed this works well, since we have the advantage of one ViewModel and can benefit from easily sharing one set of data between all three tabs, But we still have an issue should we start adding more functionality and increase the properties and functions in the ProjectViewModel. Soon maintaining the ViewModel will become difficult, and testing discrete portions of functionality will rapidly become difficult. We need to be able to isolate or reduce the impact that the alterations made to the ViewModels have on each other. This means adhering to the principal of “loose coupling”.

So what does it mean for us to create a ViewModel per tab? The biggest issue now will be communicating between each ViewModel, and as always, our mantra should be “Keep it simple. Please. Pretty please”. So how do we achieve communicating data updates without creating three ViewModels that are still highly dependent on the others? Our solution is to implement a subscribe and publish message architecture. While this sounds intimidating, this simply means we will create each ViewModel with a method – a “subscription” – that will wait for a message that has the data we need. As a corollary, each ViewModel need a way to “publish” any changes to data that occurs.

Super Simple Message with PostalJS

PostalJS is a very simple messaging framework that facilitates sub / pub messaging in a unique way. In particular, PostalJS allows us to set up a subscription that remains “ignorant” of how the message is generated. There is no “pre-registration processes” to map out a route between ViewModels; on the contrary, your Javascript object simply declares that will update when a subscription arrives. This also means that several ViewModels can subscribe to an event and the publisher doesn’t care.

Here is a brief sample taken from github:

var subscription = postal.subscribe({ channel: "orders", topic: "item.add", callback: function(data, envelope) { // `data` is the data published by the publisher. // `envelope` is a wrapper around the data & contains // metadata about the message like the channel, topic, // timestamp and any other data which might have been // added by the sender. } }); postal.publish({ channel: "orders", topic: "item.add", data: { sku: "AZDTF4346", qty: 21 } });

Looks pretty cool. And simple. So for us, our ViewModels will remain ignorant of each other, and only are aware that someone, something has sent data to it. Another nice by product is that should one of the ViewModels fail, the impact is greatly reduced. So should the ViewModel with the calendar fail, the other tabs could still collect data and function. Better yet, adding new features to a ViewModel is going to be easier to achieve since we can test in isolation, and if the new features do not interrupt our sub / pub messaging, we can feel confident that new changes can be rolled into production without bringing down the entire application. Let’s look at the results, then examine the changes to our app’s architecture.

A Brave New World

If you open the Javascript tab of the JSFiddle, you’ll see that we have broken up the ProjectViewModel into 3 ViewModels: TeamViewModel, TimelineViewModel, and of course the remants of ProjectViewModel. We’ll take the updates on at time, focusing on the feature in the UI and work back to the code.

Project Name As before, entering the project name in the “Project Info” tab updates the title in the “Team” tab. Same as before, the update happens when the input box loses focus. Now let’s focus on the code. Open up the Javascript in the JSFiddle, and you’ll see some drastic changes. In the ProjectViewModel we have created a Knockout trigger that publishes a message:

</pre> <pre data-language="js">_projectName.subscribe(function(newValue){ // Now use PostalJS to push message out postal.publish({ channel: "project", topic: "edit.projectNameChange", data: { projectName: _projectName() } }); });

So what we are doing here telling Knockout “Anytime there is a change to the observable _projectName, fire off a function that publishes a piece of data with the new value of _projectName”. That’s it. ProjectViewModel has fulfilled its responsibility and told anyone who will listen that a change has taken place. Now find the TeamViewModel object. Here we have a subscription that waits for a message containing _projectName updates:

</pre> <pre data-language="js">var projectNameChangeSubscription = postal.subscribe({ channel: "project", topic: "edit.projectNameChange", callback: function(data, envelope) { _projectName(data.projectName); } });

We get the data, and merely update an observable on the TeamViewModel. It should be apparent by now that neither ProjectViewModel nor TeamViewModel “know” about each. ProjectViewModel says “_projectName update ready” and who can handle it, does so. TeamViewModel just grabs the update, uses it. That’s it. The messaging works by creating a “channel” – in this case “project” – further defines the message with a topic – “edit.projectNameChange”. This means you can a single channel that support multiple topics and narrowly define your event messages.

ProjectTeam Update Play around with the “Team” tab and add some team members with different dates. The operates just as before. Under the hood, the code in TeamViewModel that handles the publishing is:

</pre> <pre data-language="js">_projectTeam.subscribe(function(){ // this is how postaljs publishes events postal.publish({ channel: "project", topic: "edit.teamUpdate", data: { projectTeam: ko.toJS(_projectTeam) } }); });

As before, we are asking KnockoutJS to watch for changes to the _projectTeam array, and when a change occurs, we publish a different message. The portion of code – topic: “edit.teamUpdate” distinguishes this event from the previous on. We simply take our observableArray and convert it a plain Javascript script array and throw out to whoever wants it. If you look in both ProjectViewModel and TimelineViewModel you’ll see subscriptions that handle this topic. This brings us to another important aspect of messaging and postaljs’ strength: should we want to add more ViewModels that need _projectTeam updates, we only need to subscribe to the topic “edit.teamUpdate”. We could subscribe 50 more times if we wanted. The publisher / source ViewModel does not need any alteration, and this achieves our goal of loose coupling.

What Are The Other Benefits?



Looking at our ViewModels, you may have noticed that we are exposing less in the return statements, and with each ViewModel handling less functionality they become simpler to read and maintain. Imagine that the needed to support 20 different data entry input boxes – one monster ViewModel would have a huge return statement. It makes it hard to keep things straight in one “god” class.

With PostalJS and event messaging we no longer need to expose an entry point in our objects for data to be passed. The subscriptions allow the ViewModel to handle receiving update messages internally. A quite common scenario would be responding to an AJAX update. With PostalJS you can avoid calls to each ViewModel when new data arrives from the server. Simply publish to the appropriate topic and let the ViewModels respond as they need.