Don't send after_create_commit and after_destroy_commit to self in broadcasts

[jon-sully]

Greetings! 👋

I really like the premise of just throwing broadcasts into a model and knowing that the lifecycle methods will just work via action cable provided I wire up the correct DOM id's (which are fairly standard) and turbo_stream_froms in my views, but I'm a little bit confused on the underlying construction behind including only broadcasts a la:

class ChatRoom
  broadcasts
end

In particular, I can't quite follow why broadcasts implements the after_create_commit and after_destroy_commit the way it does, pointing all of the broadcasts it queues up to the self channel. Ex: On the create side:

# given
chat_room = ChatRoom.create 

# create callback in context look like
broadcast_action_later_to "chat_room_1", action: :append, target: "chat_room_1"

Which, if I understand correctly, will automatically render the partial chat_room/_chat_room.html.erb with the local variable of chat_room set (standard) then send a turbo stream message to append that rendered HTML targeting a DOM id of chat_room_1.... on a broadcast/cable channel named chat_room_1. My confusion is, given that this model was just created (in a controller#create method maybe), how could a previously-rendered view have subscribed to channel chat_room_1 when it didn't really exist yet?

Thinking through a fairly vanilla Rails install, I'd think a user would create a new record of an object by submitting a form and subsequently get redirected to that record's #show but we'd want other concurrent users to see the new record in a #index list immediately. Or in an alternative install, maybe the form is at the side or bottom of a table-of-records on an #index view and submitting it ought to pop that new record into the table for all users. Under the assumption that the 'table' in a typical #index should have a DOM id == the plural class name, wouldn't it be more typical to have the broadcast sent to that plural class name than the individual-record-dom-id on this 'after create' callback?

---

I believe the after_destroy_commit side is similar — sending a destroy message to the self channel rather than the plural class name channel — but may also be more intuitive it changed.

On the other hand, I do think having the after_update_commit broadcast directly to the self channel makes sense and works great. The after-update callback running as-expected was shown briefly at the end of one of the early Hotwire demos too.

[dhh]

Fixed via #295