I did see that article last night. I’ve gone through it a number of times but it doesn’t really make sense to me given what I know (more like don’t know) about ember and handlebars.
so, I’m curious if this is even possible in ember. This is an easy thing to do in angular ( plunkr: Plunker - Untitled ):
@machty has there been any progress on this? Keep running into situations where overriding parts of components/sub-components would be massive awesome!
Happy to work on a pull request to help get things going?
@rlivsey I would love to see a consolidated gist (or just put it in this thread) of what you had in mind, particularly lots and lots of use cases of things not presently possible/easy to do with the present API.
Will expand on it with some more examples over the course of the day but interested in your opinion if it’s at all feasible / similar to what you’ve been thinking?
We are almost certainly going to be doing something like this approach, particularly with some kind of content-for helper and named yield blocks with default content if no overriding content-for is provided at render time.
Not sure how I feel about passing in options like tagName or class to content-for to convert the passed-in content-for template block fragment into an element; you can always just pass in an element with that tagname and class in as the named template fragment that you supply in the content-for. Also, there might be use cases of using a non-block form of content-for, but pass in data to override the data that the default yield block uses to render its internals, and I wouldn’t want that clashing with the tagName/class namespace used by Ember.View / Component.
I also took a stab at another approach which optionally puts more control over how of things are rendered/bound in the component JS code, which can have its benefits over the template approach to specifying all this stuff, particularly for large components that can only have their internals reconfigured by copying and pasting the whole template and changing only the small part that needs to change. Worth a look: http://emberjs.jsbin.com/ucanam/3884/edit . If we have something like this, it shouldn’t replace the templates-based approach, but give you another way to override.
Pretty cool though that we’ve landed at a lot of the same ideas.
Heya @machty How is all this going? Quite interested in getting the ember-table (ie adepar) guys to incoporate some of these changes so it’s a bit easier to build composable tables with overridability.
I <3 your ideas about reusability in components, BTW.
It seems one would need the ability to have sub-components defined within a component, possibly. Registering all constituent components or elements would seem overkill. Reusability could be garnered by modules later, I’d guess (ie import ember-table-cell as cell from ember-table-component), etc.
Hi! I too really needed more customizable component templates, and decided to see what I could do about it. It turns out that implementing overridable blocks in components is actually possible and quite simple with some custom handlebars helpers.
The controller templates will look something like this:
<h1>Hello from the index page!</h1>
{{#my-component parent=this}}
{{#section 'header'}}
<h2>Header inside my awesome component.</h2>
{{/section}}
<p>
Here goes the main body that fits into the standard "yield" helper.
That's because I'm not in a section.
<p>
{{#section 'footer'}}
<p>Show me in the footer, please.<p>
{{/section}}
{{/my-component}}
The template of the component itself:
<div class="my-component">
<div class="component-header">
{{yield-section 'header'}} {{-- Places header section in here --}}
</div>
{{yield}}
{{#if parent.footerSection}} {{-- Overrides if footer section is specified --}}
<div class="component-footer">
{{yield-section 'footer'}} {{-- Places footer section in here --}}
</div>
{{else}}
<p>Just some generic content in case nothing else was specified.</p>
{{/if}}
</div>
Is this close to what’s suggested here? It’s no nested components, but at least it’s a start. I guess it would be fairly trivial to add a context flag to the section helper to make it use the component’s context as well.