Slots V2

[BlakeWilliams]

The road to Slots V2

We've been using slots internally for a while now and we really like the concept. It's time to start thinking about how it should look like for ViewComponent 3.0 and beyond.

Our feelings so far

Good:

• Multi-area components are easier to write and consume. (e.g. Modals with a header, body, footer, actions)
• Very useful to be able to render a slot multiple times. (e.g. Rows in a table)

Bad:

• API can sometimes feel awkward.
  • When rendering a slot, arguments don't align with the slot's initializer due to the first argument being the slot's name e.g. (component.slot(:header, classes: "my-class-name") calls Header.new(classes: "my-class-name")

Things we want to change

• Migrate from component.slot to component.slot_name. e.g. Given a component with a header slot, we could call component.header instead of component.slot(:header)
• Add support for passing collections to slots. e.g. with_slot :row, collection: true you could call component.slot(:row, @rows)

We'd love to hear from you!

Are you using slots? We'd love to hear your thoughts/experiences using slots. We want to know what you like, what could be improved, and what you'd like to see in the future.

cc @bbugh @jensljungblad @jonspalmer @thomasbrus since y'all had some really great thoughts and input on v1.

- @joelhawksley & @BlakeWilliams

[jonspalmer]

I'm a big fan of the component.slot_name API. Very much a Rails style API.

I like the simplicity of the collection API too. I remember there being reasons why we needed the explicit API but I no longer have the details paged into my brain. If we can make it work simply I'm a fan.

[fsateler]

Hi! I was directed here from #451 .

So, the question would be, if slots can be made to also solve #387.

Slots, as currently documented, and with the modifications presented here, appear to be a way for the component user to inject content into the component. Slots do not have their own template, and are exposed to the end user.

OTOH, what I actually need is only a way to be able to extract methods from the main method, for internal code organization purposes.

For #387 to be solved, slots would need to (be able to):

1. Have a template
2. Omit the block when calling (ie, don't have content).
3. Hideable from the user, and become private implementation details. (this is actually just desirable, can be accomplished with documentation).
4. Have reasonable performance characteristics (ie, relatively low overhead so it can be used for example with a thousands-long table). This is difficult with a Slot object because it requires an allocation for each invocation, which either allocates a large block of memory, or thrashes the GC if the list is large.

I specifically don't want a hypothetical TableComponent user to know (or care) that there is a slot that renders the row. All the user should do is render TableComponent.new(items).

[BlakeWilliams]

@fsateler While writing up docs for v2 I thought of this conversation.

Do you think lambda slots in V2 would solve at least some of your desired use-case? https://github.com/github/view_component/pull/503/files#diff-b4d68dc855d0f9476d3f2ee343853bd21bf82ea9960d0cf06661baa244439dd6R251-R272

[fsateler]

Almost. I would be missing a way of using a template. The docs suggest using tag and content_tag helpers, but that makes me wonder why a special syntax at all? Why not just a regular method?

If the lambda body could be replaced with a template, I think it could work. But as it stands, they don't offer much over a regular method (because remember I want templates to organize my code, not to provide the user with entry points).

[joelhawksley]

Another thing that has come up for us internally is the desire to be able to pass content to slots via an argument vs. a block.

For example, we have a component that has a title slot. Sometimes we want to pass custom HTML to it, so it accepts a block. But often we just want to pass a short string. Being able to pass in a content argument or the like, as is currently possible with content_areas, would be useful.

[jensljungblad]

Another thing that has come up for us internally is the desire to be able to pass content to slots via an argument vs. a block.

For example, we have a component that has a title slot. Sometimes we want to pass custom HTML to it, so it accepts a block. But often we just want to pass a short string. Being able to pass in a content argument or the like, as is currently possible with content_areas, would be useful.

I actually ran into this quite a bit when working on https://github.com/jensljungblad/elemental_components. I ultimately decided to keep them separate, but conceptually, there is very little difference between an "attribute/argument" and the content block. The only difference is the length and format of the content they contain. If you scroll down to "Alternative 3" in jensljungblad/elemental_components#32 I had some kind of ideas around tying the block to one of the attributes.

In any case, I agree with you! To use the alert example from the issue I linked, I frequently wanted to do stuff like this:

<%= render(AlertComponent.new(message: "A short message")) %>

<%= render(AlertComponent.new) do %>
  A longer message with some HTML etc
<% end %>

I don't think connecting the block to a named argument is probably worth it though, so using the already reserved content name seems fine to me:

<%= render(AlertComponent.new(content: "A short message")) %>

<%= render(AlertComponent.new) do %>
  A longer message
<% end %>

[jensljungblad]

If I remember correctly, I usually worked around this doing something like this in the template:

<%= alert.content || alert.message %>

Or by creating a method on the component object doing the same thing. But feels a bit silly to have to do this.

[bbugh]

@joelhawksley I think this would be a nice feature as well. I encounter this pattern often in Vue which does not have a built-in solution for it. For example, one of our components has a slot named label and a prop named label, and if the slot is set it takes precedent over the label prop. I've often wished Vue had a setting that worked like this automatically because the current pattern syntax can be tricky depending on usage.

I have noticed this limitation in ViewComponent as well when making a card component, but just settled on using slots since the slot syntax is less verbose in ERB/ViewComponent.

One problem to solve I can think of is if both a slot and an argument with the same name are defined, which takes precedent? Example:

<%= render SomeComponent.new(label: "My Label") do |c| %>
  <% c.slot(:label) do %>
    Some other label, who will win?!
  <% end %>
<% end %>

[jensljungblad]

• Migrate from component.slot to component.slot_name. e.g. Given a component with a header slot, we could call component.header instead of component.slot(:header)

That's the API I chose for https://github.com/jensljungblad/elemental_components as well. There's an example here: https://github.com/jensljungblad/elemental_components#elements.

I remember there being reasons why we needed the explicit API but I no longer have the details paged into my brain. If we can make it work simply I'm a fan.

I too remember it was brought up somewhere, but I can't seem to find it!

[bradgessler]

Migrate from component.slot to component.slot_name. e.g. Given a component with a header slot, we could call component.header instead of component.slot(:header)

I'm a huge fan of this.

Add support for passing collections to slots. e.g. with_slot :row, collection: true you could call component.slot(:row, @rows)

The API for collections of slots has been bothering me. In some cases it acts like an array; in other cases it doesn't. I propose that the API goes all-in on acting like an array.

Consider this code:

= render BadgeComponent.new do |c|
  = c.slot(:detail) do
    Name: Brad Gessler
  = c.slot(:detail) do
    Height: Tall

I assume I'm appending an array of slots? Could it look and feel more like I'm manipulating an array of slots?

= render BadgeComponent.new do |c|
  = c.details.append do
    Name: Brad Gessler
  = c.details.append do
    Height: Tall

The view code for the component is already using an Array-ish API:

.badge-component
  - if details.empty?
    Nothing to see here
  - else
    - details.each do |d|
      = d.content

Inside of that component, I might want to also be able to look at that collection of detail slots and possibly manipulate it from within the Ruby code:

class BadgeComponent < ViewComponent::Base
  include ViewComponent::Slotable

  with_slot :title
  with_slot :detail, collection: true

  def initialize(title, example_details: 0)
    @title = title
    example_details.times do |n|
      details.append "Detail #{n}"
    end
  end
end

Treating collection slots as an array would make some composition/inheritance problems a little easier to implement.

[bbugh]

Seems like some good changes.

Migrate from component.slot to component.slot_name. e.g. Given a component with a header slot, we could call component.header instead of component.slot(:header)

We had discussed this and I spent some time prototyping it this, but IIRC the reason it didn't work at the time is that the method has to perform two different incompatible functions.

For example, these two header methods are both on SomeComponent, but behave very differently:

<%= render SomeComponent.new do |c| %>
  <%# c is the instance of SomeComponent %>
  <% c.header ... %>
<% end %>

# some_component.html.erb
<%# self is the same instance of SomeComponent %>
<%= header %>

[joelhawksley]

@bbugh you're correct to identify the conflict between the two incompatible functions. It's likely that we'll need to change the API for accessing slot content.

[jensljungblad]

You can still use the same method to perform both writing/reading. That's what Rails does with content_for, for instance. This was my implementation of the same behavior: https://github.com/jensljungblad/elemental_components/blob/master/lib/elemental_components/element.rb#L38-L48

To use the example @bbugh posted above, you can write to the header slot using component.header passing either arguments or a block, and you read the header by passing nothing.

[bbugh]

@jensljungblad yeah, exactly! Ruby is awesome. Checking arity was the simplest prototype I tried. Unfortunately, there was something specific to how slots were initialized that was causing an intractable problem with sharing method names. IIRC it was something to do with slot methods not being defined until called by the consumer, and if you called it in the component template without the consumer doing it, some initialization code would misfire. There was also something about the Slotable concern implementation that was interfering I think. I tried a few workarounds but I'm remembering that the trouble was fundamental to the loading process. It's definitely solvable but at the time I didn't see a way to do it without broader internal refactoring.

[jensljungblad]

@bbugh Got it :)

[BlakeWilliams]

I have a mostly working (I think) prototype of using the same method as a writer/accessor that I worked on a while back here: https://github.com/github/view_component/blob/slots-v2/lib/view_component/slotable_v2.rb

I think the API is nice, but it does cost us a good bit of future flexibility and might not work with some of the other ideas that V2 might want to solve.

[khiga8]

Heya! I was directed from here. I'm gonna copy and paste some of what I wrote over there, but I think it'd be great if slots allowed non-keyword argument parameters!

Feature Request
Currently slots only allow keyword/double splat parameters to be set. It would be nice if they also allowed non-keyword parameters.

Motivation
I am envisioning a dropdown menu component with a few different toggle options. The ButtonToggle will ultimately render an existing button component (with some additional data attributes set). It would be nice if I can match the parameters of this slot with the button component. Currently a keyword is required.

class ButtonComponent < ApplicationComponent

   def initialize(*traits, **html_attributes)

class DropdownMenuComponent < ApplicationComponent

  include ViewComponent::Slotable
  ...

  class BaseToggle < ViewComponent::Slot
    ...
  end

  class ButtonToggle < BaseToggle
    # It would be nice if I can match this with the button component and use *traits
    def initialize(traits: [], **html_attributes) 
     ...
    end
  end

Definitely not a make it or break it, but I think the flexibility would be nice!

[BlakeWilliams]

👋 Hey y'all! Thanks a ton for all the feedback, it's been super helpful 🙏

We've been hard at work on slots v2 and have a draft PR up here: #503

We'd love to get your feedback on the current state of slots v2 and how compatible these changes are with how you currently write, and want to write slots. There's also another proposal that we'd love feedback that has a larger impact on how slots would be written here: https://github.com/github/view_component/pull/503/files#r506001533

Feel free to comment with thoughts and ideas in the pull request itself.

[fsateler]

As an extra point, creating a new component for each item will lead to large number of allocations if rendering many items, since a new Component needs to be created for each row. Refactoring as methods instead of classes avoids that overhead.

[BlakeWilliams]

I usually think of views (the .html.erb file) as a method that returns a string. What #451 wants is essentially the possibility to refactor that method into several. Most importantly, it wants that refactor to be absolutely transparent to the end user. That is, if I have a TableComponent, I don't want the user to do:

I don't believe slots or the other proposal aim to solve that specific problem. Although I'm hesitant about being able to split a single component into multiple templates, since that's effectively creating partials if I understand things correctly.

If I later decide I want the header in a separate view, I don't want that to be an API break for the user.

Would your proposal somehow cover that?

With the exception of splitting the component into multiple templates, I think creating that API and introducing a header via a slot could be done without breaking changes with the new, or existing slot API. e.g.

Before

<header>
  My Table Header
</header>

After

<% if header.present? %>
  <header class="<%= header.class_names %>">
    <%= header %>
  </header>
<% else %>
  <header>
    My Table Header
  </header>
<% end %>

For example, your proposed API would require making a (public) component for use in the slot.

I think that's true if you don't want to use the "simple" slot API, but want to use a slot that requires more logic. I don't believe it's possible right now, but I could imagine supporting creating private components nested inside of other components, exactly how slots are created in v1.

[fsateler]

I don't believe slots or the other proposal aim to solve that specific problem. Although I'm hesitant about being able to split a single component into multiple templates, since that's effectively creating partials if I understand things correctly.

I believe you are correct on both counts. I wonder why you give "effectively creating partials" as a negative, though. The proposal has 2 key characteristics that invalidate the most critical flaws in plain vanilla partials:

1. Partials are "private". You can't just render a partial from a component from outside the component. Thus you keep invocations "local".
2. Explicit arguments. This makes partials look a lot more like real methods, which they are. This makes it easier to determine what parameters are needed, unused, etc. It also removes a lot of performance-impacting code.

Moreover, I believe that partials are effectively needed if ViewComponent is to be used in larger views (eg, full pages), in order to maintain each partial to a manageable size.

With the exception of splitting the component into multiple templates, I think creating that API and introducing a header via a slot could be done without breaking changes with the new, or existing slot API. e.g.

The problem is the outward API. AFAIU, extracting the header into a slot would effectively mean that the user now needs to call component.header somewhere. At the risk of repeating myself, what I want is better internal code organization, without impacting the public API.

[khiga8]

It looks like slots v2 is being released soon 🎉!
When it's released, will support for current slots API continue (at least for a while?)?

[joelhawksley]

@khiga8 we plan to leave the initial implementation of Slots in the library until we release v3. We will deprecate it, along with Content Areas, ahead of the release.