Thanks for opening this!

I think this approach makes sense, but I think there's a few points worth discussing. I think we'll want to support renders_many slots in addition to the existing support for renders_one slots.

I think there's also one drawback to the API, which is that arguments can't be passed to the slots which narrows the possible use-cases for this functionality.

We've been discussing changing the slots API to have with_#{slot_name} as an explicit setter, so that with_content can be called on Slots that define no arguments.

e.g. with the change to the slots API, the following could work:

<%= render DisabledComponent.new do |c| %>
  <% c.with_enabled.with_content('enabled') %>
  <% c.with_disabled.with_content('disabled') %>
<% end %>

There's some overlap there, so I'm curious if that would help this particular use case.

Thanks for looking at it @BlakeWilliams!

I can see the argument for supporting renders_many for consistency across the two slot types. I can't envision a scenario when I would use a with_#{slot_name}_content for setting a renders_many slot more than once.

BlogComponent.new.with_post_content("My blog post content").with_post_content("My other blog post")

I could see using it if I was only setting one, but the slot happened to be a renders_many for other use cases.

BreadcrumbComponent.new.with_crumb_content("Home")

We've been discussing changing the slots API to have with_#{slot_name} as an explicit setter, so that with_content can be called on Slots that define no arguments.

e.g. with the change to the slots API, the following could work:

<%= render DisabledComponent.new do |c| %>
 <% c.with_enabled.with_content('enabled') %>
 <% c.with_disabled.with_content('disabled') %>
<% end %>

There's some overlap there, so I'm curious if that would help this particular use case.

My main use case was to avoid passing a block to my DisabledComponent to set some string values that could easily just be arguments. I think the cleanest API is probably what I started with DisabledComponent.new(enabled: "Apply", disabled: "Applying...") but I don't think it would generalize well to all slot names, and all components. And, in any case, I don't think it's desired/good/wanted to have ViewComponent start messing with the initializer. It would be very backwards incompatible and would just generally be hard to extend when writing your own initializers.

So while I like specifying the content for the slot as a named argument in my particular case, I don't think it's a good candidate for inclusion in the framework. But I think the with_#{slot_name}_content method is a better general API for achieving the same ends. To my eye, it reads more clearly than with_#{slot_name}.with_content. And because it's defined directly on the component instance, it makes chaining multiple with_#{slot_name}_content more ergonomic.

Those are my 2¢. It won't hurt my feelings though if the decision is that this API isn't one you want the framework to support 😄