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

Fix context-stack when calling block-helpers on null values #1321

Merged
merged 1 commit into from Mar 25, 2017
Merged

Conversation

nknapp
Copy link
Collaborator

@nknapp nknapp commented Mar 9, 2017

Fixes #1319

Original behaviour:

  • When a block-helper was called on a null-context, an empty object was used
      as context instead. (#each skips iteration on undefined values #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.

@nknapp nknapp force-pushed the issue-1319 branch 2 times, most recently from 2468864 to 55d1597 Compare March 9, 2017 21:13
@nknapp
Copy link
Collaborator Author

nknapp commented Mar 9, 2017

I'd like to have a short review by any other collaborator.

@nknapp
Copy link
Collaborator Author

nknapp commented Mar 11, 2017

I am not sure, but the compiled template now uses a property of the container (nullContext) that needs to be present in the runtime.
Do I have to increase in the compiler-version? Is this considered to be a breaking change?

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.
@nknapp
Copy link
Collaborator Author

nknapp commented Mar 25, 2017

I have changed the behavior such that compiled templates >=4.0.7 are compatible with runtimes <4.0.7, so it's not breaking change anymore. I will now merge this into 4.x and master

@nknapp nknapp merged commit c8f4b57 into 4.x Mar 25, 2017
@nknapp nknapp deleted the issue-1319 branch March 25, 2017 14:01
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

Successfully merging this pull request may close these issues.

None yet

1 participant