Hi, first of all: Congratulations to the v1 release! Thank you for keeping up the hard work 💪
I updated our TYPO3 Handlebars extension to v1 of your library and discovered a bug with the {{#if}} helper. This is my minimal reproducible code:
$template = <<<HBS
{{#if foo.bar}}{{test foo.bar}}{{/if}}
HBS;
$compiled = Handlebars::compile($template);
$result = $compiled(
[
'foo' => 'foo',
],
[
'helpers' => [
'test' => static fn (string $bar) => 'bar: ' . $bar,
],
],
);
var_dump($result);
With 0.9.x of the library, the $result is an empty string. Updating to v1 of the library raises an exception:
Uncaught TypeError: {closure}(): Argument #1 ($bar) must be of type string, null given
This is due to the nested variable, which is passed to the {{#if}} helper (foo.bar), and can be seen in the compiled template:
use DevTheorem\Handlebars\Runtime as LR;
return function (mixed $in = null, array $options = []) {
$cx = LR::createContext($in, $options, []);
$cx->frame['root'] = &$cx->data['root'];
$in = &$cx->data['root'];
return (LR::ifvar(LR::cv($in, 'foo')) ? LR::encq(LR::dynhbch($cx, 'test', [$in['foo']['bar'] ?? null], [], $in)) : '');
};
See the LR::ifvar(LR::cv($in, 'foo')) line, I think it should look differently.
Hi, first of all: Congratulations to the v1 release! Thank you for keeping up the hard work 💪
I updated our TYPO3 Handlebars extension to v1 of your library and discovered a bug with the
{{#if}}helper. This is my minimal reproducible code:With 0.9.x of the library, the
$resultis an empty string. Updating to v1 of the library raises an exception:This is due to the nested variable, which is passed to the
{{#if}}helper (foo.bar), and can be seen in the compiled template:See the
LR::ifvar(LR::cv($in, 'foo'))line, I think it should look differently.