Weave Code
Laravel Like Laravel Package
cslant/laravel-like
A Laravel package that adds like and favorite behavior to Eloquent models. Use traits and polymorphic relationships to like, unlike, toggle, count, and query liked items with minimal setup and clean syntax.
Laravel Like Package. User 👍 like, 👎 dislike, ❤️ love and unlike features for Laravel Application.
Frequently asked questions about Laravel Like
- How do I install cslant/laravel-like in a Laravel application?
- Install it with composer require cslant/laravel-like. Laravel package auto-discovery should register the service provider and the Like and Love facades for you. Then publish the config and migrations with php artisan vendor:publish, run php artisan migrate, and add the relevant trait to each model that can receive reactions. One caveat: if like.interaction_model or like.users.model are left unset, version 2.1 silently falls back to default models instead of erroring, so confirm those values point at the tables you actually want.
- Which Laravel and PHP versions does cslant/laravel-like support?
- The overview does not publish a version matrix, so check the require block in composer.json on Packagist or GitHub before committing. Version 2.1.0 is the release referenced in the package notes and it shipped a backwards-incompatible trait rename, so read the changelog before upgrading an existing install. If your platform is pinned to an older Laravel major, verify 2.1.0 installs cleanly in a scratch branch first.
- How do I add like and love behavior to an Eloquent model?
- Add the HasLike trait, and HasLove if you want the love verb, to the model's use list. The traits proxy calls to the underlying LikeManager, so methods such as like, dislike, love, unlike, and toggle become available directly on model instances. Because the relations are polymorphic, any Eloquent model can be an interactable without schema changes per model type. Confirm the trait names against the current release, since LoveScope was renamed to LoveScopes in 2.1.
- Should I use the Like facade or the model traits?
- Both are supported and both funnel through LikeManager according to the package architecture, so pick based on call site rather than behavior. Use the model traits when you already have an interactable instance and want compact, readable code. Use the Like facade or inject LikeManager when the subject is resolved dynamically, when a controller touches several different models, or when you want to mock the manager in tests. Injecting the manager is generally the more testable option for service-layer code.
- How do I count likes and check whether a user has already reacted?
- The package exposes count and query helpers through the traits and scopes, letting you query liked items rather than loading every interaction row. Before putting counts on an index page, check whether the package denormalizes a counter on the interactable model or always runs an aggregate query; if it aggregates, eager-load interaction state to avoid N+1 queries. State checks per user should also be batched where possible, especially on listing pages with dozens of rows.
- Does toggle protect against duplicate likes and race conditions?
- A toggle is typically implemented as a read followed by a write, which is race-prone unless the database enforces uniqueness or the write is an atomic upsert. The release notes do not state which approach the package uses, so inspect the migration for a unique index covering user, interactable, and interaction type. If that index is missing, add it, and wrap toggles in a transaction or a retry on unique-constraint violations in high-traffic endpoints. Load testing the toggle route is the quickest way to confirm duplicates cannot slip through.
- What tables and migrations does the package create?
- The package ships publishable migrations, but the overview does not describe the storage shape. Expect the usual pattern: a polymorphic interactable_type and interactable_id pair, a user reference, and a discriminator column for like, dislike, and love. Review the published migration before running it in production so you can size composite indexes for your read patterns, and confirm foreign key behavior for the user column.
- Is upgrading from 2.0 to 2.1 a breaking change?
- Yes. The LoveScope trait was renamed to LoveScopes, and any model or application file still importing the old name will fail fatally at class load, not with a soft deprecation. The rename landed on a minor version bump, which implies the maintainer treats direct trait references as internal, so audit your use statements before upgrading. Search the codebase for the old name and update all references in the same commit as the composer update.
- What happens to interactions when the liked model or user is deleted?
- The extraction of a ForgetsInteractions concern suggests the package includes shared teardown logic, but confirm whether it hooks model deletion events or requires an explicit call. Polymorphic columns cannot use a simple foreign key to the interactable table, so orphans are a real risk unless the package cleans them up or you add a scheduled prune. Deleting the user side is easier to enforce with a cascading foreign key on the interaction table. Test both deletion paths in a staging database before relying on either.
- Does the package fire events I can hook into for notifications and feeds?
- The package documentation summarized here does not confirm domain events such as ModelLiked. Open the LikeManager source and look for event dispatch calls before designing a notification or activity-feed pipeline around them. If none exist, wrap reactions in your own small service that fires application events after a successful call, which also gives you a single place to enforce duplicate handling. That wrapper is also a sensible way to mock reactions in tests.
Weaver
How can I help you explore Laravel packages today?