After your reply I spent a couple hours trying to refactor into a self-contained component. I got kind of close but couldn’t quite drag it across the line. Then I got distracted with higher priority stuff.
If I may ask for a point of clarification:
because all your component’s internal details are exposed to the extending components.
Basically you’re saying to prefer composition over inheritance here right? Surely there are times when inheritance is appropriate. Right?
I’d be curious to understand what sort of “bugs and confusion” the layout frame caused. Obviously the way it works now caused confusion for me (& my colleague when I asked him about it). Surely there’s room for further improvement, though I’m not sure what that would look like yet …
IMO, the word “layout” evokes the idea of a frame that will yield to a template (maybe just because of my Rails background?) I’d like it if
layout worked as I expected but if the Ember team has already been down that road and deemed it confusing, maybe we should just remove the
layout property altogether from
Or maybe simply renaming
template would clarify things and then we could update the docs (scroll to
h2#layouts) to simply indicate that the template can be assigned programmatically.