Category Archives: Javascript

Javascript: Self-replacing Promises

Posted on by

My application has several resources that need to be loaded just once, and used often afterwards.

Here is a pattern that I’m finding quite useful lately:

/** 
 * Retrieve the resource once only.
 * If the resource hasn't been loaded yet, 
 *   return a deferred that resolves to the resource.
 * If the resource has been loaded, 
 *   return the resource directly.
 */ 
App.getResource = function() {
  //Return the resource or the deferred if it's set already
  if (App._resource) 
    return App._resource; 
  //Otherwise build, set and return a deferred that 
  //replaces itself when it's finished loading
  else
    return App._resource = $.getJSON("resource/url").then(
      function(data) {
        console.debug("Loaded resource");
        return App._resource = data;
      }
    );
};
  • The first time the function is called, it fetches the resource and returns a deferred object.
  • When the promise resolves, it passes the resource to handlers.
  • If called again before the promise resolves, it returns the same promise. (won’t fetch twice)
  • After the promise has resolved, the function instead returns the resource directly.
  • If the resource can’t be loaded, the promise fails instead, and is not replaced.

To use directly;

$.when(App.getResource()).done(function(resource) {
  //Use the parameter from the promise
  resource.doStuff();
});

The $.when call transparently converts a non-promise into a resolved promise with that value. The snippet behaves the same whether App.getResource() has been previously loaded or not.

So why replace the promise at all? Sometimes you need to be able to treat the resource like a synchronous value, such as within a library or a function that is called synchronously.

//Here's a class with a synchronously-called function
var Model = Backbone.Model.extend({
  ...
  validate: function(attrs) {
    if (App.getResource().exists(attrs[id])) {
      return "Model with that id already exists";
    } else {
      return null;
    }
  }
});
var model = new Model();

//Wait for everything necessary to load first.
$.when(App.getResource(), model.fetch(), ...).done(
  function() {
    if (model.isValid()) doFoo();
    else doBar();
  });

This code waits for App.getResource() to resolve, as well as for any other needed promises. Afterwards, App.getResource() can just be treated like a synchronous function.

This pattern enables flexible and transparent use of remote resources, in both synchronous and asynchronous ways.

The App.getResource() function is also quite similar to a Lazy Promise, as discussed by James Coglan.

 

More Javascript Templates Using ‘src’

Posted on by

There was some concern about my previous solution, that it loads templates synchronously and serially. An application should have templates inlined before it goes to production anyway.

Fair point though, there is a better way.

Better Definition

Firstly; Marionette.js can transparently lazy-load and cache DOM-stored templates;

//What I had been doing
var MyView1 = Marionette.ItemView.extend({
	template: _.template( $("#template_myview1").html() )
});

//What I should have been doing
var MyView2 = Marionette.ItemView.extend({
	template: "#template_myview2"
});

The difference between the two is significant.

  • MyView1 will access the DOM as soon as the class is defined, and build the template immediately.
  • MyView2 will access the DOM only when a MyView2 instance is constructed, but only builds the template once.

This means the templates are only built at the time they are first used. The template blocks don’t need to be accessible at the time the classes are defined. The app only needs to build the template functions the first time they are used.

Using the MyView2 style will give much faster start-up times for larger applications.

(Marionette.TemplateCache can be used stand-alone, or you can fairly easily create your own caching DOM template loader)

Better Loading

Now, the template blocks won’t be referenced until they are used. We can load them asynchronously now, but we still don’t want to start the app until the templates have been fetched. $.ready(…) won’t wait for the templates, but there’s a fairly easy workaround;

//A list of promises that need to resolve before starting
var loaded = [];

//Load all templates
var $templates = $('script[type="text/template"]');
$templates.each(function() {
	var src = $(this).attr("src");
	if (src) {
		loaded.push( //Wait for the template to load
			$.ajax(src, {context:this}).
			done(function(data) {
				$(this).html(data);
			})
		);
	}
});

//Wait for the DOM to be ready
loaded.push($.ready);

//Initialise after everything is loaded
$.when.apply($,loaded).done(function() {
	//Start application
});

There! With that in place;

  • Templates are loaded into script blocks as you’d expect, asynchronously and in parallel.
  • The application starts after the DOM and the templates are loaded.
  • For production, the templates are inlined. Without any code changes, the application will transparently start as soon as $.ready is completed.

Javascript Templates Using ‘src’

Posted on by

Background

John Resig was the first to document a technique for storing templates in <script> tags;

<script type="text/html" id="item_template">
   <li><b>{{ name }}</b> - {{ description }}</li>
</script>

This works well for several reasons;

  1. Using the unknown type “text/html” means that the browser ignores it.
  2. Giving the tag an id allows us to easily grab its contents;
//Build a new item, and add it to the list
//Using JQuery, Underscore.js
var contents = _.template(
  $("#item_template").html(),
  {name: "Foo", description:"Sir Foo the Second"}
);
$list.append( $(contents) );

Today there are many libraries available for retrieving and building templates in this way, such as Mustache.js and ICanHaz.js, and more that integrate support.

Problem

One of the only problems with this technique, is that the scripts must be declared inline.

<!-- Works! -->
<script type="text/html" id="item_template">
   <li><b>{{ name }}</b> - {{ description }}</li>
</script>

<!-- Doesn't work. -->
<script type="text/html" id="item_template2" 
                  src="templates/item2.html"></script>

If the browser doesn’t understand the type, it won’t load the source. Whatever the reason, the template text is never added to the DOM.

Inlining template contents is detrimental to readability, maintainability, and traceability.

Some libraries offer asynchronous methods for loading templates. (require.js among them) Some have issues with complexity and performance.

It feels natural to define and compile the template functions at class definition time. Other solutions may add unnecessary layers of indirection.

Solution

I’ll preface this by saying “Okay, maybe this won’t work for you”, but so far it’s working well, transparently, and fast. And when you go to production, a decent deployment optimisation process will inline the templates anyway.

What if the src attributes were read properly?

<script type="text/html" id="template_widgets"
                    src="templates/widgets.html"></script>
<script type="text/html" id="template_widgets_item 
                    src="templates/widgets_item.html"></script>
...
...
<script type="text/javascript">
  //Synchronously load the templates
  var $templates = $('script[type="text/html"]');
  $templates.each(function() { 
    //Only get non-inline templates
    //No need to change code for production.
    if ($(this).attr("src")) { 
      $.ajax(
        $(this).attr("src"), 
        {
          async:false, 
          context:this, 
          success:function(data) { $(this).html(data); }
        }
      );
    }
  });
  //From this point onwards (in the same script, in the 
  //following scripts) all the "text/html" script tags 
  //will be loaded as if they were inline.
</script>

Just insert this code after all your template tags, and before you build your template functions, and you’ll be able to treat them as if they were inline all along.

Easy.* 🙂

*There are some downsides to loading template serially and synchronously. I’ve written a follow-up article that discusses a technically better solution.