ViewComponent w/ turbo-frame + Controller render => Turbo frame swap does not occur

[gap777]

Here are the details, as best I can understand them:

1. I have a view component that contains a turbo frame.
2. My VC uses the TF to swap out it's contents between two different modes (show and edit mode)
3. The VC edit mode contains a form. Controller action is standard update action, redirecting 303 to the show action
4. The controller show action renders the VC in show mode.

The intent is that the VC in edit mode would swap out via TF to the VC in show mode.

The observed behavior is that the HTML generated by #4 contains ONLY the VC rendered (no layout), and turbo JS treats the response as a turbo stream (not a turbo frame content swap), and adds the turbo frame to the DOM (as a sibling of body).

Steps to reproduce

Expected behavior

The render after redirect should include the TF layout.

Actual behavior

The render after redirect does not include any head or body tags.

Workaround

If I add content_type to the render call:

render MyVC.new,
            content_type: "text/html"

I get the TF layout (with head and body), and the TF replace occurs as expected.

Backtrace:

As you might already suspect, the problem is that when turbo JS follows the redirect after form submission, the accept header has 3 choices (#1 is turbo streams, #2 is HTML). Then, in actionview-7.2.2.1/lib/action_view/renderer/template_renderer.rb:71

def render_with_layout(view, template, path, locals)
        layout  = path && find_layout(path, locals.keys, [formats.first])

Only the first formats is used when selecting a layout.

System configuration

Rails version:
7.2.2.1

Ruby version:
3.4.1

Gem version:
3.21.0

[gap777]

Related experiences

https://stackoverflow.com/questions/78311269/rails-hotwire-and-viewcomponents-turbo-frames-not-replacing-content

[joelhawksley]

@gap777 would you be able to write a failing test for this issue?

[joelhawksley]

Closing as stale. My gut says this might be fixed by #2158 in the v4 branch, but without a failing test I can't be sure. Please re-open if you can reproduce this on v4.

[d4be4st]

Hi there

I have managed to reproduce the issue.
So the issue is more to do with turbo-rails + turbo-rails.js + directly rendering view_component.

When turbo-rails.js is included, every form submit is submitted with turbo_stream content type.
Since render ViewComponent.new does not set response content_type, the response type will be set as turbo_stream.
turbo-rails.js does not know what to do with turbo_stream response which does not have tags in it.
Manually forcing the content type to be text/html fixes the problem.

https://gist.github.com/d4be4st/69cb2480c2ace03ebe1b8ff34a660dfc

Uncommenting the line 104 in the gist show the "correct" response which turbo-rails.js knows how to handle.

[gap777]

@d4be4st Thank you for doing that.
@joelhawksley Do you think this is something we can fix in ViewComponents?

[joelhawksley]

Closed by #2348