, , ,

Yeoman, Karma, jQuery, Require, Backbone, SASS, Mocha, Dust, i18n... oh my!

, , ,

I've added a skeleton file directory / config to github in order to perhaps save you time in setting up an application using the tools listed in the title. https://github.com/mrforbes/yeoman-backbone-stack

The main reason I added it was because getting Testacular Karma working with require was not as straightforward as I had originally assumed it would be, owing to the fact that you need to tell Karma which files to include, but require wants to include them all asynchronously. The workaround is in the karma.conf.js file:

files = [
  MOCHA,
  MOCHA_ADAPTER,
  REQUIRE,
  REQUIRE_ADAPTER,
  'app/scripts/config.js',
  {pattern: 'test/lib/chai.js', included: false},
  {pattern: 'test/test.js', included: false},
  {pattern: 'app/nls/*', included: false},
  {pattern: 'app/nls/**/*', included: false},
  {pattern: 'app/templates/*', included: false},
  {pattern: 'app/scripts/*.js', included: false},
  {pattern: 'app/scripts/libs/*.js', included: false},
  {pattern: 'app/scripts/plugins/*.js', included: false},
  {pattern: 'test/spec/*.js', included: false},
  'test/test-main.js'
];

 

The included:false command tells Karma the files will be there, but it doesn't inject them into the head, which leaves require to do its thing.

The second spot to notice is test/test-main.js... This is where all of the actual test files need to be added, instead of in the karma.conf.js file. You still need to alert Karma to them ( {pattern: 'test/spec/*.js', included: false} ), but you don't want them loaded that way.

Here's test-main.js:

require({
  // !! Karma serves files from '/base'
  deps: ['app','main'],
  baseUrl: '/base/app/scripts'
}, [
/* test runners go in here */
'../../test/spec/example',
'../../test/spec/i18n',
'../../test/spec/router',
'../../test/spec/index'
], function() {
  window.__karma__.start();
});

 

Pretty self-explanatory. Karma will wait to start until all of the specs have been loaded.

So.. if you have the need, grab the repo. Keep in mind this is a skeleton not a finished app, so some of the structure decisions are likely not optimal, and definitely not final. Move stuff around to suit your style / needs.

 

UPDATE 3/11/2013: I've updated the git repository to the Yeoman 1.0 beta. The 1.0 version of yeoman has some major changes in it, so the new application framework reflects those changes.

I've also added the following:

  1. JsHint watching
  2. Karma through Grunt (watching through Grunt)
  3. Debug code removal (grunt-groundskeeper)
  4. Backbone form validation, model binding, and deep model libraries
  5. Dust templates were always there, but I never mentioned them in the original post

UPDATE 5/3/2013: Testacular has been renamed Karma (for which I am thankful). I changed my references to match.

, ,

Web Performance Optimization Tip - jQuery + Document Fragments

, ,

Here's the setup... You have a REST API returning a JSON object filled with a bunch of data that you want to put into a list. It looks vaguely like this:

[{1234:{name:'bob'}},{5678:{name:'karen'}}]

 

Two names for brevity, but the list can be N length.

Let's say you want to put this into a simple list of names.

Here's the way I still see way too many devs doing it:

<html>
<body>
<ul class="names"></ul>

<script>
$(function(){
  var restResponse = [{1234:{name:'bob'}},{5678:{name:'karen'}}];

  $.each(restResponse,function(index,value){
       $('.names).append('<li>'+value.name+'</li>'); 
  }); 
});
</script>
</body>
</html>

 

It works.. and its not really THAT bad for two names.. but what if you had 100, or 1000? Especially if you are developing for mobile, you need to use this, or you're killing your performance over one fairly simple block of know-how.

That know-how is called document fragments. I'm not going to go in depth on what document fragments are, you can check out the post on the subject by John Resig here.

The short version is that they are DOM elements you can create in memory, that don't cause screen redraws when you manipulate them. The benefit: You can add LOTS of nodes to them in memory, write them to the screen, still keep them in memory, remove them from the screen, still keep them in memory, and manipulate them as some kind of awesome phantom DOM object. Seriously, document fragments are bad-ass, and if you want to be bad-ass, you need to know how to use them. Not only that, but jQuery makes it stupendously easy to work with them.

Let's go back to the example... What if we make some minor modifications?

<html>
<body>
<div class="names"></ul>

<script>
$(function(){
  var restResponse = [{1234:{name:'bob'}},{5678:{name:'karen'}}];
  var $ul = $('<ul>');
  $.each(restResponse,function(index,value){
       $ul.append('<li>'+value.name+'</li>'); 
  }); 
  $('.names').append($ul); // or you could do $ul.appendTo('.names') whatever makes you smile.
});
</script>
</body>
</html>

 

Do you see what I did there? Here it is in super slow-mo:

var $ul = $('<ul>');

 

Yes, that made a document fragment of an unordered list. That's all it took. You can also add attributes to it like this:

var $ul = $('<ul>',{id:'listOfNames'});

 

Then we loop through our JSON object and stick each list item into the fragment:

 $.each(restResponse,function(index,value){
       $ul.append('<li>'+value.name+'</li>'); 
  });

 

Then we stick it onto the screen.

$('.names').append($ul); // or you could do $ul.appendTo('.names') whatever makes you smile.

 

If you've been making this mistake, stop now and go refactor your code.

, ,

Thinking Big... Architecting a large application with jQuery / Backbone / Require, an Overview

, ,

A Little Background Recently at work we've been in heavy development mode on a new thick-client application architecture.  If you aren't familiar with the concept, thick-client essentially means putting most of the work onto the client's processor, and removing it from the server.  The benefits of this are many, not the least of which is a much faster site response time for your users, and a much lighter load for your server.

To accomplish this basically means using javascript and a lot of AJAX, as well as implementing the application such that that a) search engines can still index your site and b) the user can both bookmark and use the back button wherever they are in your app.

In order to facilitate this heavy use of ajax and management of state, a number of MVC(ish) patterned javascript libraries have been created, and more appear seemingly every week.  After a little bit of research, we settled on Backbone due to its barebones nature, low overhead, lesser learning curve, and the size of the community.  It always helps to be able to reach out when you get stuck.

In combination with jQuery (we are already using it heavily), and Require.js (a dynamic resource loader which has also been in use for quite a while), we had the perfect trinity of tools to get the job done.

Basic App Structure

There are a lot of things to consider when architecting a large application.  For HMS, this is compounded by the fact that a) we have a lot of users with a lot of different site configurations, b) we have different variations on the main backend application, c) there is a lot of legacy code and newer front-end logic that needs to maintain compatibility so that pieces can be added one at a time.   This is where Require and its support of AMD (asynchronous module definition) really shines.

All of our thick-client application code is managed through AMD, and there are two things about it that are very awesome:

  1. It allows seamless integration on a module-by-module basis with the current application code
  2. Even portions of modules can be broken out and used before their parent module is complete - for example, we already have the autocomplete module live, even though the search module is still in development. When the time comes, it will be trivial to move it back into its proper place.

The general application structure goes like this:

  1. Event Aggregator Outlined here, we have a single global object, and its job is to manage communication between modules.
  2. Outer Router We have two routers.  This helps keep the application router a lot simpler, and keeps module related logic inside the module. The outer router manages routes for the entire application, and determines which modules to load.
  3. User Module Right now, this is the only module that sits everywhere in the application. As such, it is loaded by the outer router.
  4. Modules Each module contains its own router as well as templates and views. The router loads the views, the views load the templates (we're using Hogan).  When we compile with require, each module (including templates) becomes a single file (the module router).
  5. Models The models are the glue between the client and the server,  and they sit in their own folder because multiple modules may use the same models.
  6. Form Mediator This is actually one of the modules, but its worth describing here.  We use a special Backbone view to handle every form, enhancing functionality as we go.  This view simplifies forms immensely, managing the model, validation, and state with ease.  Its special power is to allow multiple modules to combine into a single form definition - most usefully for search / advanced search.
  7. UI Modules Most DOM manipulation (outside of insertions/removals)  and all UI effects are offloaded into separate UI modules.  The reasons for this are a) it separates presentation concerns and b) it allows for a much easier time should we decide to switch from jQuery for future manipulation (one can dream of full standards support across browsers)
  8. Backbone.Store (localStorage) Of course we're using this for our app.  Currently it persists forms, helps maintain the user session client-side, and caches model data.

Obviously, there are many ways to architect a thick-client application.  Our approach intends to prevent module dependency (outside of UI Modules), separate DOM manipulation from data logic, keep communication centralized in an event aggregator, load quickly (through smart module loading and use of localStorage, among other things), and preserve the global namespace through the use of AMD.  There are a lot of details I've left out (for instance reuse for mobile), but I do hope to dive a little deeper in future posts.

 

 

, ,

Introducing Backbone.Store ... JSON storage for Backbone.

, ,

Right now, you can't do much better for quickly developing javascript applications and modules than the triumvirate of  Backbone, jQuery, and Require.  Each of these libraries fit together so well (IMO), and have increased my personal productivity immensely - improving quality, performance, readability, and consistency. There was already a great library for Backbone to utilize HTML5 localStorage functionality; however, there were a few drawbacks to the library that caused me to look in another direction, and ultimately led me to creating Backbone.store.

My two greatest needs were:

  1. The ability to utilize the storage mechanism as a cache.
  2. A greater range of compatibility outside of localStorage support.

To meet these needs, I turned to Lawnchair, a JSON storage library with a wide range of adapters for different storage types, mixed in a little bit of the aforementioned backbone.localstorage plugin, and came out with the beginnings of a (hopefully) useful storage middleware.

While the overall project is in very early stages, its not too soon to look at, play with, and provide feedback on.

Download / clone from Github.

Features:

  1. Can be used with or without a backend server
  2. Configurable cache time to live
  3. Configure when to use server vs cached model - great for list  vs. detail of a record
  4. Does not require localStorage support, though a Lawnchair adapter may be needed to get the support you want.

Planned enhancements:

  1. Batch model upload to server (online/offline or time delayed)
  2. Parameter based caching (for caching paging / search results / etc)
  3. Remove Require (AMD) dependency
  4. ??? (accepting ideas)

Also included in the project is a basic 'Todo' style application including a CodeIgniter (php) based RESTful web server and structure, and a Backbone/Require/jQuery front-end consisting of a list/detail view with complete CRUD control and proper routing using both direct (bookmarkable) URL access and pushState routing.

Again, this project is nowhere near complete, so I'm sure there are some bugs... Still on the todo list is to add test cases using Sinon and Jasmine, and there is a known issue with the list -> detail -> list navigation.

 

 

,

jQuery DynoMenu - a plugin with a purpose

,

I've just added the first of hopefully many jQuery plugins and bits of useful javascript to Github.  Called DynoMenu, it is a plugin with a very specific and singular purpose.. yet it may have value to others who find themselves with a similar need. DynoMenu was conceived to solve a problem on HomesConnect.  Since HomesConnect is a CMS that allows users to add new pages and new menu items to their navigation, and since the navigation is horizontal across the top of the page, the need arose to be able to maintain the layout of the templates while removing the burden of keep the navigation usable from the agent.

The solution was this plugin, which will first try to shrink the navigation font to a determined size, and if failing will systematically remove navigation items until it achieves the best fit. These items are placed in a 'more' link which becomes the last main navigation item, and can be accessed from there.  Since the agent can determine the order of their navigation via a drag and drop interface on the backend, it is easy for them to decide which items will fall under the 'more' link by pushing them to the end of the navigation.

In any case this may not have much use outside of CMS systems where you cannot control the total number of nav items, but who knows.. maybe there is a use case I'm not considering.

Download it from Github here. See a demo.

Copyright 2020, M.R. Forbes, Quirky Algorithms.
All rights reserved.

Cart (0)