-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
#each skips iteration on undefined values #1093
Comments
This was changed due to #1065 where helpers fail when executing against a null context for non-strict mode. I would suggest using |
Same problem with undefined values on lout for me where I try to iterate over objects. |
@Marsup the root problem is that helpers were being called like
It's not ideal but seems to provide the best middle ground for handling undefined in non-strict mode. |
You should probably explicitly check for null and undefined, other falsy values should work. |
Good call, took that into account. |
Released in 4.0.3 |
Thanks, works like a charm! |
Fixes #1319 Original behaviour: - When a block-helper was called on a null-context, an empty object was used as context instead. (#1093) - The runtime verifies that whether the current context equals the last context and adds the current context to the stack, if it is not. This is done, so that inside a block-helper, the ".." path can be used to go back to the parent element. - If the helper is called on a "null" element, the context was added, even though it shouldn't be, because the "null != {}" Fix: - The commit replaces "null" by the identifiable "container.nullContext" instead of "{}". "nullContext" is a sealed empty object. - An additional check in the runtime verifies that the context is only added to the stack, if it is not the nullContext.
Fixes #1319 Original behaviour: - When a block-helper was called on a null-context, an empty object was used as context instead. (#1093) - The runtime verifies that whether the current context equals the last context and adds the current context to the stack, if it is not. This is done, so that inside a block-helper, the ".." path can be used to go back to the parent element. - If the helper is called on a "null" element, the context was added, even though it shouldn't be, because the "null != {}" Fix: - The commit replaces "null" by the identifiable "container.nullContext" instead of "{}". "nullContext" is a sealed empty object. - An additional check in the runtime verifies that the context is only added to the stack, if it is not the nullContext.
Fixes #1319 Original behaviour: - When a block-helper was called on a null-context, an empty object was used as context instead. (#1093) - The runtime verifies that whether the current context equals the last context and adds the current context to the stack, if it is not. This is done, so that inside a block-helper, the ".." path can be used to go back to the parent element. - If the helper is called on a "null" element, the context was added, even though it shouldn't be, because the "null != {}" Fix: - The commit replaces "null" by the identifiable "container.nullContext" instead of "{}". "nullContext" is a sealed empty object. - An additional check in the runtime verifies that the context is only added to the stack, if it is not the nullContext.
Fixes #1319 Original behaviour: - When a block-helper was called on a null-context, an empty object was used as context instead. (#1093) - The runtime verifies that whether the current context equals the last context and adds the current context to the stack, if it is not. This is done, so that inside a block-helper, the ".." path can be used to go back to the parent element. - If the helper is called on a "null" element, the context was added, even though it shouldn't be, because the "null != {}" Fix: - The commit replaces "null" by the identifiable "container.nullContext" instead of "{}". "nullContext" is a sealed empty object. - An additional check in the runtime verifies that the context is only added to the stack, if it is not the nullContext. Backwards compatibility within 4.0.x-versions: - This commit changes the compiler and compiled templates would not work with runtime-versions 4.0.0 - 4.0.6, because of the "nullContext" property. That's way, the compiled code reads "(container.nullContext || {})" so that the behavior will degrade gracefully with older runtime versions: Everything else will work fine, but GH-1319 will still be broken, if you use a newer compiler with a pre 4.0.7 runtime.
Fixes #1319 Original behaviour: - When a block-helper was called on a null-context, an empty object was used as context instead. (#1093) - The runtime verifies that whether the current context equals the last context and adds the current context to the stack, if it is not. This is done, so that inside a block-helper, the ".." path can be used to go back to the parent element. - If the helper is called on a "null" element, the context was added, even though it shouldn't be, because the "null != {}" Fix: - The commit replaces "null" by the identifiable "container.nullContext" instead of "{}". "nullContext" is a sealed empty object. - An additional check in the runtime verifies that the context is only added to the stack, if it is not the nullContext. Backwards compatibility within 4.0.x-versions: - This commit changes the compiler and compiled templates would not work with runtime-versions 4.0.0 - 4.0.6, because of the "nullContext" property. That's way, the compiled code reads "(container.nullContext || {})" so that the behavior will degrade gracefully with older runtime versions: Everything else will work fine, but GH-1319 will still be broken, if you use a newer compiler with a pre 4.0.7 runtime.
If I have an template like this:
Handlebars will render nothing when data is a dict entry with empty value, i.e. if I render above template with
Only
second
will be rendered, butfirst
will be ignored.I have made a JSFiddle to demonstrate the behaviour:
first
https://jsfiddle.net/jag017t2/1/first
https://jsfiddle.net/5n6t61kz/5/I have tested the behaviour with 4.0.0 and it is skipped there as well, so it's a problem introduced in 4.0.0.
Is this the intended behaviour now? It is not stated in the documentation and I can't see a good match in the release notes. It breaks our application, since we expect to have 7
<td>
columns rendered by Handlebars, but 2 are missing due tonull
values.The text was updated successfully, but these errors were encountered: