Client-Side Tools

Intercooler is primarily a library for making AJAX calls, but it does provide some simple but powerful tools for doing client-side DOM manipulation, allowing you to implement many client-side needs using only a few attributes:

Ready Handling

A common pattern in jQuery-based applications is to have a ready handler that executes once the page is loaded, and that often is used to hook up event handlers or to initialize javascript widgets:

    $(document).ready(function() {
      $("#my-element").click(function() { doSomethingOnClick() });
    });
  

Intercooler has a similar mechanism so that you can wire event handlers (or use javascript plugins) to partial content that has been swapped into the DOM:

    Intercooler.ready(function(rootContent) {
      rootContent.find("#my-element").click(function() { doSomethingOnClick() });
    });
  

Note that rather than doing a global lookup of elements, you do a look up from the root element of the swap, which is passed in as an argument to the callback. This helps you avoid accidentally adding multiple handlers to the same element.

Adding & Removing Classes After A Delay

In order to fine tune transitions or provide other visual easements in your app, you may find yourself wanting to add or remove classes to an element after a specified delay. Intercooler provides two attributes, ic-add-class and ic-remove-class to do this.

In this example, we apply a toRed class to the text inside the button after a click:

Timed Removal Of Elements

A common pattern in AJAX applications is to "flash" an element after a request: show the element for a bit then remove it from the DOM. Intercooler includes the ic-remove-after attribute for this situation which, like ic-poll, can take the form "2s" or "1500ms". Once the given amount of time has elapsed, the element will be removed from the DOM.

This can be paired with the ic-add-class or ic-remove-class to achieve a smooth effect.

Here is an example, where the message is faded out before being removed:

Client-Side Actions

Sometimes it is useful to have a purely-client side action in response to a given action trigger. A good example is if you wish simply to remove a element when another element is clicked, without a server request. Intercooler provides the ic-action attribute for this situation.

The full details of the syntax for this attribute are available on the detail page for it, but here are a few examples:

   <a ic-action="fadeOut;remove">Fade Then Remove Me!</a>
        

  <a ic-action="slideToggle" ic-target="#chesterton-quote">Toggle Chesterton!</a>
        

Switch Class

Sometimes you may want to switch a class between siblings in a DOM without replacing the HTML. A common situation where this comes up is in tabbed UIs, where the target is within the tabbed UI, but the tabs themselves are not replaced.

Intercooler has an attribute, ic-switch-class that enabled this pattern. It is placed on the parent element and the value is the name of the class that will be switched to the element causing the intercooler request.

Below is an example of a tabbed UI using this technique. Note that the tabs are not replaced, but the active class is switched between them as they are clicked.

        <ul class="nav nav-tabs" ic-target="#content" ic-switch-class="active">
          <li class="active"><a ic-get-from="/tab1">Tab1</a></li>
          <li><a ic-get-from="/tab2">Tab2</a></li>
          <li><a ic-get-from="/tab3">Tab3</a></li>
        </ul>
        <div id="content">
          Pick a tab
        </div>
        

  <a ic-action="slideToggle" ic-target="#chesterton-quote">Toggle Chesterton!</a>
        

History Support

Intercooler provides simple history support for AJAX calls. This functionality is currently experimental, but is usable and unlikely to change dramatically going forward.

If you want an intercooler call to push its target URL into the location bar and create a history element, simply add the ic-push-url attribute to the element and ensure that the target of the element has a stable HTML id.

Here is an example:

    <a id="hist-link" ic-post-to="/history_demo" ic-push-url="true">Click Me!</a>
  

When Intercooler makes a request to /history_demo it snapshots the HTML of the target before swapping in the new content and saves this snapshot to local storage. It then does the swap and pushes a new location onto the history stack.

When a user hits the back button, Intercooler will retrieve the old content from storage and swap it back into the target, simulating "going back" to the previous state.

Specifying History Snapshot Element

If you use history extensively within your app, you will want to use a stable element for snapshotting HTML so that if a user is many pages deep in a click stream and goes back multiple steps, the element that will be restored into is still available on the screen. There is typically a div that wraps the main content of your application and this is the suggested element to mark as the element to snapshot and restore to, using the ic-history-elt attribute

It is highly recommended that you set this attribute in your intercooler application if you are using history.

Including Request Paramters In The URL

Somtimes you may want to include one or more request parameters in the URL that is set in the navigation bar. You can do this by using the ic-push-params attribute, which lets you specify which parameters should be included in the URL. A common place where this might be useful is in search dialogs, where you want the search term to appear in the URL so it can be copied and pasted or refreshed and retain the search information.

Conditionally Updating The Location/History

Sometimes whether or not you want to update the location of the page will be dependent on the result of the intercooler request. In that case, rather than using the ic-push-url attribute, you can use the X-IC-PushURL header, outlined below in the Intercooler Response section.

Note: This is one area where intercooler leverages some relatively recent web technologies that may not be present on older browsers. Namely, it uses Web Storage and the JSON object, both of which are not available in various older browsers. If you wish to maintain maximum compatibility with your intercooler website, you should not use the history support.

Progressive Enhancement

Intercooler provides a mechanism for progressive enhancement. The ic-enhance attribute can be set to true on an element, all child anchor tags and form tags will be converted to their equivalent intercooler implementations.

Anchor tags (links) will be converted to ic-get-from with ic-push-url set to true.

Forms will be converted to the intercooler equivalent action (e.g. a POST form will convert to ic-post-to)

Commonly you will have an ic-target set up at the top level of your DOM, paired with a ic-enhance attribute. You can differentiate on the server side between normal and AJAX requests by looking for the intercooler headers.

Here is an example:

    <div ic-enhance="true">
      <a href="/enhancement_example">Click Me!</a>
    </div>
  

Server Sent Events _BETA

Server Sent Events are an HTML5 technology allowing for a server to push content to an HTML client. They are simpler than WebSockets but are unidirectional, allowing a server to send push content to a browser only.

Browser support for Server Sent Events is widespread, and there are polyfills available for browsers that do not support them natively.

Intercooler supports Server Sent Events with the ic-sse-src attribute. This tells intercooler to establish a Server Sent Event connection with the given URL and listen for both messages and events.

    <div ic-sse-src="/sse_endpoint">A Server-Sent Event Element</div>
  

Server Sent Event Sources

The simplest way to use Server Sent Events is via messages. Server Sent Messages will simply have the content of the message swapped in as the body of the target that the attribute is on. This can be used as an alternative to the more common client-side polling behavior.

If you wish to append or prepend, rather than replace the content, you can use the ic-swap-style attribute to specify so.

Server Sent Event Triggers

Another technique with Server Side Events is to use events (rather than messages) to trigger a request, rather than replace content directly. This can be done by specifying a Server Side Event source with the ic-sse-src tag on a parent element, and then specifying the Server Side Event that triggers a given child using the special sse: prefix.

  <div ic-sse-src="/sse_endpoint">
    <span ic-trigger-on="sse:contact_updated" ic-src="/contact/1"></span>
  </div>
         

For the HTML above, the span HTML will be updated from the /contact/1 URL when a Server Side Event of the name contact_updated is fired.

Note: Server Sent Events are relatively new and are a beta feature of both intercooler and the web in general. They should be used with caution.

Anatomy Of An Intercooler Request

Intercooler requests are fairly straight forward HTTP requests, but they do have a few non-standard aspects that help you out.

Special Parameters

In addition to the form serialization discussed above, intercooler requests include a few additional parameters in every AJAX request:

Parameters

Headers

Anatomy Of An Intercooler Response

Intercooler responses are HTML fragments. Here is an example of some content:

  <div>
    Here Is Some Content!
  <div>
      

This would be swapped in as the body of the element that initiated the request.

The returned content can, of course, contain Intercooler attributes itself, which will be all wired up.

No-Op Responses

Intercooler interprets an empty body or a single whitespace character in a request as a No-Op, and will do nothing in response. If you want to replace an element with only whitespace, return at least two whitespaces worth of content.

Intercooler Response Headers

Not all UI needs can be captured via pure element swapping. Occasionally you may need to invoke a client side event, let other elements know to refresh themselves, redirect the user entirely, and so on.

To handle these situations, intercooler supports custom HTTP headers. These headers can be used to instruct intercooler to perform additional work in addition to swapping in the returned HTML.

Here is a table of the response headers intercooler supports:

Dependencies In Intercooler

Intercooler has a novel mechanism for managing inter-element dependencies which builds on the concept of REST-ful URLs.

Intercooler uses server path relationships to encode dependencies. The idea is straight forward and natural if you have are familiar with REST-ful URL schemas:

If an element reads its value (i.e. issues a GET) from a given server path, and an action updates that path (i.e. issues a POST to it), refresh the element after the action occurs.

So, as a simple example, consider this button and div:

  <button ic-post-to="/example/path">A Button</button>

  <div ic-src="/example/path">A Div</div>
     

Here the div depends on the button, because they share a path with one another. When Intercooler issues a POST to the given path (on a user click), upon completion, it will issue a GET to the same path, and replace the div with the new content, if it is different.

What Paths Depend On What?

It's all very simple when the POST and GET are to the same path, but what if they aren't? What if the post is to /jobs/2341/start and the get is from /jobs/2341? Or vice-versa?

Our answer is as follows:

Two server paths express a dependency if either path is the starting path of the other.

So:

Explicit Dependencies

The dependencies above are managed implicitly by Intercooler and, with reasonable layout of your restful URLs, should handle many cases. However, there may be times when you need to express dependencies explicitly. In Intercooler, you can use the ic-deps attribute to express additional paths that an element depends on.

To disable dependencies on an element, you can use ic-deps="ignore"

Intercooler Events

Intercooler fires JQuery-style events that can be listened for. Here is a table of the events that are fired:

Example

Here is some code that uses the BlockUI library to block the UI when an intercooler request is in flight:

        $(function(){
          $('#blocking-button').on('beforeSend.ic', function(){
            $.blockUI();
          }).on('complete.ic', function(){
            $.unblockUI();
          });
        })
      

Event Attributes

Javascript can also be invoked with the following attributes: ic-on-beforeSend, ic-on-success, ic-on-error, and ic-on-complete.

Here is the same demo as above using attributes rather than a JQuery event handler:

These attributes can be placed on parent elements if you want to specify a behavior for an entire secion of a DOM tree.

Server-Side Techniques

A great strength of Intercooler is that it is inherently server-side technology agnostic: you can use anything you'd like to serve up the partial HTML and headers needed for your Intercooler-based front-end to function. That being said, there are some techniques that can be applied across all server-side technologies to help you build a better, cleaner web application:

Check for the ic-request parameter

You can use the ic-request parameter to decide if a request has originated from intercooler (and, therefore, demands a partial bit of HTML) or from a top level browser. If you are using the ic-push-url attribute to enable AJAX-based history and navigation this can be especially useful.

Check the ic-target-id parameter

If you have an even more advanced user interface, you may find yourself making requests to the same URL for different parts of the screen (this is common if you have a second-level navigation within a page) and you will want to differentiate between requests that are targeting different parts of the UI. Intercooler provides the ID of the target element, if it exists, in the ic-target-id parameter

Use the ic-trigger-id to determine who triggered a request

If it is annoying to set up multiple routes with your server-side technology, you may have a few actions that you want to run through a POST to a single URL. You can differentiate between the elements that are sending these posts up by giving them IDS and then checking the ic-trigger-id parameter.

Keep your templates DRY

Intercooler works best with a tidy server-side, with refactored and well composed templates that generate both the full and partial HTML necessary for a web app.

Leverage multiple HTTP Actions at the same URL

Intercooler makes it easy to issue more exotic HTTP actions, like DELETE and PUT. Depending on your server-side technology, you can use this to minimize the URL surface area of your app and adhere to REST-ful URL design. There is no reason to limit this concept to only JSON APIs: it often leads to a minimal and tidy code base when used judiciously for partial HTML.

Fire client-side events to manage UI state that can't be handled with content swaps

Not every UI pattern is amenable to HTML content swapping. For example, you may want to use a modal popup from a framework like Bootstrap. In situations like these, you can often use the IC-Trigger attribute to signal from the server-side to the client-side that something happened, and write javascript to update the UI accordingly (e.g. hide a modal after an update.)

This is a powerful technique for minimizing the coupling and complexity of your application while still retaining the full power of a javascript client side environment.

Error Handling & Debugging

Intercooler offers a few tools for handling errors. The most important one is the ic-post-errors-to attribute, which will post all AJAX and client side errors that occur during content swaps to a given URL. This is an invaluable way to understand what is going on on the client side of your web application.

There is also the ic-on-error attribute, which allows you to specify an expression to evaluate when an AJAX error occurs.

Finally, there are the error events specified above that allow you to handle more specific error situations if you wish.

Integrated Client-Side Debugger

Intercooler comes with an integrated client-side debugger. You can launch the debugger by including the following script on your page:

<script>
  $.getScript("https://intercoolerreleases-leaddynocom.netdna-ssl.com/intercooler-debugger.js");
</script>

The debugger consists of three tabs: "Elements", "Logs" and "Errors".

"Elements" has a clickable list of active elements on the page. When you click on one of the items in the list, it will be highlighted on the page, and intercooler-related details will be shown about it.

"Logs" has the intercooler log stream, including clickable links to the elements that caused each message.

"Errors" will show any errors that intercooler detects (e.g. bad targets on an element).

You can launch the debugger on this page by clicking this button:

Launch The Debugger

If you would like, you can capture the intercooler log event if you want to see the low level events that are driving intercooler:

        $(function(){
          $(window).on('log.ic', function(evt, msg, level, elt){
            console.log(msg);
          });
        })
  

Using Intercooler from Javascript

Intercooler does not have a large javascript API because it is intended to sit in the background, issuing and processing requests. Events and dependencies can be used to handle almost all dynamic situations that intercooler is appropriate for.

There are, however, a few methods you can invoke on the global Intercooler object:

Javascript Expression Evaluation

Intercooler evaluates expressions for attributes (ic-on-beforeSend, ic-on-success, ic-on-error, and ic-on-complete) and passed in via headers, etc. in a somewhat complex way:

If the expression is a single symbol, it will be looked up in the global namespace as a function and then, if it exists, it will be called with the given arguments.

If not, the expression will be evaluated in a new scope.

This allows sites with security restrictions around the use of eval() to still make use of scripting within intercooler.

Also note that, because expressions are evaluated in a new scope, if you are using an attribute that supports a return value (e.g. ic-on-beforeSend returning false to cancel a request) you must return the value using an explicit return statement.

Cross-Domain AJAX

Below are some basic guidelines for getting cross-domain AJAX requests working with Intercooler. For an authoritative resource on cross-domain HTTP requests refer to the MDN CORS documentation.

Response Headers

For responses to cross-domain requests you will need to set the Access-Control-Allow-Origin header to the domain which will be making requests. For example:

          res.header('Access-Control-Allow-Origin', 'http://example.com');
        

And if you want to use any of the Intercooler response headers you will need to set the Access-Control-Expose-Headers to include the headers you want to use. For example:

          res.header('Access-Control-Expose-Headers', 'X-IC-Trigger, X-IC-Script');
        

Cross-Domain Credentials (Cookies and HTTP Auth)

If you want to send cookies with cross-domain AJAX requests you'll need to set the Access-Control-Allow-Credentials header to true on the server. For example:

          res.header("Access-Control-Allow-Credentials", "true");
        

And also set withCredentials to true on the xhrFields property of the AJAX settings in the browser. For example:

          $(document).on("beforeAjaxSend.ic", function (evt, settings) {
              settings.xhrFields = {withCredentials: true};
          });
        

For more information on cross-domain AJAX requests and credentials refer to the MDN XHR documentation.

Preflighted OPTIONS Requests

Based on the MDN documentation on preflighted requests, a request is preflighted if:

• It uses methods other than GET, HEAD or POST. Also, if POST is used to send request data with a Content-Type other than application/x-www-form-urlencoded, multipart/form-data, or text/plain, e.g. if the POST request sends an XML payload to the server using application/xml or text/xml, then the request is preflighted.
• It sets custom headers in the request (e.g. the request uses a header such as X-PINGOTHER)

To avoid preflighted OPTIONS requests for Intercooler requests you can do the following:

          $(document).on("beforeAjaxSend.ic", function (evt, settings) {
              delete settings.headers['X-IC-Request'];
              delete settings.headers['X-HTTP-Method-Override'];
          });
        

Of course, this means that you won't have access to these headers on the server.

jQuery and Cross-Domain AJAX

Based on the jQuery AJAX settings documentation, the following additional points should be noted about cross-domain AJAX:

• Synchronous operations are not supported.
• The error handler is not called.

zepto.js Compatibility

zepto.js is a minimalist, largely jQuery-compatible API for use with modern browsers, that is focused on staying small (<10kB when gzipped, compared with 32kB for the latest versions of jQuery) while providing most of the familiar jQuery APIs.

As of version 1.1.0, intercooler offers zepto.js compatibility in place of jQuery. To use zepto, rather than jQuery:

• Include the latest zepto.js release.
• Include the data module from the zepto modules section

Using zepto with intercooler.js brings the entire support payload for an intercooler-based web application down to 18kB, which compares favorably with many JS frameworks (Vue.js, the smallest by a long shot, comes in at 23kB)

Differences with jQuery + intercooler.js

There are a few differences in behavior when using zepto.js with intercooler:

• Local HTML fragments (e.g. ic-get-from="#some_div" will not work)
• Event namespacing is reversed and uses a colon separator, so the beforeSend.ic event becomes the ic:beforeSend event.
• zepto does not serialize non-form elements, so ic-include must point to a form if you wish to include a value from an input. The JSON form is not affected.

Philosophy

It can be easy for some developers to dismiss intercooler as overly simple and an archaic way of building web applications. This is intellectually lazy.

Intercooler is a tool for returning to the original network architecture of the web. Using HTML as the data transport in communication with a server is what enables HATEOAS, the core distinguishing feature of that network architecture. Intercooler goes with the grain of the web, rather than forcing a more traditional thick-client model onto it, thereby avoiding the complexity and security issues that come along with that model.

Yes, intercooler is simple, but it is a deceptive simplicity, very much like the early web.

A few related blog posts for the interested reader:

• Rescuing REST
• HATEOAS is for Humans
• API Churn v. Security

On Churn

Many javascript projects are updated at a dizzying pace. Intercooler is not.

This is not because it is dead, but rather because it is (mostly) right: the basic idea is right, and the implementation at least right enough.

This means there will not be constant activity and churn on the project, but rather a stewardship relationship: the main goal now is to not screw it up. The documentation will be improved, tests will be added, small new delarative features will be added around the edges, but there will be no massive rewrite or constant updating. This is in contrast with the software industry in general and the front end world in particular, which has comical levels of churn.

Intercooler is a sturdy, reliable tool for web development.

Conclusion

And that's it!

Not a ton to it, which is kind of the point: you can build surprisingly rich UIs with this simple and easy to understand tool, and you can do it incrementally in the areas that matter the most for your users.

"There is no need to be complex..."