Resource conventions for ActionCable

ActionCable: the part of Rails I find at the same time very cool, and a component I’m never eager to develop around.

In app specs, I’ll often write what endpoints I’ll be needing. GET /plants, POST /friends, and so on. And I’ll often write something to the effect of “LIVE /friends/:id”. What I mean by that: given an endpoint which gives live updates about the status of [resource]—in this example, a Friend record.

Looking at the ActionCable guide,—and I say this with a lot of understanding that it’s still relatively young—it’s as if the conventions we know didn’t exist. All the sadder knowing that in controller-land, conventions about “resources” are already there for free, and make us that much efficient!

I’d like to see better conventions about getting live updates on resources. Ordinary singular resources, but also with an array of them, sometimes a scope of records, associated records on X, and so on.

In my new app, I tried the approach for updates on a single record. I must say that for now, I quite like it.

Some simplified code below, but the gist is:

  • Model broadcasts itself to channel after commits
  • Channel transmits record as json
  • Client can subscribe to updates as an event

Which allows my front-end code to just call:

sub = cable.subscriptions.create(
  {channel: 'FriendChannel', id: 1},
  {received: (friend) => useInDomOrWhatever(friend)}

And I get free updates.

class FriendChannel < ApplicationCable::Channel

  def subscribed
    stream_for friend
    transmit friend.as_json


  def friend
    @friend ||= Friend.find(params[:id])
class Friend < ApplicationRecord
  after_update_commit :transmit_update

  def transmit_update
    FriendChannel.broadcast_to(self, self.as_json)

I think an approach like this could simplify development of interfaces with live views.

I haven’t tested out live-viewing collections/scopes yet, but I’m looking forward to see how conventions can simplify that too.

1 Like

This all seems pretty reasonable, though based on what I infer from your examples, it seems like you’d be pretty excited to know that CableReady - the partner-in-crime to StimulusReflex - recently gained a broadcast_to method that would allow you to do a lot of the live UIs that you seem to be implying.

We’re still getting the next round of documentation ready, but if broadcasting updates to DOM elements that represent resources is exciting, check out this PR. It makes doing the sorts of live updates that have everyone excited about HEY a snap.