Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow broadcasting a renderable later #501

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Allow broadcasting a renderable later #501

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions app/channels/turbo/streams/broadcasts.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -64,6 +64,11 @@ def broadcast_prepend_later_to(*streamables, **opts)
end

def broadcast_action_later_to(*streamables, action:, target: nil, targets: nil, **rendering)
# Serialize the renderable object if it is present.
if rendering[:renderable]
rendering[:html] = rendering.delete(:renderable).render_in(self)
end
Comment on lines +68 to +70
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the property re-assignment necessary? The action_view code that checks for respond_to?(:render_in) seems to expect the object under the :renderable key.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I see. View Components aren't serializable to Active Job arguments:

Error:
BroadcastsTest#test_Message_broadcast_prepend_later_with_renderable:_render_option:
ActiveJob::SerializationError: Unsupported argument type: MessageComponent
    /Users/seanpdoyle/.asdf/installs/ruby/3.2.0/lib/ruby/gems/3.2.0/gems/activejob-6.1.7.2/lib/active_job/serializers.rb:30:in `serialize'
    /Users/seanpdoyle/.asdf/installs/ruby/3.2.0/lib/ruby/gems/3.2.0/gems/activejob-6.1.7.2/lib/active_job/arguments.rb:122:in `serialize_argument'

This means that if we stick with the current proposed change, rendering of the renderable: option would occur immediately, in-process with the request, and the broadcast would be enqueued to a background job.

Prior to this change, the rendering itself occurs in the background job alongside the broadcasting. This change would mean that rendering: options are a special case, require special care, and could have adverse effects on the request-response cycle if the rendering is expensive.

I'm curious what it'd take to make ViewComponent ActiveJob-serializable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is.

Since we're rendering the renderable in advance, if we don't re-assign, the :renderable key will have a ActiveSupport::SafeBuffer value, and Turbo::Streams::Broadcasts#broadcast_action_to will call render_format(:html, **rendering) causing it to fail with:

NoMethodError: private method `format' called for "<div class='test-message'>Test message</div>":ActiveSupport::SafeBuffer

Because it's not actually a renderable that responds to format, but rendered HTML.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I was going to mention exactly that:

That what will happen in the background is the actual broadcasting, but the rendering will still be synchronous. Unless we somehow serialize the component in a way that is compatible with ActiveJob / Sidekiq

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prior to this change, the rendering itself occurs in the background job alongside the broadcasting.

Well, not exactly true, prior to this change, these _later methods using a renderable are entirely broken 😄


Turbo::Streams::ActionBroadcastJob.perform_later \
stream_name_from(streamables), action: action, target: target, targets: targets, **rendering
end
Expand Down
22 changes: 22 additions & 0 deletions test/system/broadcasts_test.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -37,6 +37,28 @@ class BroadcastsTest < ApplicationSystemTestCase
assert_selector("title", count: 1, visible: false, text: "Dummy")
end

test "Message broadcast append later with renderable: render option" do
visit messages_path
wait_for_stream_to_be_connected

perform_enqueued_jobs do
assert_broadcasts_text "Test message", to: :messages do |text, target|
Message.create(content: "Ignored").broadcast_append_later_to(target, renderable: MessageComponent.new(text))
end
end
end

test "Message broadcast prepend later with renderable: render option" do
visit messages_path
wait_for_stream_to_be_connected

perform_enqueued_jobs do
assert_broadcasts_text "Test message", to: :messages do |text, target|
Message.create(content: "Ignored").broadcast_prepend_later_to(target, renderable: MessageComponent.new(text))
end
end
end

test "Users::Profile broadcasts Turbo Streams" do
visit users_profiles_path
wait_for_stream_to_be_connected
Expand Down
Loading