I’m a bit confused about when/where to use render vs components. My understanding is that because components are based on the upcoming web-components spec so they should be used for widgets with no domain knowledge i.e. a calendar would be a component but a meetups-calendar would use render(with associated controller, model, view, template).
Part of my confusion is that render currently seems a bit inadequate for that job, you can’t pass additional parameters through to the controller and they’re not bound when accessed in the view (from recollection). I get the feeling that it’s not really intended to be used that much, is this accurate? Would really appreciate some clarification on this.
It’s as I thought then. My confusion mainly comes from the following:
If I want to pass multiple parameters to a component I can do so with
{{my-component param1=boundValue1 paramValue2}}
but if I want to pass multiple parameters to a controller using render it’s not possible (controller has no access to param1).
{{render 'my-view' model param1=boundValue1}}
When using routes it’s possible to pass multiple values to a controller using either setupController or queryParams. Is it simply that the render helper was created a long time ago and this functionality was never added or is there some deliberate reason for this?
Yeah the render will just inherit the surrounding context, I think. You can “pass in” a model… IIRC. Of course there’s always the possibility I don’t know what I’m talking about.
Nope, render explicitly does not do this. The {{render}} helper renders a combination of a controller, view and template, and optionally allows you to provide a specific model to be set to the content property of the controller. If you do not provide a model, the singleton instance of the controller will be used.
The context of the template will always be the controller.
Definitely not - components and the render helper have different use cases and render is very useful sometimes. You should use render when you want to render a specific controller, template and view together. You cannot pass parameters to render, it is assumed that the controller and its associated model, whether passed in or not, already provide all the context that you need.
If you need to pass in parameters, then the render helper is not what you need and you should use another approach. But render is indeed very usefull in lots of scenarios.
It seems like you have your answer, so I’ll just throw this out there. My understanding might be a little muddled, so please correct me if I’m inaccurate in any part of this, folks.
Render is the most drastic solution to the question of how to display content. For all intents and purposes, it’s like that part of the page is its own little sovereign nation. You can appoint its king by specifying the model and controller etc. but from then on the page into which it’s rendered doesn’t get a say. What’s the use case for this you might ask? Basically when you want to cram different, distinct parts of your app together (so different that they would normally go on their own routes) on the same page for aesthetics purposes. If you were only concerned about how much sense the whole thing makes on the development side, you would probably never use render.
Views are when you need to encapsulate user interaction and display logic for part of the page, while still having access to the controller at large. The are transparent (you can talk to the outside controller from inside the view). They have a mammoth explanation in the docs and the guides.
Components are the small fry out of these three. As you know, they can’t access the outside context. I think you might actually be overestimating their independence though-- they’re not necessarily no-domain-knowledge. I’ve written a lot of my app-specific components. Basically they are the default I go to when I have reuseable or compartmentalized logic and I only resort to a view or render (almost never render) if I really need the controller context.
they’re not necessarily no-domain-knowledge. I’ve written a lot of my app-specific components.
Well this is where my confusion began, as seems to be the ember way I like to split my page up into small areas that have their own view/controller. When I started using ember I gravitated towards using components for everything and didn’t ever really use render. Then I discovered that components is an upcoming spec and having understood it a little better it seemed like it was more appropriate for adding custom widgets (similar to jquery plugins for instance). Another issue was that I didn’t really understand why I was using an MVC framework but ending up putting most of my app into widgets which don’t have separate views and controllers. At this point I switched to using render a lot more. It seemed like a good fit except for the parameters issue…
So now I’m a bit lost, it sounds like render should only be used very rarely and that if you want to split up the page you should really be using components(as opposed to my current practice which is to make heavy use of render). Is it the intention that the MVC is only really used in association with routes?
@alexspeller Hey thanks for that correction. I clearly didn’t know what I was talking about WRT render! Apologies. Perhaps I was thinking of partial, actually!
I guess the problem is, it’s all very specific to whatever your use-case is… so perhaps you could share these use cases… there’s no reason to use any of these things unless you’re repeating yourself. The devil is in how we’re repeating ourselves, I guess
So, perhaps you could explain a bit more about the ways you’re repeating yourself in your app, so we could be a bit more helpful?
I’ve tended to reach for components a lot in the current app I’m building. Having said that, I use partials a lot too to separate out my content.
I think Ember could deal with some better non-trivial examples in its documentation.
