Broadcasting

Liked, Unliked and ReactionChanged can broadcast over Laravel Echo. Broadcasting is off by default, so existing installs are unaffected. Enable it in config/likes.php or the environment:

// config/likes.php
'broadcast' => [
    'enabled' => env('LIKES_BROADCAST', true),
    'channel_prefix' => 'likes',
    'channel_type' => 'private',   // private | public | presence
],

LIKES_BROADCAST=true

When enabled, each event broadcasts on {channel_prefix}.{segment}.{id}, where the segment is the likeable’s full morph class with its backslashes turned into dots, as Laravel’s model broadcasting does — or its morph-map alias as-is. App\Models\Post id 42 broadcasts on likes.App.Models.Post.42, or on likes.post.42 with Relation::morphMap(['post' => Post::class]). The events keep dispatching as plain events for your listeners regardless of this setting.

Authorising private channels

The default channel type is private, so authorise it in routes/channels.php:

// routes/channels.php
use Illuminate\Support\Facades\Broadcast;

Broadcast::channel('likes.App.Models.Post.{id}', function ($user, int $id): bool {
    return $user->can('view', Post::findOrFail($id));
});

Listening with Echo

Because the events use custom broadcast names, prefix them with a dot in Echo:

Echo.private('likes.App.Models.Post.42')
    .listen('.like.created', (e) => { /* e.like_id, e.actor_type, e.actor_id, e.likeable_type, e.likeable_id, e.type */ })
    .listen('.like.removed', (e) => { /* ... */ })
    .listen('.reaction.changed', (e) => { /* e.from, e.to */ });

Delivery & payload

The events implement ShouldBroadcast, so broadcasts go through your queue. The payload carries ids and the reaction only — never the actor or likeable models, so no attribute of your users ever reaches a channel subscriber:

// like.created / like.removed
['like_id' => 7, 'actor_type' => 'User', 'actor_id' => 1,
 'likeable_type' => 'Post', 'likeable_id' => 42, 'type' => 'love']

// reaction.changed — `from` / `to` instead of `type`
[..., 'from' => 'like', 'to' => 'love']

actor_type and likeable_type are the model’s class basename (User, Post) — never a PHP class name, and not the morph-map alias either, with or without a morph map. Before 1.1.2, an app without a morph map sent App\Models\User to every subscriber — update listeners that matched the old value. They only label the payload: the channel name still identifies the likeable and stays as it was (likes.App.Models.Post.42). Same-named models in different namespaces (Blog\Post, Forum\Post) share a basename, so a listener that needs to tell them apart goes by the channel it subscribed to.

Load anything else you need client-side by id.