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.

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

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

Open
jch opened this issue Feb 5, 2025 · 0 comments
Open

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

jch opened this issue Feb 5, 2025 · 0 comments

Comments

@jch
Copy link

jch commented Feb 5, 2025

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant