I’d love to see an alternative to that. Just having a single body is a limitation of the xml’ish nature of html. And please do not say the abominations of jsx - passing markup as attributes.
You cannot use a variable from :let in the :if. The :if is evaluated before anything related to calculating the :let value is even run. When there’s no slot, then there’s no render_slot to execute and hence no value to provide for :let.
Thanks! I suspected as much, but that also means that :if clause is of very limited us. I’m going to give the custom component alternative a go instead.
You can always not render the article from within the parent.
<%= if article.status == :draft, do: render_slot(slot) %>
The point in this case was that I simply wanted to not allow the user to delete an article once it has been published, so I was trying to hide the “Delete” link in the index view for all published articles.
<:action :let={{id, article}}>
<.link
:if={article.status == :draft}
phx-click={JS.push("delete", value: %{id: article.id}) |> hide("##{id}")}
data-confirm="Are you sure?"
>
Delete
</.link>
</:action>
This would be the option to render the slot, but not the link within the slot.
Okay, your original post uses article, which based on what I’m seeing, did not exist in your scope. This makes sense, since you’re asking about an index view.
The easy ways to do this would be to use either version of the if inside the action slot.
<:action :let={{id, article}}>
<%= if condition %>
...link
<% end %>
</:action>
or
<:action :let={{id, article}}>
<.link :if={condition} ...>Delete</.link>
</:action>
I believe either of these will work for you.
Thanks! The first one is what I’m currently using. I’ll give alternative #2 a go as well.
It’s a limitation of having a tree structure.
But it’s funny because while JSX-ish components look like HTML they’re really deeply-nested deferred calls. They don’t behave like HTML at all. The fact that HTML syntax happens to be useful for representing said calls is a fascinating coincidence.
Of course in LiveView they are not deferred unless you use <.live_component />, at which point many useful guarantees mysteriously disappear…
Something like JSX is the best solution I can imagine to the template problem, but I assume what you’re referring to here is something like the “render props” pattern and I agree that is absolutely disgusting. Though still not as messy as named slots because at least it’s clearly communicated they’re flat. Unlike in the OP here where that reality is only discovered downstream of an error message.
I’m tempted to say if nobody has come up with a solution at this point it’s not gonna happen, but maybe that’s a defeatist attitude 
Fully agreed.
Not for me, not here. I would just go back to plain string template at this granularity.
I find it a bit funny that we used to have a bunch of perl and Java libraries to represent document structure as if it were code. We had wrapper functions (or methods, in Java) to represent HTML tags, all so that the programmer could feel comfortable. Now we want to do the opposite and make code seem as if it were markup.
I’m hoping that someday some very wise person comes up with the revolutionary concept of letting code look like code and document structure like document structure. Not holding my breath, however.