Are "floating slots" an accepted use case, bad practice, or something new?

[rhysb27]

Firstly, please forgive me if I'm taking the liberty of coining a name for an idiom which already exists within the use cases of this library. I've done extensive searching and couldn't find anything similar.

What I mean by a "floating slot" is a component slot defined by some component, but not referenced within the component's template. Instead it is rendered by an ERB execution tag (<%= ... %>) in the view, inside the parent component's content block.

I did this to achieve rendering a slot within the component's content, as the content in question is a form block. Given everything I've seen about ViewComponent not playing nice with Rails' form helpers, I'm very keen to keep the forms themselves in the views. I'll post a simplified example at the bottom. After trawling the forums and documentation for a way to achieve this, I came up empty and just decided to give it a go, and to my surprise, it worked.

However my question is is this supposed to work, or am I doing something dangerous/unsupported? In the case of the latter, is there a better way to achieve what I need here? Rendering slots inside variable content seems like it would be a somewhat common use case but this feels dirty.

Thank you for taking the time to read this.

Example

Primary component: app/components/sync_component.rb

class SyncComponent < ViewComponent::Base
  # Here's the so-called floating slot:
  renders_one :status, types: {
    progress_spinner: ->(**kwargs) { SyncStatus::ProgressSpinnerComponent.new(**kwargs) },
    # More status options eventually.
  }

  attr_reader :form_ref

  def initialize(id)
    @id = id
    @turbo_frame_id = "live_update_ack__#{id}"
    @form_ref = "live_update_form__#{id}"
  end
end

Primary component's template: app/components/sync_component.html.erb

<%# Including this for sake of complete context but I think the only thing that's relevant is the lack of `status` %>
<div x-data="{ pending = false, ack = false}"
     @input.debounce.1500ms="$nextTick(() => { pending = true; $refs.<%= @form_ref %>.requestSubmit(); })">
  <%= helpers.turbo_frame_tag @turbo_frame_id %>
  <%= content %>
</div>

View (segment): app/views/.../edit.html.erb

<%# ... %>
<%= render SyncComponent.new("notes") do |sync| %>
  <%= simple_form_for @foo, url: foo_note_path(@foo), html: { "x-ref": sync.form_ref } do |f| %>
    <%# Executing the slot in the view instead: %>
    <%= sync.status_progress_spinner do %>
      <%= f.input :notes %>
    <% end %>
  <% end %>
<% end %>
<%# ... %>

[boardfish]

Seems fine to me! I think about slots as just defining another public method on the component class. It could be worth adding a comment to suggest that the status slot isn't directly rendered by the template and should be called from within the component's content block, if what you're describing is the only intended use.

As an aside, I don't know if you've seen the capture compatibility patch already? That might alleviate some of your form concerns.

[rhysb27]

Thanks for the reply! Had Cameron not replied to suggest just using a method I definitely would have added the comment you suggested, for the extra legibility. It's good to know that this does work and isn't a crime against the gem, in case I end up needing it legitimately in the future, but for now the "method method" seems clearer and more stable.

Somehow despite the hours I spent on the ViewComponent website, no, I hadn't read about the capture compatibility patch! While my understanding of it is hazy, I don't think it solves this specific problem as each form is likely to be unique (and indeed may not just purely be a form, it could be arbitrarily nested) but it's good to know it's there should we need it in the future! Thanks for bringing my attention to it.

[camertron]

Hey @rhysb27, interesting question! As @boardfish says, this seems fine to me as well, but it's not really how slots were designed to be used. I feel like what you're doing works sort of by accident 😅 It would be more inline with the spirit of the slots API to refactor a bit. Here are a couple of alternative ideas.

Plain 'ol ruby methods

The idea here is to define a method called #status_progress_spinner that returns an instance of the component. The return value can be rendered in the view like any other component. Using a slot instead will wrap the component in an instance of ViewComponent::Slot, which is fine but unnecessary.

app/components/sync_component.rb

class SyncComponent < ViewComponent::Base
  def status_progress_spinner(**kwargs)
    SyncStatus::ProgressSpinnerComponent.new(**kwargs)
  end

  # ... more code here
end

app/views/.../edit.html.erb

<%= render SyncComponent.new("notes") do |sync| %>
  <%= simple_form_for @foo, url: foo_note_path(@foo), html: { "x-ref": sync.form_ref } do |f| %>
    <%# Executing the slot in the view instead: %>
    <%= render(sync.status_progress_spinner) do %>
      <%= f.input :notes %>
    <% end %>
  <% end %>
<% end %>

Using composition

Here, an instance of SyncComponent is passed into SyncStatus::ProgressSpinnerComponent. All the ivars in SyncComponent have been exposed using attr_reader, and are therefore available to ProgressSpinnerComponent (since I assume accessing this data is why the floating slot was created to begin with).

app/components/sync_status/progress_spinner_component.rb

class SyncStatus::ProgressSpinnerComponent < ViewComponent::Base
  def initialize(sync:, **kwargs)
    @sync = sync
  end
end

app/views/.../edit.html.erb

class SyncComponent < ViewComponent::Base
  attr_reader :id, :turbo_frame_id, :form_ref

  def initialize(id)
    @id = id
    @turbo_frame_id = "live_update_ack__#{id}"
    @form_ref = "live_update_form__#{id}"
  end
end

app/views/.../edit.html.erb

<%= render SyncComponent.new("notes") do |sync| %>
  <%= simple_form_for @foo, url: foo_note_path(@foo), html: { "x-ref": sync.form_ref } do |f| %>
    <%# Executing the slot in the view instead: %>
    <%= render(SyncStatus::ProgressSpinnerComponent.new(sync: sync)) do %>
      <%= f.input :notes %>
    <% end %>
  <% end %>
<% end %>

[rhysb27]

Thanks for such a detailed reply! I like the first solution, and did think about it for a while early on originally but wasn't sure if it was idiomatic enough and swiftly forgot about it. Looking at it now, it certainly seems more idiomatic than the current solution, especially having been suggested by someone else.

The primary advantage of the second solution appears to be:

All the ivars in SyncComponent have been exposed using attr_reader, and are therefore available to ProgressSpinnerComponent (since I assume accessing this data is why the floating slot was created to begin with).

but here that assumption doesn't hold true - the slot exists more or less purely for semantics i.e. it wouldn't make semantic sense to use the ProgressSpinnerComponent outside of a SyncComponent despite there being no attribute-based or logical dependency. That, and the "here's a selection of status indicators but you can only pick one" logic afforded by the polymorphic slot. Maybe that's a code smell on my part, I'm not sure, but it feels like I should group components like this together even if just to prevent misleading or accidental misuse.

For now though I think I'll stick to the first solution as it seems much clearer than what I have now. I could even augment it to allow for the aforementioned "pick a style of status indicator" logic. Thanks again!

[camertron]

I like the first solution, and did think about it for a while early on originally but wasn't sure if it was idiomatic enough and swiftly forgot about it. Looking at it now, it certainly seems more idiomatic than the current solution

Interesting yeah, I think slots are great but they do tend to get used to solve problems they weren't designed for, probably because we haven't done a great job explaining how they work. At the end of the day, all renders_one and renders_many do is define several methods and store state in ivars. We've been considering adding a section to the docs with recipe-style info that would contain patterns like this to provide solutions to problems that slots aren't an ideal fit for.

but here that assumption doesn't hold true - the slot exists more or less purely for semantics

Ah ok, that makes sense 👍

That, and the "here's a selection of status indicators but you can only pick one" logic afforded by the polymorphic slot. Maybe that's a code smell on my part, I'm not sure, but it feels like I should group components like this together even if just to prevent misleading or accidental misuse.

I think the namespacing you're already using is grouping them, although because this is Ruby there's nothing preventing someone from rendering one of the sub-components any time they like. If this were java, we could slap a private final onto the class and that would be that 😅

As you suggest, you could replicate the polymorphic slot behavior, maybe like this

class SyncComponent < ViewComponent::Base
  def status_component(type, **kwargs)
    case type
    when :progress_spinner
      SyncStatus::ProgressSpinnerComponent.new(**kwargs)
    # more when statements here
    end
  end
end

[reeganviljoen]

I like the first solution, and did think about it for a while early on originally but wasn't sure if it was idiomatic enough and swiftly forgot about it. Looking at it now, it certainly seems more idiomatic than the current solution

Interesting yeah, I think slots are great but they do tend to get used to solve problems they weren't designed for, probably because we haven't done a great job explaining how they work. At the end of the day, all renders_one and renders_many do is define several methods and store state in ivars. We've been considering adding a section to the docs with recipe-style info that would contain patterns like this to provide solutions to problems that slots aren't an ideal fit for.

but here that assumption doesn't hold true - the slot exists more or less purely for semantics

Ah ok, that makes sense 👍

That, and the "here's a selection of status indicators but you can only pick one" logic afforded by the polymorphic slot. Maybe that's a code smell on my part, I'm not sure, but it feels like I should group components like this together even if just to prevent misleading or accidental misuse.

I think the namespacing you're already using is grouping them, although because this is Ruby there's nothing preventing someone from rendering one of the sub-components any time they like. If this were java, we could slap a private final onto the class and that would be that 😅

As you suggest, you could replicate the polymorphic slot behavior, maybe like this

class SyncComponent < ViewComponent::Base
  def status_component(type, **kwargs)
    case type
    when :progress_spinner
      SyncStatus::ProgressSpinnerComponent.new(**kwargs)
    # more when statements here
    end
  end
end

@camertron I think a recipe style section for slots in the docs would be great