Intercooler Dependencies

One of the novel features of Intercooler is its dependency framework. This is how Intercooler figures out what elements to refresh and when, based on user input, poll intervals, etc.

The core concept in Intercooler is to use server paths to encode dependencies. The idea is fairly straight forward, given a REST-ful understanding of web addressses:

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), then we should 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:

Path Updated Path Read Dependency?
/foo /bar NO
/foo /foo YES
/foo/bar /foo YES
/foo /foo/bar YES
/foo/doh /foo/bar NO

Explicit Dependencies

The dependencies above are managed implicitly by Intercooler and, with reasonable layout of your restful URLs, should handle many cases. However, there are inevitably going to 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.