See this GitHub issue Passing a slot via attributes emits a warning (but still works) · Issue #3399 · phoenixframework/phoenix_live_view · GitHub.
Currently, it is possible to pass along a slot argument to another component, but not without the compiler emitting a warning.
The warning looks like this:
warning: undefined attribute "loading" for component Phoenix.Component.async_result/1
│
133 │ I am a wrapper <.async_result assign={@assign} loading={@loading} inner_block={@inner_block} />
And here is an example of code that will induce the warning.
attr :assign, :any
slot :loading
slot :inner_block
def wrap_async_result(assigns) do
~H"""
<div>
I am a wrapper <.async_result assign={@assign} loading={@loading} inner_block={@inner_block} />
</div>
"""
end
<.wrap_async_result assign={AsyncResult.loading()}>
<:loading>Loading...</:loading>
Finished
</.wrap_async_result>
Assuming attributes and slots will always share the same “namespace” (so there could not be an attribute and slot with the same name defined on a component), it seems useful to be able to pass a slot via attributes.
Are there any downsides I’m not considering?
The coupling. This might not matter much for like inner_block, but all other slots can have their own set of attributes, which can be validated by the compiler, be documented and so on. All that doesn’t really work well if you can pass those slots to further components as is. Conceptually a slots really belongs to the component it’s rendered within, not some child component of it.
Instead the wrapper can explicitly render slots for the subcomponent based on it’s own slots.
~H"""
<div>
I am a wrapper <.async_result assign={@assign} loading={@loading}><%= render_slot(@inner_block) %></.async_result>
</div>
"""
Your example should be…
~H"""
<div>
I am a wrapper
<.async_result assign={@assign}>
<:loading><%= render_slot(@loading) %></:loading>
<%= render_slot(@inner_block) %>
</.async_result>
</div>
"""
…since @loading is also a slot.
I agree that coupling is something to consider when components call other
components. But consider a function calling another function and passing through
arguments — this also introduces coupling, yet it’s natural in many cases.
As for checking and validation not working well, that seems more like a current
limitation of the compiler rather than an inherent conceptual issue with slots
being passed along. I was hoping to open up a discussion about the development
complexity this might introduce and weigh that against the potential benefits.
On the conceptual side, saying that slots belong strictly to the component
they’re rendered within feels a bit rigid to me. It’s similar to saying that
arguments strictly belong to a function and shouldn’t be passed to others.
