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

In template scope #15

Open
wants to merge 5 commits into
base: devel
Choose a base branch
from
Open

In template scope #15

wants to merge 5 commits into from

Conversation

tmeasday
Copy link
Contributor

@tmeasday tmeasday commented May 1, 2014

Hey Chris,

This branch solves the problems I've seen with helpers + data not correct passing through to the content block of a Layout when used outside of IR.

It's quite a simple change really -- we remove the hacks that pass helper lookups through the Layout Component, and instead us the UI.InTemplateScope that already exists in Blaze.

What this does behind the scenes is wires the __content block up with the Layout component's parent as it's parent. Apparently this is OK, as this is exactly what happens when you use a template as a layout via a block helper inclusion + {{> UI.contentBlock}}.

There's only one downside to all this, and it might be a deal-breaker. I'm keen to hear you thoughts.

The problem is that because the content block is now short-circuited around the Layout, there doesn't appear to be any way to get contentFor to work. That's because it looks like this:

{{#with X}} // outer component
  {{#Layout}}
    // in here, the outer component is the parent
    {{#contentFor}} // so when we try to look up the closest ancestor Layout, it blows up.

Any ideas how to work around this? Otherwise, it seems like an ideal way to make helpers and data work in a rational, sensible way inside yielded regions.

tmeasday added 5 commits May 1, 2014 16:23
@tmeasday
Copy link
Contributor Author

tmeasday commented May 1, 2014

We've also discussed both the helper and the data issue being solved by more flexibility in Blaze. I can probably live with waiting for that, but we should definitely keep this PR around until we get an alternative.

If you are attached to contentFor (probably, I personally don't use it ATM), and can't think of another way to make it work (hopefully you can!), don't spend too long looking at this for now.

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.

1 participant