-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cannot use multiple subexpressions in the options hash #748
Comments
actually it's worse than that. you can only have one subexpression in the options hash ... even if you use different helpers, the last one is the only one that gets used (see here) tl;dr: handlebars treats |
properly handle multiple subexpressions in the same hash, fixes #748
any chance this can be fixed in 1.3.X ? this is a doozy if you're relying on this pattern. |
@dwabyick There are a number of changes that are interleaved so I don't believe we are going to be able to backport anything. I suspect that we are gong to desupport the HTMLbars merge for 2.x as there hasn't been much traction on that and it's blocking the otherwise complete 2.x releases, including vital fixes such as the subexpression lookup issues. /cc @ebryn |
the workaround for handlebars-lang/handlebars.js/issues/748 employed a sorting routine that was not commutative and with the v8 upgrade in node11, the order of the arguments changed (and is considered an implementation detail that we're not meant to rely on) and so the routine would yield surprising results this patch reimplements that sorting routine to always yield the same result regardless of the order of the operands, so should work on node < 11 and > 11 test plan: there is already a case for this, so I just added node12 to the travis language matrix
the workaround for handlebars-lang/handlebars.js/issues/748 employed a sorting routine that was not commutative; its output relied on the order of its arguments, and with the V8 engine upgrade in node11, that order has changed[1] the order of the arguments to Array#sory is considered an implementation detail that we can't rely on this patch reimplements that sorting routine to always return the same result regardless of the order of its operands, and so it should work on node <= 10 and >= 11 test plan: there is already a case for this, so I just added node12 to the travis language matrix [1]: nodejs/node#24294
the workaround for handlebars-lang/handlebars.js/issues/748 employed a sorting routine that was not commutative; its output relied on the order of its arguments, and with the V8 engine upgrade in node11, that order has changed[1] the order of the arguments to Array#sory is considered an implementation detail that we can't rely on this patch reimplements that sorting routine to always return the same result regardless of the order of its operands, and so it should work on node <= 10 and >= 11 test plan: there is already a case for this, so I just added node12 to the travis language matrix [1]: nodejs/node#24294
the workaround for handlebars-lang/handlebars.js/issues/748 employed a sorting routine that was not commutative; its output relied on the order of its arguments, and with the V8 engine upgrade in node11, that order has changed[1] the order of the arguments to Array#sory is considered an implementation detail that we can't rely on this patch reimplements that sorting routine to always return the same result regardless of the order of its operands, and so it should work on node <= 10 and >= 11 test plan: there is already a case for this, so I just added node12 to the travis language matrix [1]: nodejs/node#24294
if you attempt to use the same helper more than once within an options hash (via subexpressions), the value from the last call gets used for all of them. here's a simple jsfiddle illustrating the problem. note that it's only broken for the options hash; it works correctly for arguments.
tl;dr: handlebars treats
{{foo a=(bar "a") b=(bar "b")}}
as if it were{{foo a=(bar "b") b=(bar "b")}}
The text was updated successfully, but these errors were encountered: