Handlebars-style partials aren't handled

[rmccue]

Currently, it seems like Handlebars-style partials in the form {{> partial-name}} aren't handled correctly. These are parsed by the Handlebars AST parsing into a PartialStatement, which then ends up getting passed into HydrationOpcodeCompiler.mustache. This tries to access mustache.path, which isn't set.

I've managed to hack support in by changing HydrationOpcodeCompiler.mustache to check for mustache.type == "PartialStatement" and treat it as a "partial" helper call (i.e. {{partial "partial-name"}}), but this is super hacky and I don't think it's the right place to do it either. I'm guessing it should be happening in the pre-processing stage, but I'm not sure, as I'm new to HTMLBars (and attempting to use it outside the Ember ecosystem).

Happy to work on this and add support, but need a few pointers on best practices here :)

[rmccue]

(FWIW, here's the total hack I'm using.)

[mixonic]

@rmccue I don't believe we're interested in supporting the {{> syntax. There are a few parts of the Handlebars syntax we don't implement, really Ember's templating is a compatible subset of Handlebars syntax. Perhaps @mmun can tell me I'm wrong or close this as wontfix.

[rmccue]

Would it be possible to at least have API support for implementing this? I'd really love to use HTMLBars outside of the Ember ecosystem, but totally understand if you don't want native support for this.

[rmccue]

Managed to get it working by applying that hack via subclassing of HydrationOpcodeCompiler, so if you do want to close this out, that's fine (although IMO it'd be nice for HTMLBars to support a larger subset of Handlebars :) ).

[rwjblue]

Not sure if we want to do it or not, but using the flagging infrastructure it should be possible to add this as a feature (similar to disableComponentGeneration) which is passed into options in compile and all the way through to the TemplateCompiler.

[timkendrick]

@rmccue sorry for the late reply, but could you share your hack that got this working? I'm also using HTMLBars outside Ember and it'd be great to maintain compatibility with Handlebars partial syntax…

[rmccue]

@timkendrick Some of the worst code I've ever written: https://gist.github.com/1f63f4b21c7e7ed9c7d7

Essentially, it takes the PartialStatement type (which is emitted by Handlebars' AST generation) and converts it to a helper just before htmlbars would otherwise crash on the unknown statement.

@rwjblue Good point; I'd be happy to work on patching that in behind a flag if it's likely to be accepted. :) In the meantime, I'm using Handlebars to compile to a HTML string, then converting that to virtual-dom nodes, which is basically just a terrible way to do it.

[timkendrick]

Thanks @rmccue, that's super-helpful! Saved me hours of searching.

Your fix works like a charm for inline partials, but weirdly the AST parse step fails for block partials. This is strange seeing as it's using the stock Handlebars parser to generate the AST – I'll let you know if I manage figure out why this is happening…

Thanks again!

EDIT: just figured out that block partials were only introduced for Handlebars v4, whereas Htmlbars is based on Handlebars v3.0.2. I guess that means no Htmlbars block partials…

[mAAdhaTTah]

@rmccue Did you ever come up with a solution better than HBS -> string -> vdom? I think I'm trying to do something similar (incremental updates with Handlebars as declarative DOM), but besides wiring it up with virtual-dom (or writing my own bespoke solution), I haven't yet found a way to do so in a standalone manner.

[swquinn]

Even if the {{> syntax isn't supported, Is there any intent to enhance the HTMLBars partials support? There are a number of features that Handlebars has, such as passing context or assigned variables into a partial, that could be really useful.