In this section we create the Data module as shown in figure 6.11.
This will prepare the client to use “real” data and services from the server instead of our Fake module. The application will not work after we have completed this section, as the required server capabilities aren’t yet in place. That will come in chapters 7 and 8.
Beware SPA “framework” libraries bearing gifts
Some SPA “framework” libraries promise “automatic two-way data binding” which certainly sounds good. But we’ve learned a few points of caution about such promis- es in spite of the impressive canned demos:
■ We’ll need to learn the language of the library—its API and terminology to make it do the things a well-groomed presenter can do. This can be a significant investment.
■ The library author often has a vision of how an SPA is supposed to be struc- tured. If our SPA doesn’t meet that vision, retrofitting can get expensive.
■ Libraries can be big, buggy, and offer another layer of complexity where things can go wrong.
■ The library’s data binding may often not meet our SPA requirements.
Let’s focus on that last point. Perhaps we’d like a user to be able to edit a row in a table, and when finished, either accept the entire row or cancel (in which case the row should revert back to old values). And, when the user is done editing rows, we’d like to have the user accept or cancel the entire edited table. And only then would we even consider saving the table to the backend.
The probability of a framework library supporting this kind of reasonable interaction
“out-of-the-box” is low. So if we go with a library, we’ll need to create a custom over- ride method to circumvent the default behavior. If we have to do that just a few times, we can easily end up with more code, more layers, more files, and more complexity than if we’d written the damn thing ourselves in the first place.
After a few well-intended attempts, we’ve learned to approach framework libraries with caution. We’ve found they can add complexity to an SPA rather than making de- velopment better, faster, or easier to understand. That doesn’t mean we should nev- er use framework libraries—they have their place. But our example SPAs (and quite a few in production) work fine with just jQuery, some plugins, and a few specialized tools like TaffyDb. Often, simpler is better.
We’ll need to add the Socket.IO library to the list of libraries we load, as this will be our message transport mechanism. This is accomplished as shown in listing 6.19.
Changes are shown in bold:
...
<!-- third-party javascript -->
<script src="socket.io/socket.io.js" ></script>
<script src="js/jq/taffydb-2.6.2.js" ></script>
...
We wish to ensure that the Data module is initialized prior to the Model or the Shell, as shown in listing 6.20. Changes are shown in bold:
...
var spa = (function () { 'use strict';
var initModule = function ( $container ) { spa.data.initModule();
spa.model.initModule();
spa.shell.initModule( $container );
};
return { initModule: initModule };
}());
Next we update the Data module as shown in listing 6.21. This module manages all the connections to the server in our architecture, and all data communicated between the client and server flows through this module. All that this module does may not be
Listing 6.19 Include the Socket.IO library in the browser document—spa/spa.html
Listing 6.20 Initialize Data in the root namespace module—spa/js/spa.js Figure 6.11 The Data model in our SPA architecture
Ensure Data is initialized before the Model and the Shell.
225 Create the Data module
clear at present, but don’t worry—we’ll cover Socket.IO in further detail in the next chapter. Changes are shown in bold:
...
/*global $, io, spa */
spa.data = (function () { 'use strict';
var
stateMap = { sio : null }, makeSio, getSio, initModule;
makeSio = function (){
var socket = io.connect( '/chat' );
return {
emit : function ( event_name, data ) { socket.emit( event_name, data );
},
on : function ( event_name, callback ) { socket.on( event_name, function (){
callback( arguments );
});
} };
};
getSio = function (){
if ( ! stateMap.sio ) { stateMap.sio = makeSio(); } return stateMap.sio;
};
initModule = function (){};
return {
getSio : getSio, initModule : initModule };
}());
Our final step in preparation to use server data is to tell the Model to stop using fake data, as shown in listing 6.22. Changes are shown in bold:
...
spa.model = (function () { 'use strict';
var
configMap = { anon_id : 'a0' }, stateMap = {
...
},
isFakeData = false, ...
Listing 6.21 Update the Data module—spa/js/spa.data.js
Listing 6.22 Update the Model to use “real” data—spa/js/spa.model.js
Create the socket connection using the /chat namespace.
Write the code to return our methods for an sio object
Ensure the emit method sends data associated with a given event name to the server.
Ensure the on method registers a callback for a given event name. Any event data received from the server will be passed back to the
callback. Create a getSio method,
which tries to always return a valid sio object.
Create an initModule method. This doesn’t do anything yet, but we always want to ensure it’s available and that our root namespace module (spa/
js/spa.js) invokes it before the initialization of the Model or the Shell.
Neatly export all public data methods.
After this last change, when we load our browser document (spa/spa.html) we’ll find our SPA won’t function as before, and we’ll see errors in the console. If we want to con- tinue development without the server, we can easily “flip the switch” and revert the isFakeData assignment to true.1 Now we’re ready to add the server to our SPA.