Group View: Slide <%= @presentation.current_slide %>

``` ```erb <%= turbo_stream_from @presentation %>

Individual View: Slide <%= @presentation.current_slide %>

``` We also need to update our `Application` layout to [refresh with morphing](https://turbo.hotwired.dev/handbook/page_refreshes): ```erb ... <%= csp_meta_tag %> <%= turbo_refreshes_with method: :morph, scroll: :preserve %> ``` ### Using `content_for` instead of an application-wide layout Some sites won't want Turbo refreshes on all pages. To enable morphing on a specific view only, instead of adding the `turbo_refreshes_with` helper to the application layout, add `turbo_refreshes_with` anywhere in a view's `html.erb` file. ```erb <%= turbo_refreshes_with method: :morph, scroll: :preserve %> ``` This will automatically add `turbo_refresh_method_tag` and `turbo_refresh_scroll_tag` to the `` element of that view. A note from the [Rails guides](https://guides.rubyonrails.org/layouts_and_rendering.html#understanding-yield): > Newly generated applications will include `<%= yield :head %>` within the `` element of the `app/views/layouts/application.html.erb` template. If you have updated an older Rails app, you may need to add the `yield` yourself: ```erb ... <%= csp_meta_tag %> <%= yield :head %> ``` ### The broadcasting part With this setup, when `Presentation#current_slide` is updated, the change is broadcast to the listening views, and they ~~magically~~ automatically show the content for the current slide! The overall approach requires updating the `Presentation` record, but more specifically, it relies on an ActiveRecord callback. At first, we tried the seemingly-convenient [increment!](https://api.rubyonrails.org/v8.0.1/classes/ActiveRecord/Persistence.html#method-i-increment-21") and [decrement!](https://api.rubyonrails.org/v8.0.1/classes/ActiveRecord/Persistence.html#method-i-decrement-21") methods to update the current slide. The issue with these (and a few other ActiveRecord methods) is that **they do not trigger callbacks**. And so, they never broadcast a change, and the views never update! ## Getting it working in Test Here's a simple system test to verify that the broadcasting is working as expected: ```ruby # test/system/presentation_test.rb test "/presentations/:id/group dynamically updates its content" do presentation = create :presentation, current_slide: 1 visit presentation_group_path(presentation) assert_text "Slide 1" presentation.update!(current_slide: 2) assert_text "Slide 2" end ``` ...but if you run this on a default Rails setup, it will never work. Why? Because behind the scenes, the broadcasts are handled by jobs. And in Test, jobs are configured by default to use the [TestAdapter](https://api.rubyonrails.org/classes/ActiveJob/QueueAdapters/TestAdapter.html). So, you have two choices: - Use the `:async` adapter in test, include the `ActiveJob::TestHelper` in your test file, and use a `perform_enqueued_jobs` block around the `#update!` call: ```ruby # config/environments/test.rb config.active_storage.service = :async ``` ```ruby # test/system/presentation_test.rb include ActiveJob::TestHelper test "/presentations/:id/group dynamically updates its content" do presentation = create :presentation, current_slide: 1 visit presentation_group_path(presentation) assert_text "Slide 1" perform_enqueued_jobs do presentation.update!(current_slide: 2) end assert_text "Slide 2" end ``` - or, use the `:inline` adapter but swap it out for the test adapter in your `test_helper.rb` file so that `ActiveJob` tests that rely on enqueued jobs continue to work: ```ruby # config/environments/test.rb config.active_storage.service = :inline ``` ```ruby # test/test_helper.rb module ActiveJob module TestHelper def queue_adapter_for_test ActiveJob::QueueAdapters::TestAdapter.new end end end ``` with no changes to the first system test example above. ## Getting it working in Production (Heroku) There are many ways you might be handling jobs in your Production environment, but in Heroku, we had to create a separate dyno running `bundle exec bin/jobs`: ![A list of two dynos in Heroku, one running puma, the other running bin/jobs.](https://images.thoughtbot.com/9094etabzp9i570c9f0u666ucsdf_CleanShot%202025-03-03%20at%2015.16.12.png) ## Final thoughts Thanks to `broadcasts_refreshes`, `turbo_stream_from`, and Turbo morphing, we can keep a robust multi-screen system that stays in sync with the presenter's view with only a few tiny additions to our code. The possibilities are endless, but the core idea is the same: any view can reflect the state of a model with Hotwire. There _are_ some gotchas to keep in mind, but other than that, it's as easy as...syncing!