Access to root context in partials and helpers

[kpdecker]

There is already a related bug about getting parent context inside a partial called from within a block helper: issue #182. However, tracking parent context is probably not enough - add in another block helper (e.g. an if inside an each) and things quickly get out of hand.

The same story with helpers - it's easy enough to get current context via this, it's easy enough to pass in parent context via ".." - but once again, very quickly it becomes "../../../.." There is a hack proposed in issue #245 but I had mixed fortune with it.

The above two problems seriously affect code re-use - one must always keep track of context and nesting. There are pull requests for parentContext by introducing helpers and passing explicit parent context. While I find that useful, I also need the global context - just a couple of sample use cases: localization (must know which language to use), changing some item layout/details based on user status (essentially access check, although some might argue this is "logic" and should thus not be done inside a template).

It would be great to have access to global/root context at all times - inside an {{#each}}, inside an {{#if}}, inside any helper that I create myself and naturally inside any partials that may be nested inside block helpers.

[dominykas]

This is just one example of how badly "../" can get out of hands: http://jsfiddle.net/gsVLy/1/

I realize this is probably correct behavior - there's no "rootItem" inside the each, so "../rootItem" does not exist inside the if inside the each, but if one tried to add a nested loop, and an if in there... you get the point.

[brikkelt]

Another reason to support root access might be Handlebars' claim that 'Mustache templates are compatible with Handlebars, so you can take a Mustache template, import it into Handlebars'. The Mustache enginges for both php and js seem to support access to root context (see http://jsfiddle.net/brikkelt/A3gqF/ for js version), so one might expect Handlebars to do so as well.

However, the strongest reasons for support are the use cases you describe above + the pain of keeping track of parent depth.

+1!

[AshHeskes]

Mustache.js has a nice way of dealing with this. It essentially looks for the named property in the current context, if it can't find it, it will traverse back up the context tree all the way to the root checking each parent context for the named property, and uses the first one it finds.

e.g.

Template:

<ul>
{{ #items }}
    <li>Item {{.}} for {{user}}</li>
{{ /items }}
</ul>

Context:

{
    items: [1,2,3,4,5],
    user: 'Ash'
}

Output:

<ul>
    <li>Item 1 for Ash</li>
    <li>Item 2 for Ash</li>
    <li>Item 3 for Ash</li>
    <li>Item 4 for Ash</li>
    <li>Item 5 for Ash</li>
</ul>   

I think this would be a great addition to Handlebars and would bring it more inline with Mustache.js

Of course in the case where you are looking a property on the root which shares a name with a property somewhere in your context tree it will only return the closest property to you.

It might be useful to have a special keyword tag e.g {{ root }}. That always references the root Object. That way you can call out the {{ root.someProperty.SomeChild }} anywhere in your template. similarly using it in a section will switch the context of that section back to the root context.

e.g.

{{# outerProp }}
    {{# innerProp }}
        {{#root }}
            {{# outerProp.innerProp }}
                {{.}}
            {{/ outerProp.innerProp }}
        {{#root}}
    {{/ innerProp }}
{{/outerProp}}

Although I feel like this would be a rarer case than the first solution, which comes in handy quite a lot. Where as I have yet to find a situation where I have nested properties with the same names.

[williamcoates]

I opened a pull request which makes it simple to access the root context in custom helpers:

#525

[jonschlinkert]

Yeah we just had an issue on Assemble related to this, assemble/assemble#164.

[Snugug]

👍 for this as well. It's recently bit me not being able to access root.

[sidonaldson]

👍 I would like to request this too. I have an each statement which iterates over a 2D array and using "../" doesn't work. I have a nested if statement so have tried "../../" and that too doesn't work. If there isn't performance overhead to adding a root keyword then it's a quick win.

[jonschlinkert]

Would love to see some kind of acknowledgement of this issue. It has been an ongoing problem for us with assemble.

[kpdecker]

This is a non-trivial implementation that none of the core team has had a time to look at. It has not been closed as it is something that we would like to do. Pull requests are welcome.

[kpdecker]

Note that there are many issues to consider with this such as arbitrary nesting vs. blanket root access vs. work-around such as using @ data var (as well as the similar issue of how/if data vars should support traversal.

[jonschlinkert]

Note that there are many issues to consider with this such as arbitrary nesting vs. blanket root access vs. work-around such as using @ data var

@kpdecker perhaps you could put an issue up with some bullets to discuss and socialize with the community? then we can try to systematically attack the problem and gain consensus on each point.

[kpdecker]

@jonschlinkert working through all of the issues is one of the major tasks here. I'll try to prioritize this higher but as a volunteer on an OSS project with only so many hours in the day its tough.

[jonschlinkert]

👍 I hear you there

[evil-shrike]

I can see two points here:

• a feature for easy access root context in any nested helper/block/etc - this would be a very helpful, because traversing with "../" is error-prone.
• issues with current behaviors of block helpers - i.e. when we have to add ".." to go out current context of ANY block helper. So N nested "if will create N nested contexts. Such behavior was very confusing for me when I encountered with it even after more than a year of using HB. I really didn't understand that even "if creates nested context. I even created a bug Expression "../" inside "#if" can't exit "#with" context #601 which makes no sense indeed (BTW: it's very long way to build and run tests for HB because of need to install node, ruby, ruby devtools (!), rake and other gems).
  So I'd say that this's a bug (even if it's by design). Wouldn't it make sense to not nest a block's context if it hasn't changed? Not every helper can change context.

[jonschlinkert]

@kpdecker, could subexpressions be used to achieve this? Looks like it should might, but I haven't had a chance to test. thanks!

[kpdecker]

@jonschlinkert strawman? I think the simplest solution here is to just add @root variable to the data object but I'm hesitant to do that until the depthed question is answered sufficiently.

[jonschlinkert]

Strawman implies that I was putting forth some kind of argument, which I'm assuming is a result of me using the word "should" instead of "might". If that's the case, sorry for the confusion. I wasn't stating that "subexpressions ought to be used to achieve this", just asking "if they could be".

Also, now that I've looked more closely at subexpressions I think my initial (incorrect) interpretation was the inverse of how they actually work. Regardless, the feature still looks awesome, a great addition to Handlebars. Anyway, sorry about the confusion.

[kpdecker]

@jonschlinkert no worries. I think something like @root.foo or similar is going to be the best route for this, which can actually be implemented outside of the library itself it people want to play around with that.

[doowb]

@kpdecker we have this pending PR on assemble-handlebars, and I'm wondering if this looks like it could solve the issue.

I think it would allow doing... {{root.foo}} from any place, but I haven't had a chance to test it yet.

[jonschlinkert]

@kpdecker I know you're super busy, but would you mind just glancing at the PR to give us your insight as to whether or not this is a good approach? nothing detailed.

[kpdecker]

@doowb @jonschlinkert Why not just do @root.foo? I'm not a fan of that solution as it could conflict with context variables named root and creates a lookup that could surprise people if they don't know to expect this.

[jonschlinkert]

@kpdecker makes sense thanks. so just use createFrame?

[jonschlinkert]

ah, nice. I was actually asking if createFrame is what I should use, I need to take more time on my replies! sorry

[ericf]

Sweet! Glad to see this merged.

[BrewDawg]

Can somebody please show us how the API works?

If it's @root then how do we use it to access data?

I'm hoping it's {{root.SomeData}} ?

[jessehouchins]

Does this get passed down to partials somehow?

[kpdecker]

@BrewDawg {{@root.someData}} see the tests.
@jessehouchins it should. If it's not I would consider that a bug

[doowb]

@kpdecker Thanks for merging this. I'm glad to see this in the main branch instead of us trying to do something that would cause conflicts.That's exactly why I was asking for your advice on the other PR.

[winstromming]

@kpdecker Good stuff. Do you have an estimate on when this might make an appearance in the next npm release for those of us using grunt?

[jezell]

+1 this is awesome. push it!

[AndrewEastwood]

+1

[kpdecker]

Released in v2.0.0-alpha.1

[jonschlinkert]

👍 !

[winstromming]

Lovely!

[jezell]

yay!

[regiskuckaertz]

Very late on this but wouldn't it be more idiomatic/efficient to keep using the tree traversal notation to access top-level variables instead of introducing a new syntax? Like so:

{{ /someVar }}
{{ /someOther.var }}

[shellscape]

I'm not seeing any documentation on how the root is used/called upon within a helper. Could someone post an example and/or update the documentation?

[AndrewEastwood]

yeah! how to get root in partials and blocks?