Skip to content
This repository

YAML front matter in partials #98

Closed
jonschlinkert opened this Issue March 20, 2013 · 10 comments

3 participants

Jon Schlinkert Brian Woodward
Jon Schlinkert
Owner

Would be convenient if YAML front matter wasn't limited to pages, like Jekyll and others. I guess what makes this difficult is when the context is established.

Brian Woodward
Owner
doowb commented March 20, 2013

YAML front matter should work in partials...

code that makes it work

You access it in handlebars based on the partial name...

---
defaults:
  base: alert
  modifier: "alert-warn"
  text: Something strange is happening!!!
---

<div class="{{alert.defaults.base}} {{alert.defaults.modifier}}">{{{alert.defaults.text}}}</div>
Jon Schlinkert
Owner

Ohhh, I didn't check the codeeee! silly me. Lol the example you did is very close to the test file I just created. Why do I always default to "alerts" for partials?

Thanks!

Jon Schlinkert jonschlinkert closed this March 20, 2013
Jon Schlinkert
Owner

btw, tested and confirmed! Will document now before it gets lost in the abyss again ;-)

Brian Woodward
Owner
doowb commented March 20, 2013

:+1:

ahoy fellas,

this is a handy feature but i just wanted to check one thing. given the following partial link.html with YFM front matter data:

---
local: "ahoy!"
---
<a class="{{class}}" id="{{id}}" title="{{title}}" src="{{URL}}">{{link.local}}</a>

if this partial is called with a context argument or within a context block as in this template:

---
target:
  class: root
  id: nav1
  title: home
  URL: /index.html
---
{{> link target}}

{{#target}}
  {{>link}}
{{/target}}

then the partial's local data is ignored. the partial's data is only available if the partial is called with no arguments or outside of a section block:

{{>link}}

perhaps this is intended behavior? however, considering the example above i assumed that the partial's local YFM data would always be available (e.g. as a "default" in your example above) and merged with the calling context, perhaps overridden if the calling context contained similar keys. i believe that merging the partial's data into the context would be more useful than simply ignoring it and would work for your defaults use case described above. then again, i am very new to Assemble and perhaps not understanding correctly.

i would be happy to help document this functionality once it is settled.

thanks in advance and for Assemble.

peace

Brian Woodward
Owner

This is something that happens due to handlebars context. We do have a partials helper that lets you use the context from the partial yfm. I'll try to find the link to it soon. Or search for handlebars helper partial.

Jon Schlinkert

i would be happy to help document this functionality once it is settled.

thanks! that would be great. most of this stuff is technically documented somewhere but needs to be organized and explained better

i believe that merging the partial's data into the context would be more useful than simply ignoring it and would work for your defaults use case described above

This issue is pretty old, so it's really outdated. Here is the helper @doowb mentioned (this is just one example of many where we're attempting to provide granular access to context to account for different scenarios):

waynedpj referenced this issue in helpers/handlebars-helper-partial January 11, 2014
Closed

mixing native partial and partial helper for same partial #1

thanks @doowb and @jonschlinkert for the replies. i apologize for jumping onto this old thread, i just thought it would keep the related discussions together.

the handlebars-helper-partial works a treat (save a small issue i may have found) and seems to fit the "default context" use case that @doowb describes above. that helper makes Handlebars function like other template langs (like Mustache, dust) that seem to merge the context all together. unfortunately it seems that currently partials in Handlebars will only use the context passed in as a argument or of its enclosing section and not inherit the parent's context:
wycats/handlebars.js#182
wycats/handlebars.js#368

thus, this helper is very "helpful" indeed .. sorry, i love bad puns ;)

as for Assemble documentation updates, i assume that should we then make clear somewhere that
1. partials in Handlebars will only use the context that they are called with (either via a partial context parameter or via the section in which they are called) and not inherit anything from the calling template
2. the handlebars-helper-partial exists to provide different/expected? behavior

also, where should this go? i am guessing it should go here?

thanks again.

Jon Schlinkert

@waynedpj, sorry I don't know how I missed this last reply of yours, but I didn't see it. I'm working on getting the documentation workflow and templates updated, but in the meantime that page you linked to would be good for this - if you do still feel like taking a crack at it. Thanks!

@jonschlinkert no worries. i made an initial update to the partials documentation here but will hold off on a PR until this and this are fixed, since my updated docs will not build currently.

in the meantime, if you have any comments/updates/etc. please let me know.

waynedpj referenced this issue in assemble/assemble.io January 22, 2014
Merged

Partials docs update #71

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.