Handlebar template tags

[sprynm]

I wrote two new tags to support quicker handlebar templates vs custom tags. The custom tags seem to put too much content in the Gulp file and also had the authors change contexts. Probably fine for complex layout but too much friction for simple iterative examples.

I'm not entirely sure about the {type} in the Comment Parser so I just splits strings to create arrays. First by pipes (|) then double colons (::) for nested arrays. Perhaps there is a native type that could just take JSON?

I also up'd the web components to the new version and the recommended CDN. However, I have to admit, I'm not sure how it fits in with this project so far - I'll create a issue to discuss. I'm fine removing that change too.

[coveralls]

Coverage decreased (-0.02%) to 94.92% when pulling 99657a0502447287b2c1c8ff900d971f5702ab16 on sprynm:hbs-template-tag into b5e062d636e1098240d8f08e22cdae2b53dcc0f1 on straker:master.

[coveralls]

Coverage increased (+0.2%) to 95.187% when pulling b6bb17f164d1a79c74a0888763d912969c679076 on sprynm:hbs-template-tag into b5e062d636e1098240d8f08e22cdae2b53dcc0f1 on straker:master.

[straker]

Thanks for the pr.

Could you please elaborate how using inline handlebars templates that output html for the @example tag simplifies custom tags? I'm not seeing how the two are related since the @example tag doesn't use custom tag data. Custom tags are only used when using a custom handlebars template to render the style guide.

As I interpret this pr, the handlebars template only saves you from having to write duplicate HTML in an example. So instead of this:

/**
 * @example
 * <h1>Heading Level 1</h1>
 * <h2>Heading Level 2</h2>
 * <h3>Heading Level 3</h3>
 * <h4>Heading Level 4</h4>
 * <h5>Heading Level 5</h5>
 * <h6>Heading Level 6</h6>
 */

you would write this:

/**
 * @hbs_data 1|2|3|4|5|6
 * @hbs_example
 * {{#each hbs_data}}
 * <h{{this}}>Heading H{{this}} </h{{this}}>
 * {{/each}}
 */

[sprynm]

The goal was to have as much work as possible happen right at the source code. Custom tags like the handbarsExample requires a context shift and seems overly complicated for simpler templates. These tags mean less need to open the gulpfile to define content (which could get cluttered for large projects). I also like that if I delete a source file/section, the template auto-prunes.

You are interpreting correctly and the nested array allows for more complicated presentation. Each item can have X number of data as outlined in the last example of the readme. I've personally used the tags to iterate over color pallet uses (color, bg, alerts etc).

I originally wrote the pair as custom tags but thought a generic template function might be appreciated.

[sprynm]

Not feeling this one?

[straker]

Sorry ya, been taking some time to think about it and I'm just not sure it's the direction I want to take with this project. If more people feel that this would be a useful default then I'll reconsider it. Thanks again for taking the time to improve the project.

[sprynm]

Fair enough, I can convert back to a custom tag.

Two questions/thoughts:

I'd be happy to share this as a custom tag should anyone else want quick templates, perhaps you could create a repository for user contributions like templates, partials and tags?

I wasn't that happy with the heavy handed way I handled the arrays here. Do you know how to pass an object or JSON via the comment parser? Or perhaps a different method for structured data.

[straker]

I like the idea of a user contributed template/partials/tags. Have you seen one that works well? Would the wiki page be easy enough so anyone could come and add one?

I'm not entirely sure how the comment parser splits the parts, but I would think if you could get it to the description part a normal array/json structure would work since it should just take whatever's left in the comment as the string

[sprynm]

Transferring wiki conversation: https://github.com/straker/livingcss/issues/55

As for the JSON, I was over thinking. This is all I needed:

JSON: function() {
    var json = JSON.parse(unescape(this.tag.description));
    this.block.json = json || {};
},