Skip to content
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

Closed
jenseng opened this issue Feb 20, 2014 · 3 comments
Closed

cannot use multiple subexpressions in the options hash #748

jenseng opened this issue Feb 20, 2014 · 3 comments

Comments

@jenseng
Copy link
Contributor

jenseng commented Feb 20, 2014

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")}}

@jenseng
Copy link
Contributor Author

jenseng commented Feb 20, 2014

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 {{foo a=(bar "a") b=(lol "b")}} as if it were {{foo a=(lol "b") b=(lol "b")}}

kpdecker added a commit that referenced this issue Mar 5, 2014
properly handle multiple subexpressions in the same hash, fixes #748
@dwabyick
Copy link

any chance this can be fixed in 1.3.X ? this is a doozy if you're relying on this pattern.

@kpdecker
Copy link
Collaborator

@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

amireh added a commit to instructure/i18nliner-handlebars that referenced this issue Nov 18, 2020
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
amireh added a commit to instructure/i18nliner-handlebars that referenced this issue Nov 18, 2020
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
amireh added a commit to instructure/i18nliner-js that referenced this issue May 24, 2022
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
amireh added a commit to instructure/i18nliner-js that referenced this issue May 24, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants