The Shell discussed in chapter 3 is responsible for application-wide tasks like manage- ment of the URI anchor or cookies, and it dispatches feature-specific tasks to carefully isolated feature modules. These modules have their own View, Controller, and a slice of the Model that the Shell shares with them. An overview of the architecture is shown in figure 4.1:1
Sample feature modules might include spa.wb.js to handle sketching on a work- bench, spa.acct.js for account management features like sign-in or sign-out, and spa.chat.js for the chat interface. Because we seem to be on a roll with chat, we’ll focus on that module in this chapter.
1 The author has this diagram taped to the wall next to his desk.
Figure 4.1 Feature modules in SPA architecture (shown in white)
97 The feature module strategy
4.1.1 A comparison with third-party modules
Feature modules are a lot like third-party modules, which provide all sorts of capabili- ties to modern websites.2 Example third-party modules include blog commenting (Dis- Qus, or LiveFyre), advertising (DoubleClick or ValueClick), analytics (Google or Overture), sharing (AddThis or ShareThis), and social services (Facebook “Like” or Google “+1” but- tons). They’re enormously popular because website operators can add high-quality features to their sites at a tiny fraction of the cost, effort, and maintenance than if they were to develop the features themselves.3 Typically, third-party modules are added to a website by including a script tag in a static web page, or adding a function invocation to an SPA. Many features on many websites wouldn’t be possible were it not for third- party modules, as the costs would otherwise be prohibitive.
Well-written third-party modules share these common characteristics:
■ They render in their own container, which may be provided for them, or they append to the documents themselves.
■ They provide a well-defined API to control their behaviors.
■ They avoid corrupting the host page by keeping their JavaScript, data, and CSS care- fully isolated.
Third-party modules have some disadvantages. The primary problem is that the
“third-party” has its own business goals, which may be at odds with our own. This can manifest itself in many ways:
■ We’re dependent on their code and services. If they fail or go out of business, their service can be lost. If they screw up a release, they can even prevent our site from working. Sadly, this happens a lot more often than it should.
■ They’re often slower than custom modules due to server chatter or feature bloat. If one third-party module is slow, it may slow down our entire application.
■ Privacy is a concern because each third-party module has its own Terms of Ser- vice, in which their lawyers almost always reserve the right to change at a moment’s notice.
■ Features often don’t integrate seamlessly due to a mismatch of data, style, or lack of flexibility.
■ Cross-feature communication may be difficult or impossible if we can’t integrate their third-party data to our SPA.
■ Customization of the module may be difficult or impossible.
Our feature modules keep the positive characteristics of third-party modules, but because there is no third party, we avoid their disadvantages. This means that for a
2 To learn more about third-party modules and how they’re created, see Third-Party JavaScript by Ben Vinegar and Anton Kovalyov (Manning, 2012).
3 It’s hard to gauge exactly how popular third-party modules are, but it’s hard to find a commercial website with- out at least one. At the time of this writing, for example, we counted at least 16 major third-party modules in use at TechCrunch.com, with at least five analytics services alone—and a whopping 53 script tags.
given feature, the Shell provides a container that the feature module populates and controls, as shown in figure 4.2. The feature module provides a consistent API to the Shell for configuration, initialization, and use. The feature is kept isolated from other features by using unique and coordinated JavaScript and CSS namespaces, and by not allowing any external calls except to shared utilities.
Developing feature modules as if they were a third-party module allows us to take advantage of the benefits of third-party-style JavaScript:
■ Teams can be more effective because developers can distribute responsibility based on the module. Let’s face it: if you’re working on a team, the only module that isn’t third-party to you is the one for which you’re responsible. Team members who aren’t responsible for a module only need to know its API to use it.
■ The application tends to perform well as the modules manage only the portion of the application for which they’re responsible, and they’re optimized for our use without the bloat of unused or unwanted capabilities.
■ Code maintenance and reuse is much easier because modules are kept neatly iso- lated. Many of the more sophisticated jQuery plugins, such as a date picker, are effectively third-party applications. Think of how much easier it is to use a date picker plugin than it is to write your own.
And, of course, there’s one other, huge advantage to developing our feature modules like third-party modules: we’re well positioned to use third-party modules for non- core features of our web application, and then selectively replace them—as time and resources allow—with our own feature modules, which can be better integrated, faster, less invasive, or all of the above.
http://www.awesomesite.com/our/spa.html
Josh: Hi Mike
Mike: Hey Josh, what’s happening?
Looking for itinerary insp...
Chatting with Josh
=
Send
The Shell
Defines the page and the feature containers. Manages application-wide features such as cookies and the URI anchor.
Feature model
Provides a well-scoped capability to the application. The module
creates and manages its own content (typically HTML or SVG) in a container provided by the Shell.
Figure 4.2 Shell and feature module responsibilities
99 The feature module strategy
4.1.2 Feature modules and fractal MVC pattern
Many web developers are familiar with the Model-View-Controller (MVC) design pattern because it’s presented in many frameworks such as Ruby on Rails, Django (Python), Catalyst (Perl), Spring MVC (Java), or MicroMVC (PHP). Because so many readers are familiar with this pattern, we’ll explain how our SPA architecture relates to it, particu- larly to the feature modules.
Let’s recall that MVC is a pattern used to develop an application. Its parts include:
■ The Model, which provides the data and business rules of the application.
■ The View, which provides the sensory (usually visual, but also often audio) rep- resentation of the Model’s data.
■ The Controller, which converts requests from the user into commands that update the Model and/or View of an application.
Developers familiar with a web MVC framework should be comfortable with most of this chapter. The greatest difference between a traditional web developer’s view of an MVC framework and our SPA architecture is as follows:
■ Our SPA moves as much of the application to the browser as possible.
■ We recognize the MVC pattern is repeated as if in a fractal.
A fractal is a pattern that displays self- similarity on all levels. A simple example is illustrated in figure 4.3, where from a distance we see a general pattern, and as we look closer we see the pattern repeat- ing at finer levels of detail.
Our SPA architecture employs a repeating MVC pattern at multiple levels, so we call it Fractal Model-View-Controller, or FMVC. This concept isn’t new, and developers have been discussing it with the same name for at least a decade. How much of the fractal we see is a matter of per- spective. When we view our web application from a dis- tance, as in figure 4.4, we see a single MVC pattern—the Controller handles the URI and user input, interacts with the Model, and provides us with a View in the browser.
When we zoom in a bit, as seen in figure 4.5, we see
that the web application is split into two parts: the server side, which employs an MVC pattern to feed data to the client, and an SPA, which employs MVC to allow the user to view and interact with the browser Model. The server’s Model includes the data from the database, whereas the View is the presentation of the data that gets sent to the browser, and the Controller is the code that orchestrates data management and com- munication with the browser. On the client, the Model includes the data that’s been received from the server, the View is the user interface, and the Controller is the logic that orchestrates the client data with the interface.
Figure 4.3 Box fractal
Model View Controller Web application
Figure 4.4 Our web applica- tion from a distance
When we zoom in closer still, as in figure 4.6, we see yet more MVC patterns. The server application, for example, employs an MVC pattern to provide an HTTP data API. The database that the server application uses employs its own MVC pattern. On the cli- ent, the client application uses an MVC pattern, yet the Shell calls subordinate feature modules, which themselves use MVC patterns.
Almost all modern websites fit this pattern, even if the developers don’t recognize it.
For example, once a developer adds a commenting feature from DisQus or LiveFyre to their blog—or virtually any other
third-party module—they’re adding another MVC pattern.
Our SPA architecture embraces this fractal MVC pattern. In other words, our SPA works nearly the same way whether integrating a third-party feature or a feature module we write ourselves. Figure 4.7 shows how our Chat module will employ its own MVC pattern.
We’ve covered where feature mod- ules fit into our architecture, how they’re similar to third-party modules,
Model View Controller
Server Client
Model View Controller Web application
Figure 4.5 Our web application a little closer
Model View Controller Server application
Database Client application
Model View Controller Web application
Model View Controller Model
View Controller
Feature
Figure 4.6 Our web application up close and personal
Model
(spa.model.js) View
(spa.chat.js, DOM methods) Controller
(spa.chat.js, event handlers)
Figure 4.7 The MVC pattern as it appears in our Chat feature module
101 Set up feature module files
and how they employ fractal MVC. In the next section, we’ll put these concepts to use and create our first feature module.