I also ran into this, any chance of getting this reviewed/merged?

@thomasbrus I'm not comfortable with this solution, as it depends on a Rails monkey patch. We've already disabled the existing monkey patches when the library is used with Rails 6.1, and don't plan to re-introduce them.

That being said, we do need to address this bug. It just might require making changes to Rails itself.

Any workarounds for this?

@thelucid not that I'm aware of. If you find a solution that works for you, let us know!

@joelhawksley I ended up passing the template instance into the constructor and running any renders and helper calls on that instance. Seems to be working quite well.

To clarify, I have a form component that takes a the template as an initializer argument. I store that in an instance variable and renter anything else, including form fields via that instance.

On further investigation, it seems that if this method was changed to always use the view context, this wouldn't be a problem. To give some context, I'm currently passing a template around to avoid this issue:

module ComponentHelper
  # A simple wrapper around `form_with`, for FormComponent.
  # 
  def component_form_with(**options, &block)
    form_with(local: true, **options) do |form|
      FormComponent.new(form, self).then do |component|
        yield component
        render(component, &block)
      end
    end
  end
end

class FormComponent < ViewComponent::Base
  def initialize(builder, template)
    @builder = builder
    @template = template
  end
  
  def fields(**options, &block)
    @template.render(Form::FieldsComponent.new(@builder, **options), &block)
  end
end

I'm happy to create a pull request, but am unsure of any knock on effects of always rendering via the view context.

It seems I can get around this by manually rendering via the view_context, and therefore remove the need to pass around the template. It still feels like the view context should always be used:

module ComponentHelper
  def component_form_with(**options, &block)
    form_with(local: true, **options) do |form|
      render(FormComponent.new(form), &block)
    end
  end

class FormComponent < ViewComponent::Base
  def initialize(builder)
    @builder = builder
  end
  
  def fields(**options, &block)
    view_context.render(Form::FieldsComponent.new(@builder, **options), &block)
  end
end

@BlakeWilliams what do you think about always rendering in view_context?

@BlakeWilliams what do you think about always rendering in view_context?

I'd need to jump back in and regain context, but if we always use view_context are we bypassing render_in and always writing directly to the parent renderers @output_buffer? I think there may be some trade-offs, but that may work.

I can update this branch real quick to try that and see if the tests still pass.

I just pushed up a rebased version with the view_context.render change, sadly it looks like the issue still exists.

I think it may be due to the builder created by form_for and friends captures the current rendering context at call time and view_context may be different by the time the label with a block arg is called? It's also possible it's the existing render_in issue. I'd have to dive in more later, but if anything looks off please let me know.

Thinking about it, one possible fix might be to just not use render_in in production/dev until the @output_buffer issue can be solved. I'm not a huge fan of that, but I think that may unblock things until we can come up with an upstream solution for Rails.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

We have the same problem, are there any updates on this?

@23tux This is something I'll be revisiting soon, so I'm hoping we'll have an update on the status of this problem in the near future.

Sorry for the delay on this, it's a bit of a tricky problem!

I just pushed up a new module that should be includable in components that use a slower, but more correct (from a view component point of view) capture behavior when inside form_for and form_with.

I haven't had a chance to test this out in a real application yet, but if anyone wants to give it a try and report their experience, that would be awesome.

Unfortunately, not even including ActionViewCompatibility helps. This is a pretty big issue that stops me from rewriting my forms with view_component