broadcast
and broadcast_to
immediately transmit all pending operations to subscribed ActionCable clients. Both methods can be called on an existing instance of CableReady::Channels
or as the conclusion to a method chain.clear: false
as the last keyword parameter to prevent clearing the queue. Not clearing the operations queue leaves it available for potential future broadcast
methods to repeat.broadcast_later
and broadcast_later_to
are an excellent way to speed up Reflex actions, although creating jobs has its own overhead and the client could receive any operations performed by the job a few ms slower. After all, your users don't know what a Reflex is and likely don't care that it's finished if they are still waiting on content.stream_from
method in their subscribed
method. broadcast
is most frequently called with no arguments, which instructs CableReady to send one ActionCable payload for every string-based stream identifier with pending operations.broadcast
with no parameters delivers all queues identified by strings while ignoring any queues identified by constants.broadcast
is called at the end of a method chain, there is no opportunity to change the identifier. In this context, broadcast
only accepts the optional clear: false
boolean argument.broadcast
can.broadcast_later_to
will batch up all of the outstanding operations, serialize them and send the result to an ActiveJob for processing. The job worker will take responsibility for actually broadcasting the operations.broadcast_to
can.broadcast_to_later
an ActiveRecord model so that the job knows what resource to broadcast the operations to.stream_for
method in their subscribed
method. broadcast_to
is most frequently called with its single mandatory argument, which is an instance of an ActiveRecord model. This instructs CableReady to send one ActionCable payload for every constant-based stream identifier with pending operations.broadcast
method, the developer can deliver multiple constant-based identifiers, or constain the call to a subset. However, while we don't want to be prescriptive, the nature of the resource-driven functionality and the patterns it enables means that most applications using constant-based identifiers will likely be used in a 1:1 channel-to-broadcast capacity. It's actually difficult to come up with a realistic example:broadcast_to
with only an ActiveRecord model parameter delivers all queues identified by constants while ignoring any queues identified by strings.broadcast_to
is called at the end of a method chain, there is no opportunity to change the identifier. In this context, broadcast_to
accepts only model
and the optional clear: false
boolean argument.CableReady::Broadcaster
has access to a special, server-side version of the Rails dom_id helper. Whereas the view helper is typically used to generate id
values for rendering DOM elements which map cleanly to ActiveRecord model instances, this method is intended to generate CSS selector strings used by CableReady to locate those DOM elements.#
so that it can be passed directly to document.querySelector()
on the client. This syntactic sugar means you can use a clever DSL instead of ugly string concatenations.dom_id
can also accept ActiveRecord::Relation
objects, which are are pluralized. Finally, it will also accept any object which can be turned into a String, such as a constantized class name.