Getting Started

Require the package with Composer and follow the README installation steps. Publish migrations/config only if you need to customize table names or broadcast behavior.
Run migrations, then add the package’s likeable/reacter traits to the models involved. Confirm service-provider auto-discovery before registering anything manually.
Look first at the Liked, Unliked, and ReactionChanged event classes plus the broadcasting configuration. These define the payload and channel behavior your application will consume.
First use case: have a User like a Post, broadcast the Liked event on the post’s channel, and consume it in a queued listener or frontend Echo subscription. In 1.1.2 the payload should contain actor_type: "User" and likeable_type: "Post".

Implementation Patterns

Use the package traits on both the likeable model and the actor/reacter model. Let the package resolve the polymorphic likeable and actor relations rather than writing those columns directly.
Trigger likes, unlikes, and reaction changes through the package API so the correct domain events and broadcasts fire consistently.
In listeners, treat actor_type and likeable_type as serialized labels. After 1.1.2, compare against class_basename(User::class) and class_basename(Post::class), not FQCNs or morph-map aliases.
For frontend integrations, keep channel authorization tied to the likeable’s channel. The channel name did not change in 1.1.2, so existing Echo subscriptions can remain; only payload type matching needs review.
If you use a morph map, continue using it for database relations, but do not assume the broadcast type equals the morph alias. Add a small mapping helper when clients need to resolve a basename back to a model class.
Queue broadcast listeners where appropriate. Package events are normal Laravel events and compose with ShouldQueue, broadcastOn, and broadcastAs.

Breaking payload change in 1.1.2: actor_type and likeable_type are now PHP class basenames (User, Post), not FQCNs (App\Models\User) and not morph-map aliases. Update any listener, frontend switch, analytics mapper, or test that asserted the old values.
Basename collisions are now possible. If App\Models\User and Admin\Models\User both exist, both broadcast as User; the payload alone cannot distinguish them. Disambiguate through your own payload or channel context if that matters.
The channel name is unchanged. Do not rename subscriptions just because the payload type changed; verify channel routing and payload matching independently when debugging.
Debug broadcasts by inspecting the event in a feature test and logging $event->broadcastWith(). Assert basenames explicitly to catch regressions.
If your API depends on morph aliases, map them from the model yourself rather than reading them from the broadcast payload.
Package dev/CI notes—testing ^1.6 and tmpfs database legs—only affect contributors. Application upgrades should focus on event payload assertions and listener compatibility.
Extension point: if basenames are insufficient, override the broadcast payload in your own listener or event subclass instead of forking the package, and preserve the package’s channel naming.