For example, say I want to include a database driven web poll on certain
pages. Using the approach you describe would create both controller and
view dependencies on my web poll (even though say an article controller
really has nothing to do with a web poll). From a pure code perspective,
only needing to include the poll via render component just seems so much
For components where the content is completely unrelated to the rest of
the page and operates on different base objects, components of some
form may be advantageous. The cart example plays of the fact that in a
shop, the prime directive is to buy stuff. Thus, its not a tangential
concern, so its very natural that the cart is available most every
And that's been the far most common use of components I've seen. Where
essential pieces of the application, which uses data that the majority
of actions operate on (or which uses data that can be fetched from an
object which should be available always, like @person.preferences or
something), are chopped up. Components unnecessarily complicates such a
design and partials are usually a better fit.
But when you truly do have a case like the web poll, which is kind of
like a portlet, then the problem with render_component is mostly one of
implementation. Sounds like Ezra is exploring a way to deal with that
doing cells and I've even had thoughts of doing something like another,
internal HTTP request.
In any case, I consider components to be a rare specialty tool. Not a
general purpose architect-my-app-after-it kind of tool.