-
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
#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: