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
POSTto 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
It's all very simple when the
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
Our answer is as follows:
Two server paths express a dependency if either path is the starting path of the other.
|Path Updated||Path Read||Dependency?|
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.