stream_from
, we're going to use the stream_for
method:stream_or_reject_for
, which is intended for scenarios where you're looking up a record based on params
, as in the example above. If you're dealing with sensitive information, stream_or_reject_for
is a solid practice.stream_from
:broadcast_to
method, which requires that you pass a resource to it.ActionCable::Channel
provides a class method, broadcasting_for, which provides another way to build string identifiers. If you have a HelensChannel
, you can:stream_for
/broadcast_to
magic that we discuss on this page.HelensChannel
knows what a Post
is or not; it's just joining strings together.broadcasting_for
is not bad, but stream_for
/broadcast_to
is more powerful and presents more interesting creative possibilities.stream_from
and broadcast
make it easy to develop reactive interfaces with Rails.stream_for
and broadcast_to
actually unlock new feature and UX design possibilities.stream_for Helen.find(params[:id])
has_many
relationship or even an integer array attributebroadcast_to
that morphs the markup of the resource for anyone who has that instance displayed on their screencurrent_user
pattern so often that we can almost forget that it's a resource. You know what doesn't forget? CableReady.rails g channel users
to create a UsersChannel.stream_for
current_user
:app/javascript/channels/users_channel.js
connect, and ActionCable will pull in the current_user
reference from your Connection class, no params
required.current_user
from anywhere in your app.broadcast_to
to send updates to current_user
.clear: false
. When called without any identifiers, it will broadcast all queues with constant-based stream names.broadcast_to
allows the developer to queue up all required interface updates on their respective Channels before delivering them with a single, brutal command.id
metadata in your views. For some applications, slugs are a good approach. Other times, Signed Global IDs (aka sgid) are a powerful choice because you cannot reverse engineer the model or id from the resulting string. You can even generate sgids which are use-limited.ApplicationRecord
as we suggested in CableReady Everywhere, you can just use the sgid
method on your model:sgid
instead of an id
:find
, just hand the parameter off to GlobalID::Locator
:#
prepended to the sgid
:dom_id
helper becomes impossible as it reveals the model and id. Use the sgid
as your id
and you won't compromise the security you get with Signed Global IDs.stream_for
multiple resources in one Channel, making use of ternary logic operators and any other decision making structure that might be applicable to your application. After all, if you have instantiated a model instance, you've ready used a substantial amount of logic that is hidden away behind syntactic magic.broadcast_to
is designed to enable shared experiences around resources. A resource that doesn't exist yet is fundamentally difficult to collaborate on. Yet, when you create an empty Google Doc and share editing rights, the document already exists in every meaningful way. If we want a similar outcome, we have to find creative ways to operate on resources that aren't persisted and might not pass validations.param
arrives, establish the subscription and then create the model instance you need. Send the id of that model back to the client:id
value, we create a temporary UUIDv4 for the new resource and send that to the server. When the server sends us an integer back, we can set the idValue
before unsubscribing from the channel and forcing another controller connect
method. After all, it really is just a method:stream_from
and stream_for
together:cable_ready["helen-fans"]
and cable_ready[HelensChannel]
are separate operation queuesbroadcast
can only work with string-based stream identifiersbroadcast_to
can only work with constant-based stream identifiers