So, gather around and I will tell you a story of a terrible curse. Or not:
Add this to your application helper and use it instead of
render whenever there’s a chance you will call a partial and try to wrap it in a layout.
Takes the current view_flow, stores it, starts a new one, renders your partial, then puts everything back the way it was
###Layouts and Partials
Normally, it’s not so hard to apply a layout to a partial. Why would I apply a layout to a partial ? Am I nuts ? Possibly. Let me explain. Let’s say I have a bunch of things I would like to have similarly formatted = Use case for a layout. Say, you were trying to display something that was self-referencing. Like an Item that has_many items. Yes, that sounds reasonable. The Item object has a ‘name’ property.
rails g scaffold Item name item:references
Now, I warn you, I like haml with a bit o Bootstrap. So that’s how this is going to go down. Let’s say I have a template thus, for rendering one of these thingies and it’s children.
And a partial for rendering an Item
A bit of a tweak to
A little prep in rails console or migrations, whatevs.
Probably need to work on making these names a bit less ‘itemy’
Rails is smart enough to work out what to do at
render folder.contents. It’s going to render a collection, calling the
folders/_folder partial for each Folder in contents. There is another way to do this. I could call
render partial: 'folder/_folder', layout: 'shared/filesystem_object'
instead. The results would be the same - bitterly disappointing.
Let’s take a look at some screenshots.
Well, that’s what we were HOPING for. But actually this is what you end up with:
Let me tell you WTF. It’s pretty simple. Rails has a thing called
view_flow which is an instance of
ActionView::OutputFlow. When you do
content_for it puts the result of that block into the
view_flow.content hash. If
content_for gets called multiple times it concatenates the results. Are you feeling me ? So what happens in our example. Well, the following happens:
content_forfirst item’s :name is called.
content_forfirst item’s content is called BUT it has to do this first:
content_forsecond item’s :name is called (uh oh. what’s in the
content_forsecond_item’s :content is called BUT it has to do this first: (oh dear lord)
- render all the crap above that’s been mashed together
- render all the crap AGAIN
You get the picture…
So get on with it already.
This little fella takes a copy of the
view_flow and makes a fresh one for your recursive call, and puts it back once the result is computed and output. That stops stuff falling all over itself. How do we use it ? Easy. Let’s refer back to this partial:
view_flow feels horribly like a global variable, doesn’t it ? Perhaps there’s a way to make it local-er.
Thanks to André Arko for the inspiration for this solution. His solution doesn’t work for multiple
content_for sections, but rather has a single yield. This didn’t work for my needs. His explanation helped me work out a refinement of his solution. Also, the format of his article inspired the structure of this one. So, many thanks.