- How do I install modularavel/favoritable in a Laravel app?
- Install it with composer require modularavel/favoritable, then publish the package's config and migration files using the vendor:publish command documented in the readme. Run php artisan migrate to create the favorites table, and add the favoritable trait to each Eloquent model that should support favoriting. The whole flow is additive and does not modify your existing tables.
- Which Laravel and PHP versions does modularavel/favoritable support?
- The package is tagged at v1.0.0, but the release notes do not publish an explicit Laravel or PHP version matrix. Check the composer.json constraints in the repository before committing, and verify against your current LTS rather than assuming compatibility. If you are on an older Laravel release, test in a scratch branch first.
- How do I make an Eloquent model favoritable?
- Add the package's trait to the model you want users to favorite, which gives that model a polymorphic relationship to favorite records. The inverse relationship is typically available on your user model so you can query what a user has favorited. After that you can call the provided favorite and unfavorite methods directly from your application code or from the Livewire toggle component.
- Should I use a morph map with this package?
- Yes, registering a morph map is strongly recommended before you write production rows, because the polymorphic type column will store either full class names or morph aliases. Switching later means backfilling every existing favorite row, which is effectively a one-way door. Decide the alias strategy up front, especially if you plan to rename or namespace models.
- Does the package prevent duplicate favorites from the same user?
- Uniqueness handling depends on the published migration, so open the generated file and read it rather than assuming a constraint exists. You want a composite unique index covering the favoritable type, favoritable id, and user id columns. If it is missing, add it yourself before going live, since duplicates are painful to clean up afterwards.
- Is counting favorites going to be a performance problem at scale?
- The package provides an Eloquent relationship and query API, but no documented counter-cache or aggregate column. Counting favorites per record with withCount is fine for moderate volumes, but high-traffic listing pages can degrade into expensive scans. If you need favorite counts on every card in a feed, consider maintaining a cached counter column and updating it alongside the toggle.
- What happens to favorite rows when a model or user is deleted?
- Because the migration is published into your app, cascade behavior is whatever you define in that schema and in your database engine. MySQL, Postgres, and SQLite differ in how polymorphic foreign keys and indexes behave, so orphan cleanup is largely your responsibility. Test soft deletes, hard deletes, and forceDelete explicitly, and add a scheduled reaping job if orphans are possible.
- Can I support multiple favorite types like likes, bookmarks, and stars?
- The package is described as single-purpose polymorphic favoriting, with no documented support for multiple independent flavors out of the box. Supporting likes versus bookmarks would require adding a type or collection column and adjusting your queries accordingly. If you need several distinct reactions, evaluate whether a dedicated reactions package is a better fit.
- Do I need Livewire to use the favorites feature?
- No. The core of the package is an Eloquent trait and query API, so you can favorite and unfavorite records from plain controllers, API endpoints, or Blade views. The Livewire toggle button and favorites list components are a convenience layer on top, useful when your front end already runs Livewire. If your app is API-only, you can ignore the components entirely.
- Is modularavel/favoritable production ready and well maintained?
- Treat v1.0.0 as declared API intent rather than proven provenance: it is the first stable tag, the release notes carry no changelog, and the package is maintained by a small vendor org with bus-factor exposure. Integration risk is low because the package is a thin, additive trait, but you should pin the version, read the published migration yourself, and cover the behavior with your own tests. If the maintenance signal matters to you, compare against larger, longer-established favorites packages before committing.