Variants not working with XHR Turbo Stream responses

[HashNotAdam]

Steps to reproduce

1. Create a component that includes both a standard template and a variant.
2. Load a page showing the component
3. Submit a form
4. In the receiving controller, set the variant, then respond using a turbo stream

Expected behavior

The variant version of the component should be shown

Actual behavior

The default template is rendered

Example repo

This repo includes the recommended HomeController. The root page has 2 buttons, "Request Turbo Drive response" and "Request Turbo Stream response". Both buttons submit a form HomeController#create and in both cases the action sets request.variant = :compact.

The difference, however, is that the Turbo Drive version returns the compact variant, while the Turbo Streams version returns the default template. The page also displays the value of request.variant as well as the name of the variant that was loaded.

First page load

Response from Turbo Drive

Response from Turbo Stream

System configuration

Rails version: 7.1.3.2

Ruby version: 3.2.2

Gem version: 3.11.0

[bockets]

I'm running into the same problem with a turbo hotwire native app. The view_context.lookup_context.variants looks right, but the default template is being rendered rather than the variant.

[joelhawksley]

@bockets would you be able to test your failure mode against the v4 branch? I'm hoping we have it fixed there.

[bockets]

@bockets would you be able to test your failure mode against the v4 branch? I'm hoping we have it fixed there.

It is working as expected in the v4 branch 🎉 thank you!

[bockets]

@bockets would you be able to test your failure mode against the v4 branch? I'm hoping we have it fixed there.

It is working as expected in the v4 branch 🎉 thank you!

OK I must have spoken too soon. I'm still getting the non-variant HTML templates when using hotwire native/turbo streams. I've switched back to using the PR I closed #2206 as that does seem to address it in a very hacky way.

[joelhawksley]

@sfnelson any ideas here? I'm wondering if we should try to fix this on the v4 branch due to the compiler changes you landed there.

[sfnelson]

@joelhawksley I'm happy to have a look in a couple of weeks when my workload eases a bit. @bockets do you have a test repro? Can you reproduce the issue with Rails respond_to blocks?

[sfnelson]

I've checked out the repo provided by @HashNotAdam and run it with v4 and I can reproduce the issue. Using a debugger and inspecting @lookup_context for both calls, I can see that in the Turbo Drive case the variant is present but in the Turbo Stream case the variant is not present.

Here's the LookupContext details for the stream:

When I step through the compiler I can see that the variant template is indeed being filtered out because it doesn't match the lookup context @details object.

I don't know what the cause of this issue is, but whatever the cause it's already happened by the time TagBuilder.render_template is called. This makes me think the root cause may actually stem from Rails itself.

FWIW I've reproduced it in pure Rails without ViewComponents: https://github.com/sfnelson/view_component_issue_2025

[sfnelson]

I'm 90% sure this is a Turbo Rails issue. In the usual render path that ViewComponent takes, the actual call to render_in takes place after calling _normalize_render from AbstractController::Rendering.render. This is where configuration such as the variant makes its way into the lookup context.

In the turbo_stream case, the TagBuilder captures the view_context but doesn't call _normalize_render or render_to_body and so the variant is not set by the time the partial is rendered (the actual location that the variant is assigned is in ActionView::Rendering._render_template). This is the code that I was trying to take advantage of by refactoring the ViewComponent compiler, but it's not in the execution path for TurboRails' TagBuilder.

[sfnelson]

As a workaround, if you call lookup_context.variants = :compact in your controller then both Rails and ViewComponent will render the correct variant.

[joelhawksley]

Closing as this issue is not in ViewComponent. Happy to have our test suite validate compatibility though, so if someone wants to write a failing test that is fixed by the upstream fix, I'd be happy to include it ❤️