-
-
Notifications
You must be signed in to change notification settings - Fork 4.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
Support for the block form of {{#unbound}} #1457
Conversation
+1 |
Looks like a great feature. I will try to review it when I can. Or maybe @wycats can do it. |
Related to #444 |
// If we have an {{unbound}} block, set the option so nested output can | ||
// be automatically unbound. | ||
if (block.mustache.id.string === "unbound") { | ||
var originalValue = this.options.insideUnboundBlock; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you're going to stash things inside of this.options, perhaps you should stick it inside a this.options.ember object?
@eviltrout it probably makes sense to completely remove all traces of the unbound block in this case. |
Okay I've done the easy stuff (see the above commits) Removing all traces of the {{unbound}} block seems harder for me. Are there any tips you can give me of how to achieve such a thing? I have an idea logically of what should happen (the block should be replaced in the AST with its compiled contents) but I'm not sure how to do it. |
@eviltrout It looks like this doesn't merge cleanly anymore. |
Weird, I thought Travis was supposed to say something. I will fix. |
the block will be bound. Example: {{#unbound}} {{firstName}}, {{age}} {{/unbound}} Is equivalent to: {{unbound firstName}}, {{unbound age}}
Says it's good to merge again! |
Any updates on this? It's been a month. |
@wycats, what do you think? |
@eviltrout the changelog should be updated for this |
@twinturbo @wycats is the changelog the only thing blocking this being merged in? |
I discussed it with @wycats and the advantage of #unbound is not as great as it used to be, thanks to @ebryn's recent improvements with observers. The issue is it's not clear when you would use #unbound and not want to use the #group helper. There is a small improvement in using both, but it's quite minor on most of our app's views - somewhere in the range of 10ms. I'm not sure it's worth saving just 10ms and losing bindings, when #group provides them. I think we can probably shelve the feature for now unless there's a good reason to use it I can't seem to think of. |
There are a need for a unbound each block. When trying to iterate trough a model for use in other javascript plugins (like twitter-bootstrap carousel), the metamorph script tags influence the javascript handling the carousel. I have tried different photo carousels but none of them are working because of this issue. |
@QuentinLangeveldt you may want to look into the group helper -> https://github.com/emberjs/group-helper |
@stefanpenner @eviltrout much like @stefanpenner I've been somewhat stymied by the metamorphs mucking up various other js libraries (specifically both twbs carousel and now foundation orbit). IMO this is technically a deficiency of these other libraries, but it would be nice if there were an easily reached mode of rendering things with Ember that would play nice. The twbs seems to have no desire to address the issue. I'm going to see how zurb feels about a similar improvement to orbit. |
@sdhull HTMLBars is on its way and will fix the woes of metamorph tags messing up these libraries. |
@sdhull Even i am facing same issue. Trying to create bootstrap carousel using {{#each}} helper. Carousel navigation doesn't seems to be working because of script tags. Any workarounds ? |
@rlivsey @eviltrout Any idea bout progress of {{#unbound}} block helper ? It would be great to have |
Oh man this issue is a blast from the past. As noted above we closed this because it was not a major improvement for performance reasons when you could use the group helper. HTMLBars will fix issues with metamorphs, but until then you can try creating your own views that produce raw strings if you REALLY need performance and no metamorphs. It's much uglier and less maintainable though so I don't recommend it unless you really need to. |
@eviltrout hah yeah sorry to resurrect such an old issue. @devendrawani (and everyone) maybe you could show me some love and go +1 my PR for zurb Foundation? foundation/foundation-sites#4079 😄 For any who (like me) has no idea what HTMLBars is, Google has turned up an enlightening discussion , which links to the repo (which appears active), and dependent lib 'bound-templates'. It sounds like it will be ready in the near future, without any real "blockers", just hard work and time. |
@sdhull :) Sure. @eviltrout : Agree on using {{#group}} for time being. But faced trouble while accessing context when #group used along with #with. Will open new issue for same in group-helper. |
I couldn't get group helper to work at all, so YMMV. |
I'm looking at using the unbound block helper to prevent updates from re-rendering a collection. The reason has nothing to do with performance and everything with preventing user confusion. Can this be achieved today in another way? |
None of the output within the block will be bound. Example:
{{#unbound}}
{{firstName}}, {{age}}
{{/unbound}}
Is equivalent to:
{{unbound firstName}}, {{unbound age}}