link_to_if/link_to_unless inconsistencies

Hi there,

Seems like in the positive condition, link_to_if and link_to_unless are inconsistent. When I send a block to link_to (or for that matter anything else that calls content_tag) the block is used to determine the content in the case that “name” is not provided. It gets around this by shifting the args, effectively, as in (html_options, options, name = options, name, block if block_given?).

However, with link_to_if/link_to_unless, when the condition is met it always uses the main content. As in:

link_to_if(true, root_path) do

My Link <%= some_helper %>

end

looks like “/” in the UI and the block is ignored. I’d love to fix this, but want to make sure there isn’t some good reason first.

Thanks.

It is the way they work. See the documentation. The block is used only when the condition is not met.

I get that that’s the way that it works, my point was that it’s inconsistent. Right now you can’t achieve the normal link_to behavior when the condition is met. We can preserve the behavior for the negative case and still get the content_tag block benefit for the positive case.

If that is possible without breaking backward compatibility go ahead, but I can’t think in a way to make it backward compatible.

It would necessarily break backward compatibility with the positive condition, but that’s the point that I’m making. If it’s not going to be accepted that’s fine, I was just hoping to understand why.

In this use case, how would one specify the content to be used if the condition is `false`?

I can't think of a way that isn't clunkier than the plain ERB way to accomplish the same thing:

<% if condition %>   <%= link_to foo_path do %>     Content for true   <% end %> <% else %>   Content for false <% end %>

IMO, `link_to_if` and `link_to_unless` are intended to capture a common pattern that would otherwise lead to repeated strings / code. If you need a behavior that's well outside of that pattern, just write ERB / helpers / etc.

--Matt Jones