Skip to content

Why does broadcast_refresh need to be in a background job? #712

Open
@jch

Description

@jch

From the source https://github.com/hotwired/turbo-rails/blob/main/app/models/concerns/turbo/broadcastable.rb#L386

# As a rule, you should use the <tt>_later</tt> versions of everything except for remove when broadcasting
# within a real-time path, like a controller or model, since all those updates require a rendering step, which can slow down
# execution. You don't need to do this for remove, since only the dom id for the model is used.

# ... snip
# Same as <tt>#broadcasts_refreshes_to</tt>, but the designated stream for page refreshes is automatically set to
# the current model, for creates - to the model plural name, which can be overriden by passing <tt>stream</tt>.
def broadcasts_refreshes(stream = model_name.plural)
  after_create_commit  -> { broadcast_refresh_later_to(stream) }
  after_update_commit  -> { broadcast_refresh_later }
  after_destroy_commit -> { broadcast_refresh }
end

Why is an update commit queued in a background job, but the destroy commit done inline? The comment suggests that later should be used for anything blocking requiring rendering, but the refresh turbo stream tag doesn't require any rendering:

<turbo-stream action="refresh"></turbo-stream>

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions