-
Notifications
You must be signed in to change notification settings - Fork 21.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make possible rendering of a block with a layout and a collection. #13447
Conversation
both render_partial and now collection_with_template render the block via I am not sure this make sense. In a controller layout scenario the template is rendered first and is therefore able to supply content_for to the layout. Here, the block is rendered on demand, and is not able to supply content to the the layout. So what value does Also the docs already state that the layout is able to pass args to the block, so I guess rendering the block first is not an option. So perhaps it makes sense to avoid |
well, there are tests that depend on |
@@ -412,6 +412,15 @@ def test_render_layout_with_block_and_yield_with_params | |||
@view.render(:layout => "layouts/yield_with_params") { |param| "#{param} Content from block!" } | |||
end | |||
|
|||
def test_render_layout_with_collection_and_block_and_yield_with_params |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could make this a bit more readable without sacraficing line count:
args = {layout: "layouts/yield_with_params", collection: %w[item1 item2], as: :item }
actual = @view.render(args) do |param, locals|
"#{param} Content from block! #{locals[:item]}:#{locals[:item_counter]}"
end
expected = %(Yield! Content from block! item1:0\nYield! Content from block! item2:1\n)
assert_equal expected, actual
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this test started as a copy, they all look like this, I think it's readable enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was hard for me to read, even if the others are hard to read no reason we can't make this one better. At the end of the day it won't block the PR but are you happy with the Rails codebase being just good enough ? 😄
going to make a change later, don't merge |
I am thinking of the following change: content = template.render(view, locals) do |*name|
if view._yield_to_block?(name.first, @block)
name << name.extract_options!.merge!(locals)
view.capture(*name, &@block)
else
view._layout_for(*name)
end
end
def _layout_for(*args, &block)
name = args.first
if _yield_to_block?(name, block)
capture(*args, &block)
else
super(name)
end
end
def _yield_to_block?(first_yield_arg, block)
block && !first_yield_arg.is_a?(Symbol)
end the idea is to only do locals merging if you know you are going to be capturing the block, but that decision is made in _layout_for, so I factored it out. Should I go with this? |
@rafaelfranca can you please review this and the proposed changes above |
@rafaelfranca - or suggest someone else |
ack. Assigned to me and I'll take a look tomorrow |
@rafaelfranca I believe this is still an issue. Anything I can do to get this bumped? |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Fixes #13354.