On nested slots...

[tonywok]

Hi there 👋 Loving the library so far. Something similar to what I've wanted in rails views for a long time.

I work on an app that has some reasonably complicated views. In particular, these views get rendered in different contexts (surprise!). The shape are similar, but the components arrive at that shape in different ways -- and sometimes isn't relevant for a particular context.

I'm trying to take advantage of slots, but I'm wondering if I'm using the wrong tool for the job.

render(SomePageComponentA.new(stuff)) do |page|
  page.thing(more, stuff)

I have the urge to go deeper, because the "thing" slot actually has slots of its own, and I want to make sure to fill them in with components that are relevant to SomePageComponentA (as opposed to SomePageComponentB).

In other words, top level components that have the same shape, but their slots are filled in with different variants based on some context.

As far as I can tell, the first level slot declarations do not yield a block, and are unable to inject slots of their own at the point of initial render. In other words, at least from my experimentation, you cannot do:

render(SomePageComponentA.new(stuff)) do |page|
  page.thing(more, stuff) do |thing|
    thing.nested_thing(a,b)    

Instead, it seems you have to have a template for "thing", which renders its slots. This is kind of fine, but I have all the context I need at the initial render and I'd like to just declare exactly what components fill in each slot -- instead of threading some data down to lower level components and making them responsible for deciding.

My solution has been to just pass the nested components I want to render into the component constructors, instead of taking advantage of slots.

render(SomePageComponentB.new(stuff)) do |page|
  page.thing(nested_thing: SomeNestedComponentB.new(a, b))
    # .. further down we go, same shape as "A", but all nested components are scoped to "B"

Then "thing" can render "nested_thing" without caring too much about the fact that it's, say, for A or for B.

I'm curious if I'm missing a concept or trying to fit a square peg in a round hole. Apologies if I was too abstract, more than happy to try again.

Thanks in advance for the discussion :)

[tonywok]

Just a quick update after having re-written the portion of my app.

I ended up passing components in the constructor. I felt like this afforded me the most declarativeness.

In cases where I don't diverge, I use a shared component. In cases where the context is such that I need specific code, I construct a specific component that conforms to the expected interface.

One of the pages ended up looking like this:

build = Shared::Build.new(some: "stuff")
notes = Shared::Notes.new(some: "stuff")
settings = SpecificNamespace::Settings.new(some: "stuff")

build_tab = Shared::Tab.new(title: "Build", icon: "fa-puzzle-piece", panel: build)
notes_tab = Shared::Tab.new(title: "Notes", icon: "fa-pencil", panel: notes)
settings_tab = Shared::Tab.new(title: "Settings", icon: "fa-cog", panel: settings)

tab_container = Shared::TabContainer.new(tabs: [build_tab, notes_tab, settings_tab])

export_modal = SpecificNamespace::ExportModal.new(title: "Something")
exporter = Shared::Exporter.new(modal: export_modal)

Builder.new(tab_container: tab_container, exporter: exporter)

Then there are competing pages that have a similar shape but use components from a different namespace.

Once I have it working, I'm going to see if I can rework it to use slots v2.

[jrochkind]

reading this a few months later, I'm curious how you think that "supply ViewComponent instances in constructor" pattern is working out for you, or if you've ended up reworking it to use slots?

[tonywok]

I've continued down the path of just passing in my dependencies. I'd say it's working out well.

I end up making factory methods to tidy up where all the instantiation happens.

The leaf components can vary quite a bit in the application I'm building - so I think it's preferred that the parent components that render them don't know much, if anything, about the components they render.

I found this difficult to express with slots. It's probably time I try it again and see if that's still the case.

[halo]

I found this discussion after running into the same trouble today. My use case is a table:

/ index.html.slim
/ This does not work, it's just wishful thinking
= render TableComponent.new do |table|

  - @records.each do |record|
    - table.row(url: record.url) do |row|
      
      - row.column 'Date'
        = record.date

I thought I'd let TableComponent render the "header row" by checking one of the actual rows and simply extract the field names from that. Also if there are many rows, maybe I'd like the table design to look differently (I'm using CSS grid to style the table).

Now I'm not sure how to move forward. If I do the following then the row information would be completely detached and inaccessible from the outer table component:

/ index.html.slim
/ This does work but is not what I want
= render TableComponent.new do |table|

  - @records.each do |record|
    = render RowComponent.new do |row|
      
      - row.column 'Date'
        = record.date

Now, I could do something like this but it would be awkward trying to "calculate" the number of rows given this input.

/ index.html.slim
/ This does work but is cumbersome
= render TableComponent.new do |table|

  - @records.each do |record|
  
    - table.row_column 'Date'
      = record.date
      
    - table.row_action 'Show'
      = link_to record_path(record)

    - table.row_action 'Edit'
      = link_to edit_record_path(record)

I tried it, it works, but nested components felt more intuitive, so I tried that, but it doesn't work. I'd appreciate any ideas :) Is this a bug or a feature?

[tonywok]

Can you provide some more detail into what you mean by it doesn't work?

component_b = ComponentB.new(stuff)
render(ComponentA.new(b: component_b))

This should work, and you would be able to do something like:

# component_a

<em>Hi there, I'm component A</em>

<%= render(component_b) %>

# component_b

<em>Hi there, I'm component B</em>

[halo]

Can you provide some more detail into what you mean by it doesn't work?

Yes, what I meant was simply what you already found out:

As far as I can tell, the first level slot declarations do not yield a block, and are unable to inject slots of their own at the point of initial render.

So this does not work:

= render BlogComponent.new do |blog|

  - blog.article do |article|
    
    / This won't work. You cannot call `#title` on the `article` slot.
    - article.title
      = icon :smiley
      ' I would be the title of the article
    
    ' I would be the body of the article.

To my understanding, an ArticleComponent here would not make much sense outside of the BlogComponent. So I would have expected that nesting the two components would be a sensible thing to do. Also, the ArticleComponent would naturally have access to its parent blog component without me having to inject or pass around anything.

It's not a big problem, it just appears that both you and I intuitively thought this would work, but it didn't. So I was wondering whether there is a technical reason for that limitation.

[tonywok]

Thank you for the detailed response!

I think you summed up my confusion expertly, and yes, I think we are both curious about the same thing :)

I'm still manually constructing and injecting as I mentioned above with reasonable success.

However, I do think this syntax (or something like it) would be convenient in some cases. For instance, if you have a similarly structured concept with slight template variation. And I'm not seeing any reason this couldn't be arbitrarily nestable.

Maybe something like...

= render(Blog.new(articles: articles)) do |blog|
  - blog.articles.each do |article|
    .container
      = render(article) do
        %article
          %h1= title
          %p= body
      

I could see this being useful when factoring into really polymorphic structures. Sometimes for small components making a template file feels a bit much. I realize you can define them inline. I could see this for like link_to and friends, but it always feels icky to use content_tag for a reason I can't quite put my finger on.

In this example, the block is effectively what call would return, but you have a more natural way to define the template. This feels maybe slightly different than goals of slots?

Using the example above, I've been putting factory methods on the component definitions. In this case, maybe it could handle constructing the articles based on an aggregate root.

class Blog < ViewComponent::Base
  def self.make(some_record:)
    data_things = some_record.do_query_stuff
    intermediate_results = data_things.slice_and_dice_etc
    intermediate_results.map do |data_thing|
      Article.new(data_thing: data_thing)
    end
  end

  def initialize(articles:); end
end

[tonywok]

Closing this. In hindsight, after using view components a lot more -- and the library getting a lot better, I don't think this is relevant anymore.

[ksweetie]

Hey @tonywok! We're running into exactly this issue, where we're having trouble defining deeply nested slots. Do you have any context or tips for why this is no longer a problem for you? Thank you!

[tonywok]

Hey @ksweetie, sorry I let this drop. Let me try and add some context.

I've become more conscious of when to use slots and when to instead embrace a component rendering a context that happens to contain another component.

For instance, if you imagine an empty state component. I think in the past I would fall into the trap of wanting the component to own every possible variant. Whereas now, I might instead opt to give the component the freedom to render arbitrary content, but still provide a nice looking container so user can get 80% of what they're after without thinking about it (as a contrived example).

Additionally, one of the projects I work on renders a lot of similar, but different content. For instance, I might have context A's page with components A, B, C -- whereas context B's page might have A', B, and C. I was making context specific components that did this. I then burdened myself with making a single generic thing that could render either context.

I've stopped doing this so much. Instead, I leverage the view more as a place to assemble the shared components -- and keep the components unaware of the context in which they render. In the cases where it's necessary (say, like a namespaced url that I need deep down the component hierarchy, I pass it down as an argument).

Let me know if you're running into anything specifically and I can try and suggest how I might handle it -- and one of us will learn something (maybe me! ;))