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
cleaner.
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
where.
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.
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.
Last time I investigated this, it looked like everything I wanted out
of a component could be obtained by exposing
render_component_as_string, but I couldn't figure out how to do
that.
Last time I investigated this, it looked like everything I wanted out
of a component could be obtained by exposing
render_component_as_string, but I couldn't figure out how to do
that.
Is there a reason that's a bad idea?
Currently, I believe components just have some performance issues. I'd
encourage you to benchmark with and without to see whether it matters
in your case. And then be on the lookout for other/better ideas that we
could possibly do this. As well as keeping in mind that components are
not a general strategy for compartmentalizing things in Rails, unless
they have this portlet-type flavor we're discussing.
Currently, I believe components just have some performance issues. I'd
encourage you to benchmark with and without to see whether it matters
in your case. And then be on the lookout for other/better ideas that we
could possibly do this. As well as keeping in mind that components are
not a general strategy for compartmentalizing things in Rails, unless
they have this portlet-type flavor we're discussing.
Components have had performance issues in EVERY web platform I've
used, but usually that's related to the overhead of an additional
request/ssi, instantiating the execution stack, or something related.
I suspect (but haven't dug into the code to confirm) that the right
way to approach this might be to stick a continuation somewhere in the
rendering path to save all of that setup and use it later to execute
an additional action/view pair.
You can pass vars to a partial using a render option called :locals which points to a hash of names/values to be available as local vars in the partial.
