Accessing the template block when using Phlex::DeferredRender

[stex]

Hey!

When designing new components for our application, I switched from ViewComponent to phlex now and quite like it so far :)

I have a Modal component which can react to various request formats and behave accordingly:

  def template(&)
    if !turbo_stream? && !turbo_frame?
      plain_content(&)
    elsif turbo_frame?
      frame_content(&)
    elsif turbo_stream?
      stream_content(&)
    end
  end

However, I now wanted to extend this component to support an optional header element
as a ViewComponent-like with_header:

= render Modal.new do |c|
  - c.with_header("something")

  %p I am in the modal body

I'm using Phlex::DeferredRender to delay rendering the template until the header part is known, but that gets rid of the block. I could add a #with_content method, but that seems like overhead and isn't compatible to the original modal component any more.

Is there a way to access the output of the Modal.new-block while using DeferredRender so I can
just yield it in the various methods like I do without the DeferredRender?

Thanks a lot in advance!

[joeldrapper]

Hey @stex, we decided against passing the block to the template method when using deferred render because it could likely lead to confusing interfaces. Take this for example:

render Card.new do |c|
  p { "Before" }
  c.title { "Hello" }
  p { "After" }
end

If the card was implemented in the "builder style" like this, you would get the expected output.

class Card < Phlex::HTML
  def template(&)
    article(&)
  end

  def title(&)
    h1(class: "title", &)
  end
end

But if the card was implemented with deferred render, both paragraphs would appear after the title.

class Card < Phlex::HTML
  include Phlex::DeferredRender

  def template
    article do
      h1(class: "title", &@title)
      yield
    end
  end

  def title(&block)
    @title = block
  end
end

We thought it would be better to encourage people to ignore the output of the block itself and instead use specific methods for each content slot. In this case, we could implement a content or with_content method.

render Card.new do |c|
  c.title { "Hello" }

  c.content do
    p { "Hello" } 
    p { "World" }
  end
end

[willcosgrove]

I think I have changed my opinion on this. I also came from a ViewComponent background and so I used to be on the side of providing the captured block, because that was what I was accustomed to. But I do think that this can be subtly confusing, and it can so easily be made unambiguous by defining a method for your main content block of your component.

Now I view it as a helpful constraint, nudging the component author toward a better interface. But that's just my 2¢.

[joeldrapper]

I think it does feel a little strange when it's the only slot method. For example, this feels redundant when there's no title. It's not terrible, though, and I tend to agree.

render Card do |c|
  c.with_content do
    p { "Content" }
  end
end

[willcosgrove]

That's a fair point.

we could enable it, and it's up to you whether you yield or not.

Maybe it's best to keep Phlex unopinionated here, like it is in most every other scenario.

[stex]

I think it does feel a little strange when it's the only slot method. For example, this feels redundant when there's no title. It's not terrible, though, and I tend to agree.

render Card do |c|
  c.with_content do
    p { "Content" }
  end
end

That was the main reason I asked the question. In most cases, I'll only have the body/content and having to put a slot method around it seemed inelegant.

Maybe it's best to keep Phlex unopinionated here, like it is in most every other scenario.

As phlex.fun currently already contains an own page about DeferredRender, maybe an info box / a short paragraph about this behaviour would be enough to allow yielding?

[stex]

Hey again :)
Did you come to a conclusion regarding this topic?

I'm currently a bit stuck with a few components and before I work around not being able to yield, I wanted to ask whether it might be allowed in a future version of phlex.

---

Edit: I switched away from DeferredRender for now even though it's a bit less elegant