Returning turbo_frame and broadcasting is a legit way to speed up performance?

1

Hey there,

I was running into issues in my system tests explained in Turbo Stream broadcasts happening before turbo_stream_from can establish websocket connection in System tests with Capybara - #8 by edwinthinks and the way I’ve been getting around it is by returning a turbo_frame and broadcasting. So it looks a little like this:

  <% row_component = IssuesTableRow.new %>

  <%= turbo_stream.replace("#{dom_id(@issue)}-row", row_component) %>
  <% Turbo::StreamsChannel.broadcast_replace_later_to(@meeting, target: "#{dom_id(@issue)}-row", html: row_component.render_to_html) %>

I realize that this is also likely an anti-pattern and makes things a bit more complicated to maintain. But what I’d like to know is would this cause any user experience issues by doing it this way?

Thank you!

1 Like
2

I ended up running into this issue as well in a system test where the broadcast I was expecting was not firing because it would only get queued.

I solved it like so:

RSpec.describe 'Some system test', type: :system do
  include ActiveJob::TestHelper

  # set up
  it 'does something' do
    # other test stuff
    perform_enqueued_jobs do
      # This action triggers my broadcast
      click_link 'Delete'
    end
    # Assert changes
  end
end

You could probably include the helper in some type of config block and set something like run_jobs: true option. There were a few SO posts that set it up like this:

1 Like