Thenable support

[sethkinast]

Dust handles thenables (promises) in context, either directly or as the return value of a context helper. Dust will reserve a chunk asynchronously for the eventual return value of the promise.

If the promise is invoked as a reference, the reference will become the eventual return value. If the promise is invoked as a section, the eventual return value will be pushed onto the stack.

This allows Dust to integrate with third-party modules that don't know what Dust is, while still allowing those modules to make use of Dust's asynchronous nature seamlessly.

Closes #568

[sethkinast]

var q = require('q'),
    dust = require('../lib/server');

var tmpl = dust.compile('Eventually, {magic}!', 'magic');
dust.loadSource(tmpl);

dust.render('magic', { "magic": q("magic") }, function(err, out) {
  console.log(out);
});

Before:

$ node tmp/test.js
Eventually, [object Promise]!

After:

$ node tmp/test.js
Eventually, magic!

[sethkinast]

Open questions:

[x] Currently a rejected promise calls chunk.setError just like any other error. However, rejected promises aren't "hard" errors. Would it make sense to render an {:error} block instead, if it exists, pushing the error onto the context?
[x] chunk.thenable isn't the coolest name ever

[smfoote]

I like the {:error} idea. Let's make sure this gets into the documentation before/as this feature gets released.

[sethkinast]

#573 includes docs for this

[jimmyhchan]

what would happen if someone tries to reference magic.foo. I remember we had some logic that would fire the magic function and look for foo in it's return value.

[sethkinast]

A Thenable is not a function so it would look for a property on the Object called foo