Go with the flow
I recently completed the major components of a large project at work where I was refactoring an internal messaging system. Being a typical business-driven software shop (yes I know every software shop is business driven but I may go into that in another post) our code is a bit of a mess and there is a large mixture of architectures and styles present within various features of our relatively large web application. Currently, most pages are written using ASP.NET Web Forms which I have come to despise greatly due to the extreme reliance on postbacks to the page. For the refactor I was involved in I was given the green light to try and bring our development practices into the 2010’s. This meant a host of new JSON services written with MVC since we don’t currently use Web API which depresses me a bit but it’s not the end of the world it just takes a bit longer to develop. The exciting piece for me personally though was that I got to try my hand at crafting an implementation of Facebook’s flux architecture for client side web applications.
The flux architecture caught my eye at first because it looked like Facebook was trying to sound cool by inventing another MV* architecture that wasn’t all that different from the ubiquitous MVC pattern. However after reading through the description a few times I finally caught on to the insight flux brought to the table which was a very simple and well-defined flow of data through the application (flux means flow). Like MVC there are three major components to this style of application development. Everything starts at the data stores which house your model instances and provide an initial state. This initial state is read by one or many controller-views/smart-views to render the page. As the user interacts with the page the views trigger custom events through a global dispatcher component where the data stores complete the cycle by registering handlers for events that are fired from the dispatcher. If any underlying data changes within the data stores the stores generate an event indicating that data has changed and the views can listen to a stores change events and rerender as needed. This brings enormous benefits in terms of code organization and separation of concerns especially when compared to the somewhat absurd jumble of random jQuery methods scattered about with explicit onclick attributes polluting the html.
What was very satisfying to me was that I was able to implement this quite effectively with Backbone, Underscore, and jQuery having had little to no experience with Backbone or Underscore. Within Backbone I used collections as my data stores along with (somewhat obviously) Backbone views for my views. Some perks of using Backbone include a nice model object to provide defaults, getters, and setters and a concise method for defining jQuery event handlers for your UI. I know there is a lot more that Backbone provides but I didn’t use much else since REST style services are not prevalent in the main application and we were using an older version of Backbone which caused some headaches as I tried to figure out why my code kept throwing errors as I was trying to use new features not supported by the version I had available (I like trying out new ideas and concepts but have been around long enough to know the dangers of randomly updating shared libraries in such a large application). In the end though it produced a nicely organized single page feature with outstanding performance especially compared to the rest of our application’s constant full page refreshes.
That’s my first experience with implementing the flux architecture and I will definitely be building on the things I learned. Hopefully my ramblings made enough sense to inspire you to try flux the next time you are building out a complex client side web application.