Layout not omitted for turbo frames when using custom layout #268

morgoth · 2021-10-27T08:37:31Z

Let's say having:

AdminController < ApplicationController
  layout :admin
end

When I use turbo frame request in sample controller:

UsersController < AdminController
  def show
  end
end

The optimization to omit layout in

turbo-rails/app/controllers/turbo/frames/frame_request.rb

Line 16 in a0f14b9

layout -> { false if turbo_frame_request? }

does not work.

I can see that this bug is known, ie #232 (comment) but opening this issue to keep track on this specific problem.

The text was updated successfully, but these errors were encountered:

WriterZephos · 2022-02-21T16:46:05Z

I don't consider this a bug. You want dynamic behavior but you are setting the layout in a static way. Try setting your layout with a proc instead of a static value.

The change you are asking for would break other people's code (including my own) where we rely on being able to set the layout and override the turbo default.

HalfBloody · 2022-05-11T10:24:12Z

This behaviour breaks the turbo frame silently when it's placed in the layout because the header already contains an empty turbo frame with the same name.

It's counter-intuitive that you can place a turbo_frame in Application Layout and it will work but if you place it in custom layout it will unexpectedly not work. This will hinder Turbo adoption.

samlachance · 2022-06-28T22:03:57Z

I ran into something similar to what @HalfBloody did. In my case, though, I was using a turbo-frame with a src which errored when the returned HTML included the layout, which included the turbo-frame with a src

I'm not sure I understand why there is or should be a connection between whether a layout is set and whether a layout will be included in the turbo-frames response. Different layouts are used for all sorts of reasons.

I feel like the current behavior is only intuitive and desirable if you are employing a very specific design pattern. It sounds like the current behavior could be utilized in interesting ways but I'm not sure it's worth not being able to use turboframes in a layout if a layout is set in a controller.

nickjj · 2022-11-25T13:53:53Z

I've encountered this too. It's kind of a big deal because it means our targeted frames are really executing all of the queries associated with other areas of the layout.

I tried setting the layout in 2 different ways:

class Courses::ApplicationController < ApplicationController
  # layout 'courses'
  layout Proc.new { 'courses' }
end

In both cases the full page's content (from <html> to </html>) gets sent in the response when navigating links within a frame.

Does anyone have a suggested workaround?

For more context my custom courses layout has:

<% content_for :content do %>
  <%= render 'courses/video' %>

  <div>
    <%= turbo_frame_tag 'course_details', data: { turbo_action: 'advance' } do %>
      <%= render 'courses/nav' %>
      <%= yield %>
    <% end %>
  </div>

  <%= render 'courses/toc' %>
<% end %>

<%= render template: 'layouts/application' %>

The concern is rendering the video and toc is pretty expensive. There's a bunch of queries that get run and none of that content needs to change when navigating the links in the course detail's frame.

morgoth · 2022-11-25T14:07:39Z

@nickjj You can write in the given controller action render layout: !turbo_frame_request?

nickjj · 2022-11-25T14:16:15Z

@morgoth that ends up bypassing the frame and makes links transition in the same way as Turbo Drive. That was pretty unexpected behavior. I am using nested frames too. Basically that "courses_details" frame has other frames that are used within it.

tmaier · 2023-05-17T21:39:42Z

I was also hit by this, but the other way around. I did not know that turbo-rails would set the layout to false automatically. I started to write layout: false in many related renders (e.g. of modals)

I would vote for properly documenting this behaviour.

The solution is to recommend to not use layout :admin in the controller, where admin is the name of the layout file, but to set it to a method.

For example

AdminController < ApplicationController
  layout :determine_layout

  private

  def determine_layout
    return false if turbo_frame_request?
    
    :admin
  end
end

cice · 2023-06-05T07:35:43Z

We have just been bitten by this hard, too. Imho this should be documented

nickjj · 2023-06-20T23:31:41Z

What pattern would you use to get this to work when the following conditions are true:

You have a custom layout
Your custom layout includes defining a turbo_frame_tag
You have a bunch of view partials that set a turbo_frame target to the frame defined in step 2

With the documentation's suggested changes, I do only get back the turbo_rails/frame.html.erb response but I also get a "Content missing" error and it's due to the response not containing the expected frame defined in step 2.

For example, here's my custom layout in layouts/course/player.html.erb:

<% content_for :content do %>
  <main>
    <div class="min-h-screen md:flex">
      <div class="flex-1">
        <%= turbo_frame_tag "course_video_player" do %>
          ...
        <% end %>

        <%= turbo_frame_tag "course_details", data: { turbo_action: "advance" } do %>
          <%= render "courses/nav" %>
          ...
        <% end %>
      </div>

      <%= render "courses/toc" %>
    </div>
  </main>
<% end %>

<%= render template: "layouts/application" %>

Then inside one of my views for this layout I have a partial with:

<%= link_to "Hello world", "...", data: { turbo_frame: "course_details" } %>

When I click that link, that's when I get the content missing error.

I think this makes sense because the course_details frame doesn't exist since I made a frame request which means the turbo_rails/frame.html.erb layout is being used which doesn't have that frame defined. But I'm not quite sure what an ideal pattern looks like here to make this work. Especially since the layout has a lot of other common things, having to duplicate essentially the entire course player's layout in each view which would be painful. The "real" version has like 100 lines of HTML and I have a lot of views.

Ideally that frame and its associated layout related HTML would exist once somewhere, which is what I did back when the layout loaded in each response but now the layout isn't loaded for frame requests (which technically is the result I want, except I still want the benefits of the layout). What am I doing wrong?

firedev mentioned this issue May 25, 2023

Including tubo_rails gem breaks normalize_name #468

Closed

cice mentioned this issue Jun 5, 2023

Add a note about overwriting layout resolution and turbo frame requests #470

Merged

dhh closed this as completed in #470 Jun 20, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Layout not omitted for turbo frames when using custom layout #268

Layout not omitted for turbo frames when using custom layout #268

morgoth commented Oct 27, 2021

WriterZephos commented Feb 21, 2022

HalfBloody commented May 11, 2022 •

edited

samlachance commented Jun 28, 2022

nickjj commented Nov 25, 2022 •

edited

morgoth commented Nov 25, 2022

nickjj commented Nov 25, 2022 •

edited

tmaier commented May 17, 2023

cice commented Jun 5, 2023

nickjj commented Jun 20, 2023 •

edited

Layout not omitted for turbo frames when using custom layout #268

Layout not omitted for turbo frames when using custom layout #268

Comments

morgoth commented Oct 27, 2021

WriterZephos commented Feb 21, 2022

HalfBloody commented May 11, 2022 • edited

samlachance commented Jun 28, 2022

nickjj commented Nov 25, 2022 • edited

morgoth commented Nov 25, 2022

nickjj commented Nov 25, 2022 • edited

tmaier commented May 17, 2023

cice commented Jun 5, 2023

nickjj commented Jun 20, 2023 • edited

HalfBloody commented May 11, 2022 •

edited

nickjj commented Nov 25, 2022 •

edited

nickjj commented Nov 25, 2022 •

edited

nickjj commented Jun 20, 2023 •

edited