React and ActionCable

Currently, our concert show page makes a fetch call to the server to determine the current status of the seats on the page, and it makes a POST call to put a seat on hold after you click on it. We can replace both of these calls with a single ActionCable subscription—granting, of course, that this is an absurdly minimalist implementation since we’re not doing a full security setup or complicated state transitions or anything like that.

ConcertChannel on the Server

Server side, we need to create a new ActionCable channel. This one will have the same subscribe method as our previous channel, but we need to add a method for our client side to call to actually reserve a ticket:

This is a little more complicated than our earlier channel. In the subscribed method, our stream_from name is now a dynamic string: concert_#{params[:concert_id]}". This suggests two things. First, it means that different concerts will have different streams, so we don’t have to worry on the client about seeing messages not meant for the page we are on. It also means that the client will need to pass the concert ID as a parameter when it subscribes.

And you probably noticed the added_to_cart method. This method is called when the client sends a message that tickets are to be added to the cart. It combines the functionality we had put in the ShoppingCartsController to update tickets and the functionality we had in TicketsController to return a data structure of all the tickets sorted by row. I’ve refactored that functionality into the Shopping Cart and Ticket classes, as shown here:

For our purposes, this means our channel expects a message that tells it to invoke the add_to_cart method with the same data that was passed to the original fetch endpoint, and it uses ActionCable.server.broadcast to send the same complete list of seat setup data back over the channel. This broadcast will go to all the clients subscribed to the channel, crucially including the client that sent the message in the first place.

On the client side, we need to subscribe to the channel. We also need to send a message to it when we click on a seat, and we need to respond to the resulting data. Mostly this involves a slight restructuring of the existing code.

In the Venue component, since we still need to do our data fetch in the useEffect hook but don’t want to poll the server anymore and instead want to subscribe to an ActionCable channel, we need to add a call to create the subscription:

We’ve taken this call to create the subscription out of useEffect for kind of quirky logistical reasons—useEffect happens after the component loads, whereas we want this subscription to be created before the rest of the component loads so that it can be passed down the React component tree. However, we don’t want the subscription to be created more than once, so we create a variable outside the component definition to store the subscription and then only create the subscription if it does not already exist.

The actual creation of the subscription is only slightly different from what we did in the Stimulus ActionCable example. Rather than have the first argument to create be the name of the channel, the first argument is a JavaScript object that has a channel attribute. That attribute determines which channel we are connecting to; every other attribute gets passed to the subscribed method as part of the params hash. As we saw earlier in our definition of the server-side channel, we need to pass the concert ID so that we can specify the name of the channel. In response to the data, in the received part of the code we call the same setVenueData method we were already calling in response to this data when it was coming from an HTTP request.

The place where the client side sends data back to the ActionCable channel happens in the Row component, so we need to pass the subscription to the parameters of the VenueBody and then to the Row. The VenueBody only changes to accommodate importing ActionCable, receiving the subscription as a parameter, and passing it along to each row.

The Row component changes to receive the parameter and then there’s a change to the onSeatChange method as well:

The subscription object is passed through as props.subscription and then we call the perform method on it. The first argument to perform is the name of the method to be invoked on the receiving channel, and the second argument is a JavaScript object that is received as the data argument to the method being invoked. In this case, we’re passing all the same data that we would have been passing to the AJAX POST call.

And that is that. If you open two browsers side by side to the same concert page and click on a seat in one of them, the other browser will change to reflect that action almost immediately.

There is one other thing we can do, which is send the new ticket purchase back to our schedule page to adjust the number of tickets remaining to reflect the change. We have a couple of options here, depending on how much we want to upend the work we’ve already done in this channel. We could change the “sold out” messages we’re sending to the JSON channel to update the amount of tickets available and tweak our existing Stimulus code to handle that. Or we could use a Turbo Stream helper to automatically send a message when a Ticket is updated.

Both of these are viable options, but since we already have a Schedule channel to receive the data, we’ll use that. However, later in Appendix 1, ​Framework Swap​, when we rewrite the React page in Stimulus, we’ll try it the other way.

We get this new feature with only a few small changes. First, our ConcertChannel needs to add a second broadcast when something is added to the cart:

Here we have a second broadcast to the schedule channel. The data format has changed; it’s now an array called concerts, where each element in the array is an object with the properties concertId and ticketsRemaning. In this particular use case, the array will only have one element, but you could imagine a case where we need to refresh multiple concerts at once.

On the client side, we need to update the SoldOutDataController that receives the broadcast:

Three changes were made here. First, at the top of the file, there’s a new interface ConcertRemainingData that contains the concertId and the ticketsRemaining. Strictly speaking, this isn’t necessary, but TypeScript likes to know this information, and we do have it. Second, the createChannel changes slightly to expect concerts as the top-level key in the incoming JSON when data is received. And third, the updateData method changes too. For each entry in the data, it checks all the concert targets, and if the IDs match, it updates the tickets remaining and sold-out information in the element dataset. (For performance reasons, you’d probably want the concertTargets to already be indexed to avoid the inner loop, but it’s not a significant problem yet.)

And we have one more small change to make to ensure the display actually updates. To do this, we need to change the name of the method in the ConcertController to watch the tickets remaining value, like this:

And this works. Now if you open a browser to the schedule page and a different browser to a concert page, selecting seats in the concert page will update the tickets remaining list on the schedule page.