Add support for render-level partials

[ericf]

The renderView() method now accepts render-level partials that are merged with the instance-level and global Handlebars partials. The option value is specified as object with the shape: {partialName: fn} or a Promise of such an object.

Fixes #82

[ericf]

I removed the merge of this.handlebars.helpers since Handlebars will do this merge automatically at render time.

[caridy]

+1

[ericf]

Released in v1.2.0.

[nealshail]

Thanks for this feature, though I'm unsure of the exact syntax to use..

'specified as object with the shape: {partialName: fn}

I've used {'mypartial':'path/to/my/partial/mypartial.hbs'} but this is only adding 'path/to/my/partial/template.hbs' as text in the place of the partial. How should we resolve this to an object or a promise of an object? Do you have an example?

[caridy]

It is an promise that resolves to a map, you can use getTemplate() method off the instance to fetch those partials. We can probably improve that by providing a easy way to define each partial as a promise in the map, we just need to convince @ericf jejejeje.

[ericf]

@nealshail It's a hash of "partialName"s to compiled Handlebars template functions. Or it can be a promise whose value resolves to an object in that shape:

{
  foo: function () { /* compiled Handlebars template */ },
  bar: function () { /* compiled Handlebars template */ }
}

[ericf]

We can probably improve that by providing a easy way to define each partial as a promise in the map

@caridy Not sure I follow…what are you thinking?

[caridy]

@ericf we have a similar situation with MBR. It is just messy to have to create a bunch of promises (one per partial) then aggregate them into a map after calling Promise.all(). Maybe we can abstract that part of the operation into exp-hbs directly, so they only need to create a map, something like:

{
    foo: obj.getTemplate('/path/to/foo.hbs'),
    bar: obj.getTemplate('/path/to/bar.hbs')
}

[ericf]

@caridy would that be covered by what I wrote here #118 (comment)?

[caridy]

@ericf that's a no go since dirs means nothing when you have contextualization.

[ericf]

Well the API currently provides what's needed to implement what you want, it sounds like the app needs an abstraction over this to create an more DLS-y API. I don't care if people have to write a loop/forEach to accomplish the complex use they have…