Helpers called from with-in @partial-blocks do not have access to the root data.

[rcampbel]

Issue: Helpers called from with-in @partial-blocks do not have access to the root data.

When calling a registered helper from with-in an @partial-block starting from v4.0.7 you no longer have access to the root data that was supplied in v4.0.6.

I believe there was a breaking change added in v4.0.7 that changed how the @partial-blocks are being processed in side of lib/handlebars/runtime.js:invokePartial. This change has been compounded in later commits and bug releases because the data object has changed between v4.0.7 and v4.0.11 .

Root of issue believed to come from the fix added for issue #1252

Objects passed to the helper function:
v4.0.6

		{
			data : {
				root: {name: "Max", age: 38}
				__proto__: Object
			},
			fn:ƒ prog(context),
			hash:{X: 1},
			inverse:ƒ noop(),
			name:"testHelper",
			__proto__:Object
		}

v4.0.11

		{
			data:{
				_parent: undefined,
				partial-block: undefined
			},
			fn: ƒ prog(context),
			hash: {X: 1},
			inverse: ƒ noop(),
			name:"testHelper",
			__proto__: Object
		}

JS Fiddle Cases by Handlebar version:

Handelbars Version	JS Fiddle
v4.0.6	https://jsfiddle.net/6kgLcr8n/5/
v4.0.7	https://jsfiddle.net/6kgLcr8n/4/
v4.0.11	https://jsfiddle.net/6kgLcr8n/3/

^^ Notice the difference in the context between v4.0.6 and v4.0.11 for Test case 2

Was able to reproduce the issue with compiled templates. But I think that the lambda method adds complexity to this issue, since I was seeing in the call stack it was being called up in the call stack (lambda -> partialBlockWrapper -> prog -> 9 -> helper.testHelper.call(...)). In this case when partialBlockWrapper is called there will be no context or options argument passed, which results in the v4.0.11 argument (see the v4.0.11 data above) being passed to the helper.testHelper.

[nknapp]

Hi and thanks for the thorough research. I'm sorry, if I have introduced a breaking change. If there is a way to go back to the old behaviour without breaking any fixes made in the meantime, this should be done.
I'll have a look at it, but I can't promise anything.

[nknapp]

I have stripped down your examples a little, in order to get a minimal test case

• 4.0.6: https://jsfiddle.net/6kgLcr8n/10/
• 4.0.11: https://jsfiddle.net/6kgLcr8n/11/

The data-frame goes missing somewhere. This should definitely not be the case.

[nknapp]

I think I found the problem:

Partial-blocks are called with {{> @partial-block}} and not with {{{@partial-block}}}.

Change this and your example seems to be much more compatible and much less breaking.

It is unfortunate, that this code works at all, or at least pretends to do so. I only found the reason, because my test-case worked and I started to compare it to your example.

Here is the reason why the result is so similar to the partial-block invocation: The compiled partial-block is added to the current data-frame as partial-block, so {{{@partial-block}}} refers to this function just as {{@root}} refers to options.data.root. Handlebars renders functions by evaluating them, so the partial-block-function is evaluated. But all the frame-handling is not performed in this case, because the invokePartial-function never gets called in such a case.

Please check if this is helpful for you.

[nknapp]

Released in 4.0.12