"web_notifications_#{current_user.id}",{title: 'New things!',body: 'All the news that is fit to print'}
```
The `ActionCable.server.broadcast` call places a message in the Redis' pubsub queue under a separate broadcasting name for each user. For a user with an ID of 1, the broadcasting name would be `web_notifications_1`.
The `ActionCable.server.broadcast` call places a message in the Action Cable pubsub queue under a separate broadcasting name for each user. For a user with an ID of 1, the broadcasting name would be `web_notifications_1`.
The channel has been instructed to stream everything that arrives at `web_notifications_1` directly to the client by invoking the
`#received(data)` callback. The data is the hash sent as the second parameter to the server-side broadcast call, JSON encoded for the trip
across the wire, and unpacked for the data argument arriving to `#received`.
...
...
@@ -234,7 +234,7 @@ class ChatChannel < ApplicationCable::Channel
end
```
Pass an object as the first argument to `subscriptions.create`, and that object will become your params hash in your cable channel. The keyword `channel` is required.
If you pass an object as the first argument to `subscriptions.create`, that object will become the params hash in your cable channel. The keyword `channel` is required.
```coffeescript
# Client-side, which assumes you've already requested the right to send web notifications
...
...
@@ -293,7 +293,7 @@ The rebroadcast will be received by all connected clients, _including_ the clien
### More complete examples
See the [rails/actioncable-examples](http://github.com/rails/actioncable-examples) repository for a full example of how to setup Action Cable in a Rails app and adding channels.
See the [rails/actioncable-examples](http://github.com/rails/actioncable-examples) repository for a full example of how to setup Action Cable in a Rails app, and how to add channels.
The second option is to pass the server url through the `action_cable_meta_tag` in your layout.
This uses a url or path typically set via `config.action_cable.url` in the environment configuration files, or defaults to "/cable".
This method is especially useful if your websocket url might change between environments. If you host your production server via https, you will need to use the wss scheme
This method is especially useful if your WebSocket url might change between environments. If you host your production server via https, you will need to use the wss scheme
for your ActionCable server, but development might remain http and use the ws scheme. You might use localhost in development and your
domain in production.
In any case, to vary the websocket url between environments, add the following configuration to each environment:
In any case, to vary the WebSocket url between environments, add the following configuration to each environment:
```ruby
config.action_cable.url="ws://example.com:28080"
...
...
@@ -440,7 +440,7 @@ The Ruby side of things is built on top of [websocket-driver](https://github.com
## Deployment
Action Cable is powered by a combination of websockets and threads. All of the
Action Cable is powered by a combination of WebSockets and threads. All of the
connection management is handled internally by utilizing Ruby’s native thread
support, which means you can use all your regular Rails models with no problems
as long as you haven’t committed any thread-safety sins.
# Collection class for all the connections that's been established on this specific server. Remember, usually you'll run many cable servers, so
# you can't use this collection as an full list of all the connections established against your application. Use RemoteConnections for that.
# As such, this is primarily for internal use.
moduleConnections
# Collection class for all the connections that have been established on this specific server. Remember, usually you'll run many Action Cable servers, so
# you can't use this collection as a full list of all of the connections established against your application. Instead, use RemoteConnections for that.
# WebSocket connection implementations differ on when they'll mark a connection as stale. We basically never want a connection to go stale, as you
# then can't rely on being able to receive and send to it. So there's a 3 second heartbeat running on all connections. If the beat fails, we automatically
# then can't rely on being able to communicate with the connection. To solve this, a 3 second heartbeat runs on all connections. If the beat fails, we automatically
