Possible issue with using packs and specifying layout directive in controller for turbo frames

This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.

Not sure where to mention this, but for those of you who are using packs, you may be breaking turbo-rails handling for turbo frames if you are specifying a layout directive in your controller (for example, to reference a layout not found in a common place):

require 'json'

module MediaPlanner
  class MediaPlansController < PackageController
    layout 'core_ui/layouts/application'

Doing that prevents the default layout of turbo_rails/frame to be used when a turbo frame request is being serviced (turbo_frame_request?). The downside of this is 2 fold:

• More rendering steps/logic (you’re skipping the turbo frame performance optimization to only render the page, and not render your whole application layout)
• You may be inadvertently consuming flash messages (which are likely being accessed/rendered from your application layout) when you don’t intend for them to be used.
I discovered this when exploring why, when I break out of a turbo frame like this:

format.html do
  redirect_to media_planner_media_plans_path, status: :see_other, alert: @error_message
end

my flash message never showed up.

It turns out that “normal” turbo rails behavior when a turbo-frame:missing event is encountered is to fetch the page twice: once expecting a turbo-frame, and once to do full rendering (with application layout, b/c turbo_frame_request? will be false).

tldr: if you specify your layout per controller, and you’re using turbo frames, you may want to explore something like this:

# media_plans_controller.rb
module MediaPlanner
  class MediaPlansController < PackageController
    turbo_frame_aware_layout_override 'core_ui/layouts/application'
    ...
  end
end
# application_controller.rb
class ApplicationController < ActionController::Base

  def self.turbo_frame_aware_layout_override(new_layout_file)
    layout lambda {
      turbo_frame_request? ?
        'turbo_rails/frame' :
        new_layout_file
    }
  end

@AlexEvanczuk Is there a way we can incorporate this learning into packs-rails ?

I don’t know much (anything) about turbo frames – it seems like they’re part of a suite of tools called hotwire? I wonder if we need a packs-hotwire integration?

Hmmm… “rails” means a lot of things already… does packs-rails expressly communicate the parts of rails it includes, and the parts it does not?

I think turbo-rails & hotwire are a standard part of rails now, even if you don’t choose to use them… just like action cable, active storage, etc….

I didn’t realize those were part of rails – I’m a bit behind on the times! packs-rails IMO should support the pack-version of any rails features where possible!

Right.

So… can you ask around to see if there’s support for this kind of PR against packs-rails?

And maybe we can work together to think about how to add this?

Sure! I doubt anyone will object but I will double check. I’d be happy to help but going to be a bit swamped until after RailsConf at least

I’m not in a rush… just wanted to prevent others from getting bit.

Another lower-tech solution here that will add some incremental value for now would be to just start a discussion about how to configure turboframes with packs and link it in the readme.

Is that what you recommend I start with?

Yeah I think that’d be a good place to start! What do you think?