Allow arguments to be passed to content areas #285#323
Allow arguments to be passed to content areas #285#323jonspalmer wants to merge 2 commits intoViewComponent:masterfrom
Conversation
|
ping @andrewmcodes @rosendi @thomasbrus |
jonspalmer
force-pushed
the
arguments_to_content_areas
branch
from
97d3e51 to
b1bcb89
Compare
| assert_selector(".title strong", text: "Hello!") | ||
| assert_selector(".body", text: "Have a nice day.") | ||
| assert_selector(".footer", text: "Bye!") | ||
| end |
There was a problem hiding this comment.
With this change "wrapping" the render arguments results in a stack overflow. Its a weird use case anyway and not one that I'm that bothered about supporting. Seems like anyone rendering the component can choose one mechanism or the other.
| content = view_context.capture(&block) | ||
| define_singleton_method(area) do |*args| | ||
| block = ->() { content } unless block_given? | ||
| view_context.capture(*args, &block) |
There was a problem hiding this comment.
This is the key change. Rather than capturing the block immediately and storing the result in the attr_reader instance variable we redefine the method and capture the block when its called passing the arguments.
|
@jonspalmer thanks for putting this together. I vote that we let https://github.com/github/view_component/issues/325 play out before moving forward with any further changes to content areas ❤️ |
|
@joelhawksley Agreed. We're getting there on #325 I think the answer will be clear out of that |
|
Closing as stale, feel free to reopen if you'd like ❤️ |
2 participants
Summary
Alternative solution than #322 for passing arguments to content areas as requested in #285
Other Information
I'm not 100% convinced we need this complexity. I'd love more example use cases. But assuming an agreed need I think this is the way we'd do it