No way to directly process a block's inner text?

[benpusherhq]

(Related to: #353.)

It doesn't seem possible (or I can't figure out how) to implement this:

{{#markdown}}
My _markdown_ text parser would handle this inner text
{{/markdown}}

This is possible in vanilla Mustache via context functions (which get the inner text and a render callback). Context functions in Handlebars appear not to have this same signature and thus cannot be used for this purpose.

As there are workarounds to handle this, it is not a critical issue. I can also understand how this might not be handled "by design". That said, it would be nice to be able to process the inner text of a block via a registerHelper or a context function.

[doowb]

@benpusherhq we process content within block helpers in our helper-lib project by doing something like the following...

    Handlebars.registerHelper("markdown", function(options) {
      var content = options.fn(this);
      return Markdown.convert(content);
    });

Markdown references another internal utility that uses marked to render the markdown content into html.

Is this what you're trying to do?

[benpusherhq]

That's almost what I was trying to do.

The above suggestion processes the content as a Handlebars template first, then processes the result as markdown. I was aiming to process the inner block as markdown without first processing it as a template. There still doesn't seem to be a way (as far as I can tell) in Handlebars to access the inner block content without processing it. Since you can do this in vanilla Mustache, this seems like a potentially nice to have feature in Handlebars.

Your suggestion is helpful though (and likely the preferred approach in many cases). Thanks!

[jezell]

We have a similar use case where not having this functionality makes us sad. Would be nice if there was a way to define a raw block helper or something of the sort.

[kpdecker]

@benpusherhq , @jezell So the goal here is to have a text representation of the block contents? What is the reason that you can't exec options.fn? Do you have {{}} literals that should not be evaluated?

[benpusherhq]

@kpdecker, correct me if I'm wrong but let's say you have this example:

{{#markdown}}
In handlebars.js text like **{{name}}** will be substituted with the value of the variable name.
{{/markdown}}

What I'm referring to is getting the inner block contents without processing: i.e. "{{name}}" won't be substituted. Using options.fn will return the text after the substitution has been done (right?). I'm talking about the cause were the raw string is returned.

[kpdecker]

That is correct. You would need to escape the mustache sequence if you want the literal.

{{#markdown}}
  **\{{name}}** {{name}}
{{/markdown}}

Would render to something like

{{name}} kpdecker

It's not as friendly as some sort of literal block notation but does allow you to mix and match.

https://github.com/wycats/handlebars.js/blob/master/spec/basic.js#L6-L10

[Arkkimaagi]

I have a similar case where I want to generate a styleguide possibly with a helper like this:

{{#styleguideBlock "Heading level 3"}}
{{h3 "Example heading"}}
{{/styleguideBlock}}

Where the {{h3}} is a simple helper for generating headings with anchor links, for the sake of this example, lets assume it generates only h3-tags.

And I would want it to render something like this as a resulting html:

"Heading level 3" renders like this:<br>
<h3>Example heading</h3>
Sourcecode:<br>
<code>{{h3 "Example heading"}}</code>

As you can see, even this simplified example adds plenty of stuff and then runs the raw code twice, once with normal fn(), and once with safestring.

As I have not found a way to access the raw block code, I'm forced to write my styleguide codes without helpers, twice. 👎 So, I came here to either provide a real life usecase or for someone to suggest something obvious to solve my problem. Thanks :)

[jezell]

Put something together that allows you to register raw block helpers.

[bartek]

👍 to this as it makes it much saner to handle gettext implementations with Handlebars

[kpdecker]

Closing this issue in favor of #573.