ractivejs/ractive — pull request #885 by martypdx (2014-06-28 00:25:31+00:00)
Title: Support function option in partial

When I changed configuration of registries back to prototypical inheritance, I removed the registry option functions. This is because they became no longer "live", in the way you can change partials and have them be picked up on subsequent render, and because it lengthened the configuration time.

Thinking some more about this, it seemed that the need was not to specify a whole set of partials dynamically, but specify an individual partial (it's already been used in the template, the question is not what partials to use, but what is the implementation to use for the partial). End result is this PR allows you to do this:
```js
var ractive = new Ractive({
el: fixture,
template: '{{>foo}}',
data: { foo: true },
partials: {
foo: function ( data ) {
return data.foo ? '

yes

' : '

no

'
}
}
})
```

Which I think is the heart of dynamic partials. One issue with partials because of their "live" nature is that the partial is not resolved until it is needed. As an edge case though, it means that functions may be delayed in being resolved:

```
var ractive = new Ractive({
el: fixture,
template: '{{#if !foo}}{{>foo}}{{/if}}',
data: { foo: true },
partials: {
foo: function ( data ) {
return data.foo ? '

yes

' : '

no

'
}
}
});

t.htmlEqual( fixture.innerHTML, '' );
ractive.set( 'foo', false );
t.htmlEqual( fixture.innerHTML, '

no

' );
```

Once resolved, it doesn't not change within an instance, unless `ractive.reset(data)` gets called.

I think this model works well for component registries as well, but wanted to get some feedback on this PR first.

(btw - thanks to my friend @willemlarsen who is learning javascript for pairing with me on this feature. :))